依赖升级、框架迁移与技术生命周期

升级是一项持续能力

长期不升级会积累安全、兼容和迁移风险；没有验证地追逐每个新版本也会持续打断交付。团队需要明确支持基线、升级节奏、风险分层和回退方式。

维护技术清单

至少记录：

• Node.js、包管理器、TypeScript 和构建工具支持版本
• 框架、路由、状态、测试和组件库版本
• 浏览器支持范围与用户数据来源
• 已停止维护或即将 EOL 的依赖
• 每个关键工具的负责人、升级入口和兼容测试

运行时和构建工具版本应在本地、CI、容器和部署平台保持一致，避免“声明升级但只有部分环境生效”。

升级分层

1. 补丁升级先运行冻结安装、完整测试和制品对比。
2. 次版本检查新默认行为、废弃告警和插件兼容。
3. 主版本先阅读官方迁移指南，建立独立基线和回滚点。
4. 框架级迁移优先使用兼容层、Codemod 和双运行验证，避免与大规模业务重构同时进行。

自动升级工具可以创建 Pull Request，但不能替代变更理解。按生态和风险分组，限制并发数量，并为安全升级提供加急路径。

渐进迁移

使用 Strangler 思路让新旧实现暂时共存：先稳定公共契约，再按路由、功能或包逐步替换。通过 Feature Flag 或流量分组验证，迁移完成后删除兼容层和旧依赖。

验证内容

• 类型、单元、组件和端到端测试
• 构建时间、产物结构和体积
• SSR、Hydration、路由和缓存行为
• Source Map、监控和部署适配器
• 最低支持浏览器与 Node.js 消费者

实践任务

选择一个构建工具或框架主版本升级：

1. 记录升级前基线和已知废弃项。
2. 独立升级核心与插件，定位兼容差异。
3. 比较构建产物、关键流程和线上指标。
4. 演练回滚，并删除不再需要的临时兼容配置。

验收标准

• 关键工具有支持版本、负责人和 EOL 记录
• 自动升级 PR 数量和分组不会淹没团队
• 主版本迁移与无关业务重构分开
• 升级前后功能、产物和性能都有基线比较
• 回滚经过验证，迁移完成后旧路径被删除