最近帮朋友看一个前端项目，页面突然打不开了，报错信息指向一个叫 'lodash' 的包。查了一圈才发现，他前几天手快，把所有依赖都升级到了最新版，结果新版本的 lodash 某些方法被移除了，而项目里还在用。这种事儿在开发中太常见了，尤其是插件依赖升级，看着是小事，一不小心就能让你加班到凌晨。
先看版本号，别盲目升
很多开发者习惯性执行 npm update 或者直接改 package.json 里的版本号，改成 ^ 最新版就跑。但你要知道，语义化版本有讲究：第一位是主版本号，第二位是次版本号，第三位是补丁号。主版本一变，大概率有 breaking change（破坏性变更）。比如从 vue-router@3 升到 @4，路由写法全变了，你项目能正常才怪。
建议的做法是：先查 CHANGELOG。大多数正规开源库都会写清楚每个版本改了啥。特别是主版本升级，一定要逐条过一遍。比如你用了 axios，升级到 1.0 版本时，取消请求的方式从 CancelToken 改成了 AbortController，代码不跟着改，请求就可能卡住。
本地先试，别直接上生产
有个同事曾经在上线前五分钟升级了 moment.js 到 3.0，结果时间格式全乱了，最后回滚代码才救回来。依赖升级一定要在本地或测试环境先跑通。最好能有一套自动化测试，哪怕只是简单的功能走查，也能挡住大部分低级错误。
你可以建个临时分支，把依赖更新后 run build 看看能不能成功打包，再打开几个核心页面看看有没有白屏、报错。特别是那些通过插件引入的功能，比如 webpack 插件、babel 插件，一旦不兼容，连构建都过不去。
注意依赖之间的冲突
有些插件看似独立，其实底层共用同一个库。比如你项目里同时用了 antd 和 element-plus，它们可能都依赖 dayjs，但版本不一样。这时候 npm 会搞出多份副本，或者强制统一版本，结果就是某个组件的时间显示异常。
可以用 npm ls dayjs 这类命令查依赖树，看看有没有重复或冲突。如果发现不同插件依赖的同一个库版本差太多，就得小心了。必要时可以锁定某个中间版本，或者找替代方案。
锁文件别乱删
package-lock.json 或 yarn.lock 是你项目的“快照”。它记录了当前所有依赖的确切版本，保证团队里每个人装的都一样。有人图省事，删掉锁文件再 install，以为能解决冲突，结果往往带来更多问题。
正确的做法是：保留锁文件，升级时用 npm update --save 或 yarn upgrade 明确指定要升哪个包。这样锁文件也会自动更新，不会影响其他依赖。
留好退路，随时能回滚
每次升级前，记得提交一次代码。万一升完出问题，git reset --hard 就能快速回到之前状态。别嫌麻烦，这一步能省下你几小时排查时间。
举个真实例子：我们组有次升级了 eslint 插件，结果 CI 流水线一直失败，因为新版本默认规则更严格。当时没备份，只能一个个降级试，折腾了大半天。后来我们就定了一条规矩：升级依赖必须单独提交，标题写清楚“upgrade: xx from 1.2.3 to 2.0.0”，方便追溯。
代码示例：如何安全地升级一个插件
# 1. 查看当前版本
npm list some-plugin
# 2. 查看可用更新
npm outdated some-plugin
# 3. 查看变更日志（浏览器打开）
npm view some-plugin changelog
# 4. 在测试分支升级
npm install some-plugin@latest
# 5. 运行测试
npm run test
npm run build
# 6. 确认无误后提交
git add .
git commit -m "upgrade: some-plugin to v2.0.0"插件依赖升级不是按个按钮那么简单，它像是给正在运行的汽车换轮胎，稍有不慎就会翻车。花点时间做足准备，比事后救火强得多。