升级

升级不是一次性任务，而是一套流程：评估影响、分批迁移、回滚预案与验证策略。

目标是降低风险并持续交付。每周一个小升级 + 验证，比一年一次大升级更可控。

一个分阶段计划

把升级当作流水线：你需要更早的信号、更容易的回滚。这要求分阶段与关注点分离。

盘点：依赖库、运行时、构建链路、部署环境。
小步升级，频繁交付。
用清单与指标验证。

升级前：盘点与风险分层

在动版本号之前，先把影响面画出来。升级痛苦多来自隐藏耦合和未知影响范围。

依赖图：识别“根依赖”（`React`、路由、构建工具）以及它们的传导影响。
运行时 vs 工具链：把影响线上行为的变更与开发工具变更分开处理。
风险分层：按流量与关键程度把模块分为高/中/低风险。

一个可落地的分批迁移

一个可靠的顺序是：工具链 → 运行时 → 行为变化。每一步影响的故障类型不同，隔离后排查成本更低。

工具链与类型：`TypeScript`、`ESLint`、构建配置，先把 `CI` 跑绿。
运行时依赖：小跨度升级核心依赖，一次只动一个根依赖。
行为变化：针对性处理弃用与 `breaking change`。
加固：性能回归、可访问性回归、安全扫描。

验证矩阵

明确“上线前必须通过什么”。紧反馈循环比通宵救火更能降低风险。

你的矩阵要“小而严”。如果某个信号噪声很大，要么修到稳定，要么移除——噪声会训练团队忽略红灯。

信号	目标	负责人
Lint	尽早发现明显问题	CI
Typecheck	阻止类型回归	CI
Build	确保产物可构建	CI
冒烟	关键页面与链路	团队

回滚与影响面控制

回滚预案不是悲观，而是工程成熟度。最快的事故处理，是几分钟内能回滚的那种。

保持可回滚：不要把不可拆分的迁移混在一起。
高风险改动要灰度（`canary`/按比例放量）。
明确回滚流程与窗口值班负责人。

发布清单（可复制）

把这份清单贴到发布 PR 里。重点不是“走流程”，而是让每次发布都执行相同的高信号检查。

- [ ] CI green: lint / typecheck / build
- [ ] Smoke: critical pages load; critical actions work
- [ ] Error paths: loading/error/empty states checked
- [ ] Observability: logs/metrics/alerts ready
- [ ] Rollback: revert steps documented and tested
- [ ] Communication: release notes and known issues

升级