一次依赖升级的复盘

这次升级原本计划一个下午完成，最后花了三天。问题不在依赖本身，而在我们对“升级完成”的定义太模糊。

先升级工具链

运行时依赖和构建工具要分开升。混在一起时，一旦构建失败，很难判断是哪个变化导致的。

我们先升级编译器和类型检查，再升级运行时库，每一步都保留一个可以回滚的提交。

再看破坏性变更

变更日志里的 breaking change 只是起点。真正麻烦的是行为变化：默认值改了、警告变成了错误、废弃 API 还能用但语义不同。

留下的检查项

• 升级前记录当前构建时间与产物体积
• 每步升级后跑一次完整测试
• 出现无法解释的差异时，先回滚再定位
• 升级提交单独存在，不和功能混在一起

升级结束之后，我们把这份清单放进了仓库。下一次不应该再靠记忆。