UniApp 聚合开发模式，在 AI 时代还有竞争力吗？
最近重新审视了 UniApp 这套聚合开发模式，想把自己的一些观察和思考整理下来。
我一开始对 UniApp 的态度是比较务实的——它能一套代码搞定多个平台，对资源有限的团队来说，确实能省钱省时间。但越往深想，越觉得这个模式的护城河，在 AI 时代正在被快速侵蚀。下面我就从几个角度聊聊我的看法。
一、组件兼容能力，其实是“最小公倍数”的妥协
UniApp 的组件体系，为了能跨端，做的本质上是对各平台 UI 能力的“最小公倍数”抽象。
什么意思呢？就是它只能封装所有平台都有的那部分能力。一个 picker 组件，微信这边支持多列选择，别的平台可能没有，那 UniApp 就只能做一个功能最简的版本给你用。如果你非要用某平台的独有特性，对不起，你得回到条件编译，写平台专属代码。
这还没完，同一个 video 或 map 组件，在 App 端和小程序端的表现可能完全不一样——层级覆盖、手势冲突、全屏行为，每个端都有自己的一套。这不是 bug，这是架构层面就注定了的差异。而且很多在 H5 端跑得好好的第三方 Vue 组件，到了小程序或 App 端直接就崩了，因为它们是针对 DOM 和 BOM 设计的。UniApp 宣传自己能复用前端生态，但实际能无缝跨端的组件，并没有想象中那么多。
所以组件兼容性差的本质是：它想用一套抽象层，去抹平几个底层渲染模型完全不同的平台。简单组件还行，复杂交互和媒体组件，平台差异一定会漏出来。
二、代码冗余和维护难度，是绕不过去的坎
一开始用 UniApp，可能觉得挺爽，写一套代码，到处跑。但项目一旦从 MVP 阶段走向成熟，条件编译的代码就会像藤蔓一样长得到处都是。
适配 iPhone 灵动岛、对接安卓各家推送、处理不同小程序的订阅消息、登录鉴权流程……这些事几乎没办法用一套代码干净地搞定。你最终还是在维护一个文件里的好几套逻辑。一个功能改动，你得同时在 MP-WEIXIN、MP-ALIPAY、APP-PLUS 下面做验证，心智负担比维护几个独立项目还要大。
而且那些为微信小程序深度定制的组件，高度依赖 wx. API，在 App 端或支付宝小程序里根本没法复用。也就是说，UniApp 的跨端，更多是跨了基础交互和基础业务逻辑。一旦触及平台深度能力，几乎一定是每端一份代码。
这点上我的判断是：随着业务复杂度提高，UniApp 的维护成本并不会停留在“1套代码远远小于N套独立代码”，而是会逐渐趋向于“管理N套纠缠在一起的代码”。那种纠缠，有时候比分开维护更让人头疼。
三、各平台 API 的割裂，是跨端框架的死穴
这一点我觉得是跨端方案最难解的结构性问题。
微信、支付宝、抖音这些平台的小程序 API，发展是异步的，而且是竞争性的。微信出一个新能力，其他平台可能会跟进，但参数、返回值、行为总有细微差别。UniApp 想要封装一套统一的 uni. API，就注定是滞后的、打折的。一个新 API 从微信发布，到 UniApp 官方封装、再支持其他平台，几个月甚至更久是常有的事。对想快速吃新能力红利的产品来说，这个时间差是致命的。
到头来，你真的要用足某平台的能力，还是得自己写 wx.、my. 这些原生 SDK 的调用。这和不用 UniApp 有什么区别？你还是得懂各个平台，还是得维护多套逻辑。UniApp 的中间层，反而多了一层负担。
四、Donut 这类“反向”方案，动摇了根基
微信 Donut 的出现，我觉得对 UniApp 的打击挺大的。
UniApp 的逻辑是：我居中调和，帮你适配所有端。但 Donut 的逻辑是：我在微信这个超级生态里已经够强了，你在我这里做好小程序，我顺便帮你生成一个 App。由于 App 跑的其实就是微信的 SDK 和渲染环境，所以行为和 API 能保持高度一致。这种一致性，恰恰是 UniApp 一直想做但做不到的。
对于大部分业务聚焦国内市场的团队来说，“微信小程序 + 一个过得去的 App” 就是核心诉求。Donut 直接简化了这个模型，而且 API 同步还是官方的、即时的。这对 UniApp 的多端分发价值，是一种釜底抽薪式的冲击。
当然 Donut 也有它的问题，比如深度锁定微信生态、App 性能也不如纯原生。但它证明了一件事：平台官方的“反向”方案，可以比第三方聚合框架更一致、维护成本更低。
五、AI 的出现，正在重构“跨端”的成本公式
这个部分是我最近思考的重点。
UniApp 过去解决的核心矛盾，是开发者有限的精力与多端业务需求之间的矛盾。你只会 Vue，又想搞定多个小程序和 App，UniApp 帮你做翻译。
但现在 AI 的能力，让这件事有了完全不同的解法。
过去你得学 UniApp 的组件、API、条件编译，现在你完全可以用你熟悉的任何一端技术栈，直接用自然语言给 AI 描述需求，AI 就能帮你生成各平台原生的小程序代码。各平台 API 的割裂，对你来说是负担，对 AI 来说只是不同知识库之间的模式匹配，反而更擅长处理。
代码冗余也不再是问题了。你不再直接维护那堆条件编译的代码，你只需要维护好核心逻辑的描述或设计文档，AI 随时能帮你重写或同步更新各平台的具体实现。复杂度并没有消失，但它被转移给了 AI，而不是沉淀在你脑子里。
这是根本性的变化。UniApp 过去牺牲性能和体验换来的“省力”，在 AI 高效生成代码的能力面前，吸引力大幅下降。
六、排错的双重文档困境，让问题雪上加霜
还有一个我特别想吐槽的，就是 UniApp 项目出问题时，排查的体验太糟糕了。
正常跑的时候都还好，一旦出了问题，你就得先判断是 UniApp 框架的 bug，还是原生平台的 bug。然后你得在 DCloud 论坛和微信或支付宝开发者社区两头搜、交叉验证。AI 对这种中间层的复杂 bug 也常常无能为力，给出的答案模棱两可，甚至把框架层和原生层的问题混在一起，反而误导你。
而如果是纯原生开发，问题栈是清晰的，AI 直接基于官方文档就能给你相对精准的答案。这种排错体验的差距，在项目后期的维护阶段会被无限放大。
最后，总结一下我的看法
我觉得 UniApp 不会消失，成本敏感、快速验证、以内容呈现为主的项目，短期内还是会用它。但它的竞争优势正在不可逆地消退。
过去它可能是多数跨端需求的首选，现在它变成了一个需要仔细权衡利弊的特定选项。AI 的出现、平台官方“反向”方案的成熟、开发者对体验和可维护性的要求提高，都在挤压它的生存空间。
我个人现在的倾向是：与其花大量时间去学习一个抽象层的各种坑和妥协，不如深耕自己擅长的一两个原生平台，然后全力用好 AI 这个杠杆来消除跨端的障碍。未来的竞争力，可能不在于你会不会用某个聚合框架，而在于你能不能精准地描述需求，让 AI 帮你高质量地执行。
UniApp 的聚合模式，是一个特定时期的产物，务实、有用，但也充满妥协。认清它的边界，才能在技术选型时做出真正适合自己团队和产品的判断。
最后，我也想反过来问问读到这篇文章的朋友：
我上面聊的，大部分是对 UniApp 这种聚合模式的质疑和担忧。但我也清楚，自己看到的可能只是故事的一面。在实际项目中，有没有哪些场景是 UniApp 实打实跑赢了原生开发或者 AI 辅助开发的？比如某些类型的产品，用 UniApp 确实做到了原生很难做到的性价比？或者在你维护的项目里，条件编译的复杂度并没有想象中那么失控？
如果你有不一样的经验和案例，欢迎分享。技术选型这事，从来就没有标准答案，多一些真实的实践视角，讨论才更有价值。
