Vue 2 停更近三年：老后台系统的三条路，别急着重写
Vue 2 已于 2023 年底停止维护，代码还能跑，但官方补丁通道关了，组件库与构建链也在陆续停更。本文按系统寿命与暴露面给出分级表，拆解就地加固、渐进迁移、重写三条路的适用条件与六步迁移顺序，并给出参考工作量，帮企业在加固、迁移与重写之间做一次能落地的取舍。
停更的含义：代码还能跑，修复通道已经关了
Vue 官方在 EOL 页面写得很清楚：Vue 2 于 2023 年 12 月 31 日停止维护，不再有新功能、更新与修复，但仍保留在 CDN、包管理器和 GitHub 上可以下载。Vue 3 自 2022 年 2 月 7 日起就是默认版本，2.7.16 是 Vue 2 这条线的收尾版本。
这段表述里有两个容易被混在一起的点。一个是「还能用」：老项目不会因为 EOL 突然白屏，服务器也不会自己停机。另一个是「没人修」：往后框架本身出问题，不会有官方补丁了。
更要紧的是围绕它的东西在持续变化，不会等你。三个方向企业侧都能感受到：
- 组件库先行冻结。桌面端后台常用的 Element UI 早已进入冻结维护，仓库标注不再积极维护，版本停在 2.15.x；它此前被披露的安全问题，多集中在 tooltip、popover、message 这类组件的 HTML 字符串属性上。
- 构建链与生态脱节。vue-cli 早已进入维护模式，新项目普遍转向 Vite；Vuex 3、vue-router 3 不再跟进新特性；Nuxt 2 已在 2024 年 6 月 30 日 EOL。
- 审计口径开始追问。甲方安全问卷、投标资格预审、等保测评访谈里，「是否使用已停止维护的组件」这类问题出现频率在上升，答不上来就要用额外材料解释。
换句话说，停更不是一场事故，是一个缓慢收紧的约束：你的代码不变，但周围的支撑在退场。
影响谁：先给系统分级，再决定花多少钱
停更的风险不是均匀分布的。同样是 Vue 2，内网工单系统和对外交易系统的处置优先级完全不同。定级前先回答四个问题：谁能访问、有没有敏感数据、有没有嵌入第三方代码、还要用几年。
| 系统类型 | 典型特征 | 停更后的风险 | 建议处置 |
|---|---|---|---|
| 内网后台 | 只有公司账号能登录，跑内部流程 | 中：攻击面窄，但权限与日志缺口会放大后果 | 先加固，再排迁移窗口 |
| 对外经营系统 | 含支付、会员、订单，直接面对客户 | 高：前端缺陷会直接落在公众视野里 | 限期迁移，别拖过下一个预算年 |
| 低频展示后台 | 几个页面几年不动，只用来发内容 | 低：功能面窄，替代品多 | 冻结依赖，加补偿控制 |
| 已在替换计划里 | 新系统已在开发中 | 取决于并行期长短 | 停止新投入，按期下线 |
有一点容易判断错：代码量不是依据。一个两万行、只在内网跑的后台，风险往往低于一个三千行、直接对外收款的页面。真正决定代价的是两件事——这套系统还要活多久，以及它手上有没有用户数据。
三条路：加固、渐进迁移、重写
路线一：就地加固，把风险关进可控范围
适用于寿命不足一年、或者纯内网的系统。目标不是把问题解决掉，而是在迁移排上日程之前不出事。
- 先升到 2.7.16，并把版本锁死：package-lock 提交入库，走内网私有源，关掉自动升级。
- 清理渲染入口：停用组件库的 dangerouslyUseHTMLString 用法，用户输入统一走转义，富文本内容做白名单过滤。
- 加一层补偿控制：CSP 限制脚本来源，WAF 拦常见注入，后台登录强制二次验证，按角色把权限收窄。
- 把依赖变成清单：记下组件库、路由、状态管理、构建工具的版本与停更状态，指定一名风险接受人，写上复审日期。
- 订阅披露渠道：关注 CVE 通告，框架或间接依赖被披露新问题时能及时收到消息。
这套动作的产出，是一份可以交给审计和甲方看的书面说明：知道问题在哪、谁在盯、什么时候解决。它的价值是把「没人管」变成「有人在管」。
路线二：渐进迁移，多数企业的实际选择
Vue 2.7 已经把 Composition API 后向移植回来，官方也提供 @vue/compat 迁移构建，让 Vue 2 写法直接跑在 Vue 3 引擎上，每碰到一处不兼容就打印一条警告。迁移因此可以拆成几段可交付的工作，而不是一次性重写。
- 升到 2.7 并统一写法，让团队先适应组合式的写法，再换引擎；
- 接入 @vue/compat，把控制台警告当作任务清单逐条清，同时给定一个移除 compat 的日期，否则新代码会继续按旧语义写，越拖越贵；
- 换构建工具。从 vue-cli 迁到 Vite 时出现的白屏，多数来自环境变量前缀、静态资源路径和依赖预构建，先把构建跑通再动页面；
- 页面级灰度。核心页面先迁，边缘页面维持原样，共存期内不混写状态层；
- 替换组件库与生态件。这一步通常是工期重心，属性改名、插槽语义、主题变量都要逐项核对；
- 用测试兜底。迁移前给关键路径补上用例，迁移后用同一批用例验收，避免改完看不出哪里坏了。
| 依赖 | Vue 2 侧 | Vue 3 侧 | 注意点 |
|---|---|---|---|
| 框架本体 | 2.7.16 | 3.x | 先用 compat 过渡，再按日期移除 |
| 路由 | vue-router 3 | vue-router 4 | 守卫注册与通配路由写法有变 |
| 状态管理 | Vuex 3 | Pinia | 两套并存会加重维护成本 |
| 桌面组件库 | Element UI 2.15 | Element Plus | 属性、插槽、主题变量逐项核对 |
| 构建工具 | vue-cli | Vite | 环境变量前缀与资源路径 |
移动端项目要单独看。uni-app 项目里 Vue 3 支持已经可用，但个别原生插件仍以 Vue 2 运行时为前提，迁之前先把插件清单过一遍，别等到编译阶段才发现卡住。
路线三：重写，只在特定条件下划算
重写合理的场景不多，但确实存在：业务本身要大改、页面数量在二十个以内、原代码既没有测试也没有文档、原班人马已经离开。这几个条件同时成立时，迁移的工作量可能高于重做。
反过来，如果只是为了「版本新」而重写，常见结局是需求在半途变化、验收标准写不清、旧系统又不能停，两边同时维护。真要重写，三件事不能省：数据迁移脚本要能重复执行，新旧系统要有并行运行期，回滚预案要实际演练过一次。
成本、周期与取舍
| 路线 | 参考工作量 | 适用前提 |
|---|---|---|
| 就地加固 | 2–8 人日 | 系统寿命不足一年，或纯内网 |
| 渐进迁移 | 每页面 0.5–1.5 人日，含组件替换与回归 | 系统还要继续用三年以上 |
| 重写 | 约为原系统建设量的六成至一倍 | 业务同步重构、页面数量有限 |
上表是参考区间，实际会随代码质量、页面数量、依赖数量浮动，评审时按项目实测再定。判断口径可以简化成一句：寿命不足一年就加固，一到三年就迁移，三年以上现在开始迁移并排下一轮计划。
关于付费延长支持，把它当过渡手段而不是终点。官方 EOL 页面列出了第三方提供的延长支持服务，能买到补丁和响应时限，但费用是逐年发生的，而迁移是一次性投入。系统还要活很久时，年复一年的支持费用会超过一次迁移。
还有一处常被忽略的取舍：迁移期间不要顺手改需求。把「换框架」和「改功能」压进同一个立项，是这类项目延期的主要原因——两边都在动，出了问题定位不到是谁的错。
尊云科技在承接企业官网与后台系统开发时，遇到前端停更的存量项目，通常先做依赖清单与风险分级，再决定是加固还是迁移；走哪条，取决于系统还要用多久、依赖有多少。相关做法可以参考网站与系统开发服务，后端侧的版本判断见PHP 开发与维护，停更框架的取舍逻辑在这篇ThinkPHP 分支判断表里有更细的拆解。
