锁文件原则是什么
锁文件把这次使用的确切版本与完整性校验固化下来：提交入库、CI 按锁严格安装、升级以独立变更评审——这是构建可复现的前提，也是供应链安全的基础。严格安装与常规安装的区别很关键：npm ci、yarn --frozen-lockfile 这类命令按锁还原并校验，不满足时直接失败而不是悄悄升级。
基本原则
| 原则一 | 锁文件进版本库、进评审 |
|---|---|
| 原则二 | CI 用严格还原命令，而非解析升级命令 |
| 原则三 | 升级走独立变更：diff 可读、风险可评估 |
| 完整性 | 锁文件带哈希校验（如 go.sum、npm 的 integrity），防制品被替换 |
| 同步提交 | 依赖清单与锁文件在同一提交更新，评审时一起看 |
| 一致性 | CI 校验清单与锁是否同步，严格还原命令会隐式验证 |
生态对照
| 生态 | 锁文件 | 还原命令 |
|---|---|---|
| Node.js | package-lock.json / yarn.lock / pnpm-lock.yaml | npm ci / yarn --frozen-lockfile |
| Python | requirements.txt（编译版）/ poetry.lock / uv.lock | pip install -r / poetry install --sync |
| Go | go.sum（模块校验） | go mod download |
| Maven | 无独立锁文件（Gradle 有） | mvn -o dependency:resolve（离线复核） |
典型使用场景
- 团队协作：一份锁文件保证成员与容器构建依赖一致
- CI 复现：严格模式确保构建与发布锁定同一版本树
- 升级评审：锁文件 diff 暴露所有传递依赖变化
- 安全响应：升级受漏洞影响的包并复核完整性校验
- 跨环境一致：本地、预发、生产按同一锁还原
- 来源收敛：依赖源（公共源换私源）变更时同步复核锁内解析地址
通用规则
通用规则
1. 锁文件进版本库、进评审
2. CI 用严格还原命令而非解析升级命令
3. 升级走独立变更：diff 可读、风险可评估Maven 生态惯用固定版本号（无锁文件）：依赖解析确定性靠「版本固定 + 仓库不可变」共同保证。
锁文件冲突不要随手重生成：合并冲突时人工比对双方变更，重生成等于放弃审阅。
锁文件格式随工具版本演进（如 npm 的 lockfileVersion 字段）：团队统一工具版本，避免因格式来回改写产生巨量无关 diff。