uni-app条件编译：避开那些“写了却没用”的坑

在uni-app开发中，条件编译是个好东西，但用不好就容易变成“摆设”。很多开发者以为写了注释代码就会自动按平台生效，结果打包后发现H5端照样报错，或者体积莫名臃肿。问题出在哪？关键在于理解它的生效机制。

uni-app 条件编译怎么写才不被 H5 端忽略

首先得明确一个核心概念：条件编译依赖的是编译器的预处理，而不是运行时的if判断。如果你在JS里用if (uni.getSystemInfoSync().platform === 'h5')，这只是运行时分支，所有平台的打包产物里依然会包含这段代码，既增加体积，又可能因为调用了不存在的API而直接报错。

真正起作用的，是下面这三种独占一行的注释语法，而且必须顶格书写，前后不能有任何空格：

• // #ifdef H5 配合 // #endif：这段代码只会在H5平台的编译结果中间出现。
• // #ifndef MP-WEIXIN 配合 // #endif：这段代码会从微信小程序的编译结果中排除，其他平台保留。
• // #ifdef APP-PLUS || MP-ALIPAY：支持用||连接多个平台，但注意，不支持&&逻辑。

一个常见的低级错误是把// #ifdef写在export default的对象内部，或者前面加了缩进。这么写，编译器会直接把它当成普通注释忽略掉，你的条件编译自然就失效了。

JS 里怎么安全调用平台专属 API

即便用条件编译包裹了代码，事情也没完。举个例子，你在onLoad里调用uni.getBatteryInfo，这个API只在App端存在。即使用// #ifdef APP-PLUS包住了调用语句，如果JS的执行流在某个分支里走到了这个未定义的函数，H5或小程序端照样会抛出“undefined is not a function”的错误。

那怎么办？这里有几个实操建议：

• 封装加隔离：把平台专属API的调用封装成独立的函数，并且用// #ifdef包裹整个函数定义，而不仅仅是包裹函数内部的调用语句。
• 运行时二次防护：在通用逻辑里，通过typeof xxx === 'function'进行判断，尤其是在函数可能被跨端复用的场景下，这等于加了一道保险。
• 避开初始化陷阱：尽量避免在data()或computed中直接调用平台API，因为这些选项在组件初始化时会同步执行，极易引发崩溃。

来看一个更安全的封装示例：

// #ifdef APP-PLUS
const getBatteryLevel = () => {
  return new Promise(resolve => {
    uni.getBatteryInfo({
      success: res => resolve(res.level)
    })
  })
}
// #endif

// #ifndef APP-PLUS
const getBatteryLevel = () => Promise.resolve(100) // 非App端返回一个默认值
// #endif

样式文件里条件编译为什么经常失效

不少人尝试在