package lock 冲突安全处理检查清单

这份清单用于处理 package-lock.json 冲突。完整说明见 package lock 冲突怎么安全处理。目标是先确认依赖意图，再处理锁文件，而不是靠猜。

请在自己的分支或测试仓库里练习。客户仓库需要授权和协作规则确认。

适合谁

适合遇到 merge conflict、pull 后冲突、PR 无法合并、AI 工具改动后锁文件变化的新手。你可以按清单收集材料，再决定是否继续。

也适合做项目诊断。客户只说“package lock 冲突”时，你可以用清单向客户要必要信息。

不适合谁

不适合在客户主分支直接解决冲突。主分支可能触发 CI 和部署，不适合新手试错。

也不适合项目包管理器不明确的情况。npm、pnpm、yarn 的锁文件不一样，不能混着处理。

风险提醒

不要删除锁文件当作默认修复，也不要只保留 ours 或 theirs。锁文件冲突背后可能有真实依赖变更。

如果需要决定依赖升级、删除、替换或包管理器迁移，先写成客户或维护者待确认事项。

具体步骤

按下面顺序处理：

1. 保存当前状态
2. 查看冲突文件
3. 确认包管理器
4. 检查 package.json
5. 确认依赖变更来源
6. 解决依赖声明
7. 按项目流程更新锁文件
8. 运行安装和构建检查
9. 写交付说明和待确认事项

每一步都要有记录。冲突处理不适合凭感觉。

当前状态

记录：

• 当前分支：
• 是否客户仓库：
• 是否有未提交改动：
• 冲突文件：
• 是否触发 CI：
• 是否需要 PR：

常用命令：

git status
git diff

先看状态，再处理。不要在不知道当前分支时改锁文件。

包管理器检查

• 是否有 package-lock.json
• 是否有 pnpm-lock.yaml
• 是否有 yarn.lock
• package.json 是否写 packageManager
• README 是否指定安装命令

如果同时存在多个锁文件，先确认项目约定。不要凭个人习惯决定。

package.json 检查

• 是否新增依赖：
• 是否删除依赖：
• 是否升级版本：
• 是否改 scripts：
• 是否两边都有变更：

如果 package.json 也冲突，优先解决它。锁文件应该反映最终依赖声明。

锁文件处理记录

记录你选择的处理方式：

• 是否按项目流程重新安装：
• 是否保留两边依赖：
• 是否有依赖需要维护者确认：
• 是否生成了额外锁文件：
• 是否删除了误生成文件：

不要只写“解决冲突”。要写清楚为什么这样处理。

验证检查

至少记录：

install command:
lint command:
build command:
test command:
result:
remaining risks:

如果项目没有某个命令，就写“项目未提供”。不要把没跑的检查写成通过。

客户待确认

常见待确认：

• 哪个包管理器是项目约定
• 是否保留某个新增依赖
• 是否允许升级依赖版本
• CI 失败是否与锁文件有关
• 是否由维护者合并 PR

这些事项没有确认前，不要把结果说成最终修复。

不要继续的信号

遇到以下情况先暂停：看不懂 package.json 变更、多个锁文件同时存在、客户要求直接改主分支、冲突涉及安全或支付依赖、CI 失败原因不明、项目负责人没有确认依赖策略。

暂停时可以交付诊断清单，而不是硬合并。

交付说明检查

交付说明至少包含：冲突文件、最终包管理器、是否修改 package.json、更新锁文件的方式、验证命令和剩余待确认。每一项都要能对应到实际操作，不要写泛泛的“已解决”。

如果你没有运行某个检查，就写明原因。例如客户没有提供 CI 权限、项目没有测试脚本、部署平台需要管理员确认。把未验证项写出来，比假装全部通过更可靠。

复盘检查

处理完后，把这次冲突写成三行复盘：冲突为什么出现、你保留了哪些依赖意图、下次如何避免。比如：合并前两边都改了依赖；最终保留新增包并按 npm 重新生成锁文件；下次提交依赖变更时同步说明 package.json 和锁文件。

如果你发现冲突来自包管理器混用，也要记录下来。下次接类似任务时，第一步就先检查锁文件，而不是等冲突出现后再补救。

CTA：下一步

把这份清单复制到排查记录里，先填当前状态和包管理器。需要拆错误用 报错解释器，需要估算范围用 项目报价助手。

免责声明

本文只用于学习和排查自查，不构成安全、法律、职业或收入承诺。真实客户仓库需要授权、备份和人工复核。