什么是 Uni-app 4 的条件编译？

如果你问一个资深的多端开发者，在Uni-app项目里最让他感到踏实的特性是什么，条件编译（Conditional Compilation）多半会排在前三。这玩意儿不像炫酷的动画或复杂的业务逻辑那样引人注目，但它却是支撑“一套代码，多端运行”这个宏伟目标的钢筋骨架。没有它，你的代码库可能会迅速膨胀成一团充满平台判断的意大利面条。

条件编译的本质：编译时决策

很多人会把条件编译和运行时的 if-else 搞混。这是两码事。运行时判断，比如用 uni.getSystemInfoSync().platform 来区分平台，代码会被打包到所有平台，只是在执行时走不同的分支。而条件编译，是在代码构建阶段就完成的。编译器会像一位精明的裁缝，根据你指定的“尺码”（目标平台），只裁剪出适合这块布料的部分，其他部分直接丢弃，根本不会出现在最终的产物里。

举个例子，你想在微信小程序里调用登录，在App里调用一键登录插件。如果用运行时判断，你的包里会同时包含微信登录和App原生插件的相关代码（哪怕只是引用），导致包体积无谓增大。但用条件编译，构建微信包时，App的代码压根不存在；构建App包时，微信的代码也消失了。这就是它最核心的价值：极致的包体积控制和纯粹的代码隔离。

语法：那些以 # 开头的魔法注释

Uni-app的条件编译语法非常直观，就是通过特定的注释指令来实现的。最常见的是 #ifdef（如果定义）和 #ifndef（如果未定义）。

// 只在微信小程序平台存在的代码
// #ifdef MP-WEIXIN
wx.requestPayment({
  // 微信支付参数
})
// #endif

// 在除了H5以外的所有平台存在的代码
// #ifndef H5
const systemInfo = uni.getSystemInfoSync()
// #endif

它不仅能包裹JavaScript逻辑，还能用于CSS样式和JSON配置，甚至是文件/目录的整个存在与否。比如在 pages.json 里，你可以为不同平台配置不同的导航栏样式：

{
  "pages": [{
    "path": "index/index",
    "style": {
      "navigationBarTitleText": "首页",
      // 仅App端启用透明导航栏
      // #ifdef APP-PLUS
      "navigationStyle": "custom",
      // #endif
    }
  }]
}

平台标识符：与谁对话的密码

精准的条件编译依赖于准确的平台标识符。Uni-app定义了一套完整的标识符体系，从大类到子类，粒度很细：

• APP-PLUS: 所有App端（iOS和Android）的统称。当你需要区分iOS和Android时，则用更具体的 APP-IOS 和 APP-ANDROID。
• MP: 所有小程序平台的统称。其下包含 MP-WEIXIN（微信）、MP-ALIPAY（支付宝）、MP-BAIDU（百度）等十多个具体标识。
• H5: 纯Web浏览器环境。
• QUICKAPP-WEBVIEW: 快应用环境。

这种层级设计给了开发者巨大的灵活性。你可以写一段所有小程序都通用的逻辑（用 #ifdef MP），也可以只针对抖音小程序做特殊优化（用 #ifdef MP-TOUTIAO）。

高级用法：不止于代码块

条件编译的威力远不止包裹几行代码。在Uni-app 4的工程实践中，它被用在了更深的维度。

1. 静态资源的分平台管理

你的应用图标在iOS上要用圆角，在Android上要用直角？在 static 目录下，你可以建立 static/app-plus/、static/mp-weixin/ 这样的平台专属目录。构建时，编译器会自动选取对应平台的资源，其他平台的资源不会被引入。这解决了多端UI适配中一个非常实际的痛点。

2. 整个页面或组件的条件存在

某个功能模块只存在于App端，小程序端根本不需要。你不需要在路由配置里写判断，可以直接将整个页面或组件文件夹用条件编译注释命名。例如，创建一个名为 app-only-page.vue?platform=app-plus 的文件（注意：实际是特殊的文件命名约定，并非真的问号参数），它就会只在构建App时被纳入。

3. 与构建模式（如开发、生产）结合

条件编译还可以基于 process.env.NODE_ENV 进行。你可以轻松地在开发环境下注入调试代码，而在生产构建时自动剔除它们，无需手动注释或删除。

// #ifdef development
console.log('当前用户数据：', this.userInfo)
// #endif

审慎使用：避免碎片化

尽管条件编译如此强大，但经验丰富的开发者会对它保持一份克制。过度使用条件编译，尤其是分散在业务逻辑各处的小段条件代码，会让代码的可读性和可维护性急剧下降。后来者很难一眼看出某个平台的特殊逻辑是什么。

最佳实践是：优先使用Uni-app提供的跨平台API，这些API本身就在底层处理了平台差异。只有当API能力或组件表现确实存在无法抹平的鸿沟时，才祭出条件编译这把手术刀。并且，尽量将针对某一平台的完整逻辑（比如整个支付流程）封装在独立的函数或组件里，通过条件编译来引入，而不是在业务流中到处穿插 #ifdef。

说到底，条件编译是一种妥协的艺术，是在追求“代码统一”理想与面对“平台差异”现实之间，找到的那个精准而优雅的平衡点。它让多端开发不再是痛苦的将就，而是可控的、高效的技术策略。