079、依赖升级风险控制：package.json 和 requirements.txt 跨版本升级的 AI 辅助
一次让我熬夜到凌晨三点的依赖升级事故
上周五下午，我接手了一个遗留了三年的Node.js项目。package.json里躺着express@4.16.0，body-parser还是1.18.x的版本。客户要求升级到Express 4.21.x，顺便把安全漏洞全修了。我心想，这不就是改个版本号跑npm install的事吗？
结果npm install跑完，项目直接启动报错。body-parser的API签名变了，中间件链路的执行顺序也跟以前不一样了。更离谱的是，一个依赖了lodash@3.x的第三方包，在lodash升级到4.x后直接罢工。那天晚上我盯着终端里密密麻麻的红色报错，第一次觉得AI如果能帮我做依赖升级的风险评估该多好。
后来我花了三天时间，把Claude Code调教成了我的依赖升级副驾驶。今天这篇笔记，就是那三天踩坑换来的实战经验。
依赖升级为什么总翻车
先说说依赖升级的“三座大山”：
语义化版本号的陷阱。很多人以为4.16.0到4.21.0只是小版本升级，但Express这种大型框架，minor版本之间可能包含breaking change。package-lock.json锁住的子依赖树，在升级主版本后可能完全重构。
