依赖升级风险评估
从 changelog 里挖出真正会踩到的 breaking change
我要把 [依赖名] 从 [当前版本] 升到 [目标版本]，项目里大约有 [N] 处调用。请：1）列出这两个版本之间所有可能影响我的破坏性变更，只保留真正会被调用到的；2）按「必须改 / 建议改 / 可以不改」分类，每条给出改法；3）给出升级顺序（先升哪个、要不要分两次）；4）指出升级后最可能在运行时才暴露的问题，以及怎么在本地提前验证。 [粘贴 changelog 与依赖配置]
使用建议
升级前把 changelog 原文一起贴进去，别只给版本号，它编不出真实变更。
适合什么场景
- 跨大版本升级（React 17→18、webpack 4→5、Spring Boot 2→3），changelog 长到没人读完。
- 安全公告要求限期升级，你需要先评估工作量，而不是直接 npm update。
不适合的场景
- 只是 patch 版本（1.4.2→1.4.3）且 changelog 没有破坏性变更：直接升，跑测试。
- 依赖只在 devDependencies 或构建期使用：运行时风险为零，不必按线上标准评估。
示例
输入
"react": "17.0.2" -> "18.2.0" 调用点：46 处 ReactDOM.render，集中在 2 个入口文件；3 个类组件用了 componentWillReceiveProps；测试依赖 enzyme。 changelog 要点：automatic batching、StrictMode 下 effect 双调用、ReactDOM.render 废弃、componentWillReceiveProps 移除。
你会得到
把 46 处 ReactDOM.render 和 3 处 componentWillReceiveProps 归为「必须改」，并指出 render 的改法集中在两个入口的 createRoot；enzyme 适配器归为「建议改」；automatic batching 导致的渲染次数变化标为「只在运行时暴露」，并提醒依赖渲染次数的测试会挂。顺序是先测试环境，再入口文件。
常见误用
- 只贴 changelog，不贴自己的调用点和用法：它会把所有破坏性变更都算成你的工作量。
- 一次把 6 个依赖一起升，出问题后无法二分定位是哪个引起的。
可以这样改
- 附上 `grep -rn "ReactDOM.render" src | wc -l` 的真实计数和涉及文件，分类会从「可能影响」变成「确定要改」。
- 加「给一个能一次跑完的本地验证脚本」，评估就变成可执行步骤。