升级前先看清楚，别急着点确定
上周同事小李手快，顺手把项目里的几个 npm 插件全升了级，结果第二天用户登录直接报错。查了半天才发现是某个认证插件的依赖库从 v3 升到 v4 后，默认配置项变了，而他压根没注意变更日志。
这种事情在日常开发和运维中太常见了。一个插件看着不起眼，但它背后可能拖着十几层依赖关系。随便升级，轻则功能异常，重则服务瘫痪。
搞清楚当前依赖结构
动手之前，先看看你现在用的是啥。比如 Node.js 项目，跑一遍 npm list <package-name> 或者 yarn why <package-name>，能清楚看到这个插件被谁引用、用了哪个版本、有没有冲突。
npm list axios
# 输出会显示 axios 被哪些模块引用，版本是否一致
Java 项目可以用 mvn dependency:tree 查看依赖树，Python 的话 pipdeptree 是个不错的选择。别嫌麻烦，这一步省下来的时间，后面都得加倍还。
留意主版本号变化
看到版本号从 2.x 升到 3.x？小心了。按照语义化版本规范（SemVer），主版本号变动意味着不兼容的 API 修改。这时候不能靠猜，必须去官方 changelog 看具体改了啥。
比如 moment.js 升级到 dayjs，虽然功能类似，但调用方式不一样。如果你代码里到处都是 moment().format()，直接替换肯定挂。
测试环境先走一轮
别在生产环境上练手。哪怕只是个小工具插件，也得先在测试环境跑一遍完整流程。特别是涉及网络请求、鉴权、数据序列化的模块。
我们之前有个日志上报插件升级后，内部把 JSON.stringify 换成了第三方序列化库，结果遇到循环引用直接抛异常，导致页面卡死。这种问题只有实际操作才能暴露。
锁定依赖版本，避免“意外惊喜”
用 package-lock.json 或 yarn.lock 锁定版本是基本操作。别图省事直接写 ^1.2.3，那样下次安装可能就自动上了新版。
{
"dependencies": {
"lodash": "4.17.20" // 固定版本，不带 ^ 或 ~
}
}
团队协作时尤其要注意这点。你本地跑得好好的，别人拉代码重新 install，结果因为版本不一致出问题，排查起来特别头疼。
关注安全通告，但别盲目跟风
现在 CI 工具动不动就弹出“发现高危漏洞”，建议升级某个深层依赖。这时候别条件反射式升级。先确认这个漏洞在你的使用场景下是否真的可触发。
有些 CVE 只影响特定调用方式，而你根本没用到那部分功能。盲目升级反而可能引入新问题。可以考虑用 npm audit fix --only=prod 控制范围，或者手动打补丁。
留好退路，备份和回滚机制不能少
每次升级前，把原来的 lock 文件和配置备份一下。万一出事，能快速切回去。
我们有个上线前 checklist，其中一条就是“验证回滚脚本可用”。真遇到问题的时候，十分钟能恢复比啥都强。