ARTICLE · 1329413
uni-app 停维倒计时:一个时代结束,但“再见”说早了
uni-app 停维倒计时:一个时代结束,但“再见”说早了
官方文档里一段平静的维护安排，让传统 uni-app 进入了停维倒计时：2027 年初，传统 uni-app 的 App 平台和 uni-app x 的 VDOM 模式将停止常规维护，小程序与 Web 暂未列入同一时间表。已有应用不会自动下线，重大兼容问题仍保留更新可能——但“还能运行”和“值得继续投入”，已经是两个问题。 这篇文章不想写成一篇悼词。旧 uni-app 确实在退场，但把这件事理解成“uni-app 死了”，既高估了一次停维的杀伤力，也低估了这次交接真正改变了什么。真正需要认真对待的，不是告别，而是 DCloud 已经把“增量进化”全部押到了另一条路线上，而那条路线和你熟悉的 uni-app，已经不是同一个东西。 先把边界说清楚，避免两种误读：一种以为“uni-app 彻底不能用了”，一种以为“只是版本号变了一下，照旧就行”。 停的是常规维护，不是运行能力。2027 年初之后，传统 uni-app 的 App 平台和 uni-app x 的 VDOM 模式不再跟进常规更新。官方明确保留的是“新手机不兼容等重大问题”的更新可能——这意味着存量 App 在可预见的未来还能跑，但不会再获得新能力、新优化和新平台适配。小程序和 Web 不在同一停维时间表内，只做小程序的团队，短期内不必因为这条公告改变技术决策。 真正有分量的是另一句话：传统 uni-app 不会跟进 Web 蒸汽模式，相关新能力将放在 uni-app x 上。这比停维日期本身更能说明问题。停维是一个时间点，而“新能力只放在另一条产品线上”是一个方向性宣告。DCloud 没有放弃这个生态，但它正在把“维护存量”和“押注未来”当成两件事来做。对开发者而言，这意味着你继续用旧 uni-app 不是不能用，而是你用的那条线，已经不在框架作者的主航道上。 所以“一个时代的结束”这个说法，成立的方式不是“最后一行代码失效”，而是当下一代能力、工具和长期方向都围绕另一条路线展开时，舞台的灯光已经换了位置。你还在台上，但追光不再跟着你。 
如果对 uni-app x 的印象还停留在“必须写 UTS、先适应一套强类型规则”，这个印象需要更新——但更新之后，也不要走向另一个极端。 蒸汽模式在业务开发上支持普通 JS/TS，UTS 退回到原生插件等场景。这对前端开发者意味着：继续用熟悉的 Vue 和 JS/TS，同时进入新的 App 原生渲染体系，不再要求你为了追求 App 性能先把业务代码全部换成另一种语言习惯。10 月 24 日的 5.33 正式版已经加入 Android、iOS 蒸汽模式的 WGT 应用资源热更新，明确支持 uvue 使用 JS/TS，并新增支付宝小程序支持。这说明产品重心已经从“能不能用”转向“怎样承接老项目”。 但“支持 JS/TS”不等于“旧项目可以平滑过来”。页面布局、CSS 支持、原生能力接入方式仍有边界；旧 uni-app 的 plus API、weex API、旧原生插件不能直接搬进 uni-app x。官方迁移指南涉及 Flex 布局、文字包裹与样式、CSS 子集、组合式 API，以及原生插件替换等多个环节。迁移不只是把.vue改成.uvue，这句话应该被每一个准备迁移的团队打印出来贴在墙上。 
蒸汽模式最容易被人记住的卖点是“去掉虚拟 DOM、比原生快几倍”。这个叙事需要被拆开看，否则很容易在真实项目里失望。 传统 Vue 渲染用虚拟 DOM 描述界面，状态变化时执行比较与更新。这层中间结构让声明式开发更方便，也带来了创建、维护和处理虚拟节点的开销。蒸汽模式的思路是让编译器提前分析模板，把更多工作放到编译阶段，生成更直接的更新逻辑： 传统方式：数据变化 → 虚拟 DOM → 更新界面 蒸汽模式：提前编译模板 → 数据变化 → 定向更新界面 收益主要落在三处：减少虚拟节点的创建与维护、减少部分运行时比较工作、让编译器更充分利用模板中的确定信息。由此有机会降低 CPU 与内存开销。 注意“有机会”这三个字。收益大小取决于页面结构、更新频率和具体实现；网络慢、图片过大、同步任务阻塞，不会因为换了渲染模式就自动消失。更重要的是，在 uni-app x 里，“蒸汽模式”还绑定了一套基于原生渲染管线的新 App 渲染系统，性能变化不能全部归功于去掉虚拟 DOM。DCloud 公布的对比数据也明确说明，并非每个组件都比系统原生组件更快。还有一个容易忽略的边界：uni-app x 编译到 Web 和小程序时仍以 VDOM 模式运行，App 端的性能结论不能直接照搬。 所以正确的期待是：蒸汽模式在 App 端提供了一条值得认真评估的原生渲染路径，但它不是“性能问题一键解决”。看测试报告的条件，比只记住“快几倍”更有价值。 
一个绕不开的问题：既然 AI 已经能分别写 Android、iOS 和鸿蒙，为什么还需要跨平台框架？ DCloud 在选型文章里的一个观点值得拿出来讨论：跨平台框架的价值，也在于减少多端系统的复杂度。我的理解是，代码生成得更快，不代表产品验证会自动变简单。同一个支付结果，三端是否一致？同一个表单，键盘弹出后会不会挡住按钮？同一个列表，换一台设备还是否流畅？这些都需要证据，不能靠“AI 说已经修好了”。 AI 可以降低实现成本，但交付仍然需要有人对结果负责。框架要回答的新问题，已经从“能不能少写几份代码”，延伸到“能不能让人和 AI 更容易把同一套产品做好”。从这个角度看，蒸汽模式支持 JS/TS、保留 Vue 开发方式，比单纯宣传“去掉虚拟 DOM”更有长期意义——它降低的是“人机协作写跨端代码”的门槛，而不只是运行时开销。 
如果你的项目已经上线，第一件事不是打开迁移指南，而是盘点。 只做小程序：先核对目标平台与插件支持，短期内可以继续评估、继续使用，不必因为这条公告仓促迁移。 正在维护 App：优先盘点 UI 组件库、plus 调用、旧原生插件和特殊页面。迁移成本往往藏在这些地方，而不是藏在页面数量里。 准备新建 App 项目：默认应该把 uni-app x 蒸汽模式作为第一候选，而不是继续在传统 uni-app 上起新工程。 更稳妥的验证方式：选一个有代表性的页面，带着真实接口和关键插件先走通；再用真机核对输入、滚动、导航，以及登录支付等业务链路，估算完整改造的工作量。技术换代可以很快，承载着真实用户的产品，需要一步一步走稳。 
旧 uni-app 当然不完美。条件编译、平台差异、打包报错，还有那些看起来只差一点、却迟迟对不齐的页面，都会让人着急。但它曾经让“一套代码，多端运行”从一句口号变成很多人手里真正跑起来的产品，这件事不会因为停维公告而失去意义。 真正值得带走的，不是对旧路线的留恋，也不是对“再见”的情绪化渲染，而是两件更具体的事：看清 DCloud 的重心已经转移到 uni-app x，以及认清迁移成本藏在插件资产和底层黑盒里，而不是藏在语法差异里。旧的代码可以留在 Git 记录里，旧的路不必被说得一无是处；但下一程的选型，应该建立在对 2027 年之后真实维护状态的判断上，而不是建立在对三五年前那个 uni-app 的印象上。 一个时代的结束，未必需要一场喧哗。也可能只是一次认真盘点，一次提交记录，然后打开一个新的工程。
一、停维停的是什么，没停的是什么
二、接棒的 uni-app x，已经不是早期印象里的那个它
三、“去掉虚拟 DOM”赢在哪里，以及不要把它当成万能药
四、AI 会写代码了，跨平台框架为什么还值得存在
五、对老项目，最好的回应是先做一次盘点，而不是急着重写
