标准答案
- 先确认升级对象是框架、构建工具、组件库、运行时 SDK，还是只影响开发阶段的工具依赖。
- 看版本跨度、SemVer 类型、changelog、迁移指南、已知 issue 和安全公告。
- 审查 lockfile diff，确认是否引入大量间接依赖变化或多版本共存。
- 按影响面跑对应验证：类型检查、单测、构建、核心页面冒烟、关键浏览器兼容和性能基线。
- 上线前准备回滚路径，包括回退依赖版本、恢复 lockfile、保留旧静态资源和配置开关。
题目解析
依赖升级最怕把“改一行版本号”当成低风险操作。比如构建工具升级可能影响产物格式，组件库升级可能影响样式和交互，监控或埋点 SDK 升级可能影响隐私字段和性能。
风险评估要先看它处在哪条链路：运行时依赖影响用户，构建期依赖影响产物，类型或 lint 工具影响开发门禁，安全修复则可能要求更快推进。
回滚不能等出问题再想。可回滚的升级应该保留旧 lockfile、旧构建产物或旧发布版本，并明确哪些配置、缓存和 CDN 资源需要一起回退。
代码示例
一次依赖升级可以按固定清单推进，避免只凭本地能启动就上线。
Text
upgrade checklist:
1. read changelog and migration guide
2. update package.json and lockfile together
3. review lockfile diff
4. run typecheck, test, build, smoke test
5. release with rollback version prepared常见误区
- 只改 package.json，不提交 lockfile 或不审查 lockfile diff。
- 把 devDependency 升级和运行时 SDK 升级当成同一类风险。
- 没有回滚版本和旧资源保留策略，出问题只能继续热修。