在 uni-app 面试中，条件编译几乎是必问的考点。原因很简单：uni-app 的核心卖点就是“一套代码，多端运行”，而条件编译正是实现这一目标的关键手段。候选人是否真正理解条件编译，往往能反映出他是否具备真实的跨端开发经验。本文将从使用场景、语法细节和常见坑三个维度，帮你系统梳理这个知识点。
一、什么是条件编译
条件编译是指在编译阶段，根据目标平台的不同，只将符合条件的代码编译到最终的产物中，不符合条件的代码会被直接剔除。它与运行时的 if/else 判断有本质区别：运行时判断会把所有平台的代码都打包进去，靠逻辑分支来执行；而条件编译是在编译时“物理删除”无关代码，产物更小、性能更好，也不会因为某个平台不支持的 API 被引用而报错。
二、典型使用场景
1. 平台特有的 API 调用
不同端的 API 差异是跨端开发中最常见的问题。比如获取系统信息、调用支付、分享等，各端实现方式不同：
// #ifdef MP-WEIXIN
wx.requestPayment({ /* 微信支付参数 */ })
// #endif
// #ifdef APP-PLUS
uni.requestPayment({ provider: 'alipay', /* ... */ })
// #endif
// #ifdef H5
// H5 端走网页支付流程
// #endif
2. 平台特有的组件与样式
某些组件只在特定平台存在，比如微信小程序的 open-data、official-account，App 端的 nvue 页面等。样式方面，小程序不支持某些 CSS 选择器，App 端 nvue 只支持 flex 布局，这些都需要用条件编译隔离。
/* #ifdef H5 */
.container { max-width: 750px; margin: 0 auto; }
/* #endif */
/* #ifdef APP-PLUS */
.container { padding-top: env(safe-area-inset-top); }
/* #endif */
3. 页面路由与导航栏差异
小程序原生导航栏、H5 浏览器导航、App 自定义导航栏的行为差异较大，针对 pages.json 中的配置，也可以用条件编译区分不同平台的导航栏样式和页面路径。
4. 平台特有的逻辑分支
例如登录流程：微信小程序用 wx.login 拿 code，App 端可能用账号密码或第三方登录，H5 端可能用 OAuth 跳转。这些逻辑用条件编译分开，代码清晰且不会互相干扰。
5. 第三方 SDK 的引入
某些 SDK 只支持特定平台，比如微信 JS-SDK 只用于 H5，友盟统计在 App 端使用。通过条件编译引入，可以避免在不适用的平台打包无用代码甚至报错。
三、条件编译的语法
uni-app 支持在 js、css、vue 模板、json 等多种文件中使用条件编译，核心语法是注释形式的指令：
#ifdef：如果定义了某平台#ifndef：如果没有定义某平台#endif：结束#ifdef A || B：多平台或#ifdef A && B：多平台与
平台标识包括：APP-PLUS、APP-NVUE、H5、MP-WEIXIN、MP-ALIPAY、MP-BAIDU、MP-TOUTIAO、MP-QQ、MP-360、MP（所有小程序）等。
在 vue 模板中使用：
<!-- #ifdef MP-WEIXIN -->
<button open-type="share">分享</button>
<!-- #endif -->
在 js 中使用：
// #ifdef H5
console.log('这是 H5 端')
// #endif
在 css 中使用：
/* #ifdef APP-PLUS */
.title { font-size: 32rpx; }
/* #endif */
四、常见坑与注意事项
坑 1：注释符号写错
这是最高频的错误。js 和 css 用 // 或 /* */，vue 模板用 <!-- -->，json 文件用 //（uni-app 对 json 做了特殊处理）。如果注释符号和文件类型不匹配，条件编译会失效，代码会被原样保留甚至报错。
坑 2：条件编译块嵌套混乱
虽然支持嵌套，但嵌套层级过多会导致可读性极差，且容易漏写 #endif。建议控制嵌套深度，必要时拆分成独立函数或文件。
坑 3：把条件编译当运行时判断用
有些开发者用条件编译去处理需要动态切换的逻辑，比如根据用户选择切换主题。这是错误的，条件编译在编译后就固定了，无法在运行时改变。动态逻辑必须用普通的 if/else。
坑 4：作用域问题
条件编译只是“删除代码”，并不会创建新的作用域。如果在条件编译块内用 let/const 声明变量，块外引用会报错。同时要注意，删除后的代码如果导致语法不完整（比如只删了 if 的一半），编译会失败。
坑 5：平台标识拼写错误
比如把 MP-WEIXIN 写成 MP-WEIXIN （带空格）或 MP_WEIXIN（下划线），条件永远不成立，代码既不报错也不生效，排查起来很痛苦。建议统一使用官方文档中的标识。
坑 6：样式条件编译的优先级
在 css 中，条件编译删除后可能影响样式的层叠顺序，尤其是多个平台样式互相覆盖时，要仔细检查最终产物中的样式顺序。
坑 7：HBuilderX 与 CLI 的差异
使用 HBuilderX 创建的项目和 vue-cli 创建的项目，条件编译的配置方式略有不同。CLI 项目需要在 vue.config.js 或 vite.config.js 中确认相关配置，否则可能出现条件编译不生效的情况。
五、面试回答建议
如果面试官问“条件编译的使用场景与常见坑”，可以这样组织回答：
- 先点明条件编译的本质——编译期剔除代码，区别于运行时判断；
- 列举 3-4 个典型场景：平台 API、组件样式、路由导航、第三方 SDK；
- 说明语法要点：
#ifdef/#ifndef/#endif，以及不同文件类型的注释符号； - 重点讲 2-3 个坑，比如注释符号写错、平台标识拼写错误、作用域问题，最好结合自己的实际排查经历；
- 最后补充一句：条件编译应尽量少用，能用统一 API 解决的优先用统一 API，过度使用会让代码难以维护。
总结
条件编译是 uni-app 跨端能力的基石，也是面试中区分“用过”和“用好”的分水岭。掌握它的使用场景不难，难的是在真实项目中避开那些隐蔽的坑。建议在日常开发中养成习惯：写完条件编译后，分别编译到目标平台验证产物，确认代码被正确剔除，而不是想当然地认为它生效了。
未经允许不得转载：任鹏个人博客 » uni-app 中条件编译的使用场景与常见坑
