Codex 修复报错时装了新依赖：怎样审查锁文件里的额外变化

Codex 修复报错时增加依赖，验收重点不是锁文件多了多少行，而是新增包、传递依赖、下载来源和安装行为是否都有任务理由。本文用 npm 项目举例；其他包管理器要使用各自锁定与审计命令。这里不选择依赖版本，也不把锁文件变小当作修复成功。

先把一次安装拆成四个问题

第一，清单文件声明了什么变化，是否确实需要新增运行时依赖？第二，锁文件解析出哪些间接包？第三，这些包来自哪个 registry 或 URL？第四，安装阶段是否会运行脚本或下载额外文件？四项分开记，才能识别“一行清单带来许多合理传递包”和“无关全树升级”的区别。

git diff -- package.json package-lock.json
node --version
npm --version
npm ls --all --json
npm explain 待核对的包名

后两项反映当前安装目录，不一定等于任务前版本。要做前后对照，任务前也必须留存输出，或在另一个干净目录按旧锁文件重建。命令失败和依赖树中的缺失项都要保留，不要把失败输出筛掉后写成“树一致”。

一张能够评审的依赖变化表

合成例子中，任务是解析一个普通日期字符串，工具却增加完整日期组件库。评审不应只问“这个库有名吗”，而应问现有函数能否解决、增加后是否减少了维护风险。

变化	进入路径	任务必要性	需要确认
直接包 A	dependencies	待说明	是否影响生产体积
间接包 B	A → B	随 A 引入	许可证与维护状态
来源域名变化	resolved 字段	无明显关系	是否换了源
安装脚本	preinstall/install/postinstall	待审查	执行程序与下载地址

表中的 A、B 是占位名，不代表对真实包的安全判断。完整性摘要帮助确认包内容与锁定记录一致，不能单凭一个 integrity 字段认定包没有恶意行为。

安装脚本要看实际内容

npm 生命周期脚本可以在安装相关阶段执行代码。先查看新增包发布内容与脚本定义，再在隔离目录中验证。需要初步检查时，可按 npm 的文档使用 npm ci --ignore-scripts，但这会跳过脚本，某些依赖因此不能正常工作；它是降低初次审查暴露面的手段，不是最终可用性验证。

npm ci 适用于已有锁文件的干净安装，清单与锁文件不匹配时会报错，而且会移除目标目录已有的 node_modules。因此不要在保留现场的共享工作目录中随手执行。用另一个检出目录完成冻结安装、相关测试与构建，记录 Node、npm 和平台，因为原生依赖可能受环境影响。

回退记录不要只写“撤掉了”

若决定不要新增包，应撤销本次清单变化并由匹配版本的包管理器重新产生锁文件，再验证依赖树。已有的用户变化不能一起丢弃。记录原先为什么增加、现在为什么不需要、删除后跑过什么检查；如果功能依赖尚未替换完成，明确标成待完成，而不是把安装错误隐藏在测试跳过里。

常见问题

锁文件上千行变化一定有问题吗？ 不一定，包管理器格式与解析树都会影响行数；应解释语义变化。

安全扫描没有告警就能接受吗？ 扫描只能覆盖已知规则，仍需看新增功能和安装行为。

只提交 package.json 可以吗？ 对约定提交锁文件的项目通常不完整，应遵守仓库规则并验证两者一致。

继续处理相关问题

相关入口：Codex 远程压缩报错分流。

官方依据与核对日期

核对日：2026-10-23。npm 锁文件：锁文件记录解析后的依赖树与相关元数据；npm ci：干净安装要求锁文件匹配，且会移除现有 node_modules；npm scripts：安装生命周期可运行包脚本。文中的流程、阈值和合成数据属于工程示例，不能代替当前账号、文件或运行环境的验收。