- 文集信息
- 目录大纲
- 最新文档
- 知识宇宙
文集详情
文集导读
教程导读：带着条件编译这枚罗盘出发
别以为把代码写完，应用就能原封不动地跑上全部设备——uni-app 从来没有许诺过这种魔法。它的真实主张冷静得多：源码保持统一，由编译器在构建的那一刻替各端做取舍，决定微信小程序拿到什么、H5 拿到什么、原生 App 又拿到什么，而不是把所有平台当成同一款产品的换皮。完成这道取舍的开关，就是条件编译。不妨把它想成罗盘：源码是统一的航道图，罗盘在岔路口给出指向，不同平台各走各的航线。整本教程，就沿着这枚罗盘的指向，把 uni-app 的多端开发从头拆开讲透。
为什么选条件编译当主线？因为它在 uni-app 里的地位被严重低估了。很多人把它当成"偶尔包一下平台差异代码"的预处理指令，用完就忘。但在真实项目里，它是贯穿始终的决策机制：页面怎么注册、组件怎么选、样式怎么写、接口怎么调、包怎么拆、产物怎么发，每一站都会重新遇到同一个问题——这段逻辑在各端是否成立？读完全册你会发现，所谓跨端经验，大半就是对"哪些地方必须分叉、哪些地方必须收敛"的判断力。条件编译就是把这个判断力写成机器可执行的形式。
先交代背景。uni-app 是 DCloud 推出的、使用 Vue 语法开发多端应用的框架，一套工程可以编译到 iOS 与 Android 原生 App、H5 浏览器应用，以及微信、支付宝、字节跳动、百度、QQ 等各家小程序。它经过 Vue2 与 Vue3 两条语法线的长期演进，如今又延伸出编译到 Kotlin 与 Swift 的 uni-app X。平台数量多，差异就多：小程序包体积有上限、H5 没有原生导航、App 端有 plus 运行时、各家小程序 API 命名互不相同。这些差异不会因为换了框架就消失，uni-app 的价值在于把差异收纳到统一的书写方式里，而条件编译正是那个收纳口。
全册地图：先看航线再上船
全册按"认知 → 语法 → 界面 → 导航 → 数据 → 原生 → 交付"推进，各章之间有明确的依赖关系：不懂得条件编译的书写位置（第 1 章），语法差异就无从谈起（第 2 章）；组件与路由（第 3、4 章）是界面骨架，数据流（第 5 章）往骨架里灌注状态，原生能力（第 6 章）处理各端专属航道，最后由构建与发布（第 7 章）把整条航线交付到各端应用市场。下图是全册的学习依赖地图，箭头指向"建议先学"的方向，虚线表示可以并行。
图 0-1 全册知识地图：以条件编译为轴心的学习航线
各章会把你带到哪里
| 章 | 解决的核心问题 | 关键产出 |
|---|---|---|
| 第 1 章 | 一套代码凭什么能跑遍多端 | 看懂条件编译的书写位置与编译期分流 |
| 第 2 章 | Vue2 与 Vue3 写法各落在哪一端 | 选对语法线，写跨版本安全的代码 |
| 第 3 章 | 界面在各端为何长得不一样 | 内置组件选型、rpx 布局、UI 框架取舍 |
| 第 4 章 | 页面如何组织与跳转 | pages.json、页面栈、TabBar 与分包策略 |
| 第 5 章 | 数据在各端如何流动与留存 | Pinia 状态树、存储封装、请求与长连接 |
| 第 6 章 | 各端专属能力怎么调 | 原生 API 版图、插件开发、平台限制清单 |
| 第 7 章 | 产物如何送达用户手上 | 编译原理、上架流程、性能与 uniCloud |
使用建议
有 Vue 基础的读者可以从第 1 章顺读，重点消化第 1 章与第 6 章里所有带条件编译的代码段——那是全册反复回访的枢纽。只关心某端的读者，先读第 1 章，再直奔第 6 章对应平台的小节，回头按需补第 3、4 章。每章支柱页都给出本章的知识点清单和主线案例，读正文前先扫一遍支柱页，能少走弯路。所有示例代码都按"可直接放进页面运行"的标准书写，遇到 API 差异处均标注了适用平台，建议边读边在 HBuilderX 里跑通，比单纯阅读有效得多。
目录大纲
最新文档
知识宇宙
正在加载知识图谱...