上周三凌晨两点，有漏议我盯着屏幕上的库修 npm audit 输出，二十七个漏洞，复建其中三个标着 critical。有漏议项目用的库修是两年前某个下载量很高的日期处理库，作者早就不维护了，复建issue 里有人贴了修复方案，有漏议但没人合并。库修这不是复建个例，是有漏议 JavaScript 生态的常态。
漏洞分两种：一种是库修你根本不知道它存在，另一种是复建你知道但改不动。前者靠工具发现，有漏议后者靠人肉权衡。库修我见过一个团队用 lodash 的复建旧版本，只因为某个内部工具依赖了它，升级会导致构建脚本挂掉。他们选择在网关层过滤恶意输入，而不是动那个库。这种“绕过”策略在真实项目里比想象中普遍。
修复的第一步不是急着 npm update。先看漏洞的触发条件。比如 prototype pollution 通常需要攻击者控制对象键名，如果你的代码只处理固定字段，风险就低得多。有个项目用 merge 函数合并配置，但配置来自内部 JSON 文件，外部无法注入，那就没必要为了一个 CVSS 7.5 的评分连夜改代码。评分是通用参考，不是你的风险画像。
真正麻烦的是传递依赖。你直接依赖的库没问题，但它依赖的库有洞。这时候 npm ls 能帮你画出依赖树，找到那个藏在深处的包。我遇到过 minimist 的原型污染漏洞，追了四层才找到是某个 CLI 工具的依赖。解决方案不是升级顶层库，而是用 overrides 字段强制指定版本。npm 8 以后支持这个，yarn 用 resolutions，pnpm 也有类似机制。
{ "overrides": { "minimist": "^1.2.6" } }但强制覆盖有代价。如果新版本改了 API，依赖它的库可能直接崩。我一般先在本地跑一遍测试，再推 CI。没有测试的项目？那就手动跑一遍核心流程，别偷懒。曾经有个同事直接覆盖了 node-fetch 的版本，结果流式响应全挂了，因为新版本改了 stream 的处理方式。这种坑只有跑起来才知道。
如果库已经没人维护，漏洞又没法绕过，那就得考虑替换。替换的成本往往被低估。不是换个包名就行，API 差异、边界情况、性能特征都得重新验证。我换过一个 moment 到 dayjs 的项目，表面看 API 兼容，但时区处理逻辑不同，导致报表日期偏移了一天。后来用 date-fns 重写，又发现它默认不处理夏令时。最后老老实实写了个适配层，把差异封装掉。
还有一个被忽视的点：锁文件。package-lock.json 或 yarn.lock 里锁定的版本可能已经包含漏洞，但 npm audit 默认只检查 package.json 的范围。你得跑 npm audit --production 或者用 npm audit fix --force 强制更新锁文件。不过 --force 会忽略 semver 规则，可能引入不兼容更新，慎用。我通常先 npm audit fix，再看剩下的手动处理。
工具能帮你发现，但判断得自己做。有些漏洞在特定场景下根本不可达，有些则一触即发。别被红色的 critical 吓到，也别因为“只是低危”就忽略。看代码，看调用路径，看攻击面。这才是修复建议里最该写清楚的部分——不是“升级到 x.y.z”，而是“为什么升级、不升级会怎样、升级后要验证什么”。
最后说个反直觉的：有时候不修复才是对的。如果那个库只在开发环境用，漏洞不影响生产，那就标记为已知风险，排进技术债列表，而不是打乱当前迭代。修复漏洞是手段，不是目的。目的永远是让系统在真实威胁下保持可用。
```