package.json 里的版本号和 lockfile 有什么作用？
简化版
package.json 声明项目允许的依赖范围，SemVer 用 major.minor.patch 表达兼容承诺；lockfile 记录解析后的精确依赖树、来源与完整性信息，使团队和 CI 尽量复现同一次安装。应用应提交 lockfile，并在 CI 用冻结安装；版本范围与锁文件分别解决“允许什么”和“这次实际用了什么”。
详细版
^1.2.3 通常表示 >=1.2.3 <2.0.0，~1.2.3 表示 >=1.2.3 <1.3.0，精确 1.2.3 只接受该版本。0.x 版本要特别小心：^0.2.3 通常小于 0.3.0，不能简单背成“永远放开 minor”。
lockfile 不只锁直接依赖，还记录传递依赖树和校验信息。它应随依赖变更一起审查和提交，仓库不要混用多种包管理器生成的锁文件。
npm ci 要求 package-lock.json 与 package.json 一致，否则失败，不会替你更新锁文件。可复现仍依赖 npm/Node、平台、可选依赖和安装参数等上下文，所以还应固定工具版本。
完整版教学
一、清单是约束，锁文件是一次解析结果
依赖解析器读取版本范围、平台条件、peer 约束和 registry 元数据，选择具体版本并形成树。package.json 只写 ^1.2.3 时，不能唯一决定最终安装的是 1.2.3 还是未来的 1.9.0。
package.json 范围 + registry 可用版本 + 解析规则
↓
精确依赖树
↓
lockfile记忆钩子：清单回答“可以装谁”，锁文件回答“这次到底装了谁”。
二、SemVer 表达的是发布者的兼容承诺
标准版本为 major.minor.patch：不兼容 API 变更升 major，向后兼容功能升 minor，向后兼容修复升 patch。这是一套契约，不是技术上强制的事实；包作者错误发版仍可能在 patch 中引入破坏。
| 写法 | 典型范围 | 是否包含 |
|---|---|---|
1.2.3 | 仅 1.2.3 | 1.2.4 否 |
~1.2.3 | >=1.2.3 <1.3.0 | 1.2.9 是 |
^1.2.3 | >=1.2.3 <2.0.0 | 1.9.0 是 |
^0.2.3 | >=0.2.3 <0.3.0 | 0.3.0 否 |
预发布版本如 2.0.0-beta.1 还有单独匹配规则，不能按普通稳定版本直觉推断。面试时给常见范围并提醒 0.x 与 prerelease 边界，比背“^ 升 minor”更准确。
三、传递依赖为什么也必须被锁住
项目直接依赖 A，A 又依赖 B；即使 A 的具体版本不变，B 的宽范围仍可能解析到新版。lockfile 保存整个树，防止间接依赖在不同安装时间悄悄变化。
假设项目有 20 个直接依赖，每个平均引入 8 个不同的传递节点，实际需要解析的节点可接近 160 个。只把 20 个直接版本写死，并不能约束剩下的依赖关系。
现代 lockfile 还常含下载来源和完整性哈希。哈希用于验证拿到的包内容是否与锁中记录一致，但不代表该包没有恶意代码或已知漏洞，安全扫描仍然必要。
四、npm install 与 npm ci 的职责不同
npm install 可以根据清单解析并更新 package-lock.json，适合开发者有意增加或升级依赖。npm ci 面向自动化环境，要求已有锁文件且与清单匹配，不匹配就失败，也不会修改清单或锁文件。
| 场景 | 推荐动作 | 原因 |
|---|---|---|
| 新增依赖 | npm install pkg | 同步更新清单和锁 |
| CI 构建 | npm ci | 冻结解析结果 |
| 审查升级 | 检查 manifest + lock diff | 看直接与传递变化 |
若生成锁文件时用了影响依赖树的参数，CI 必须采用一致设置并提交项目级配置。否则“同一个 lockfile”也可能因解析选项不同而失败。
五、为什么有 lockfile 仍不是绝对可复现
安装结果还受包管理器版本、Node ABI、操作系统、CPU、可选依赖和生命周期脚本影响。某些包会在安装时下载二进制或编译本机模块，这些行为不完全由依赖树文本决定。
例如 macOS 与 Windows 可能选择不同的 optional dependency；Node 20 与 Node 24 也可能使用不同原生二进制。因此 CI 应固定 Node 和包管理器版本，并在目标平台实际构建测试。
更高要求场景还会固定 registry、保存制品、生成 SBOM 或使用可验证构建。lockfile 是可复现基础，不是供应链安全的全部答案。
六、升级依赖应该怎样控制风险
依赖升级应是显式变更：先看清单范围和 lockfile diff，再跑测试、构建、体积与漏洞检查。自动升级机器人可以缩短反馈周期，但不能因为 patch 名义上兼容就无审查合并。
删除 lockfile 后重装会让大量传递依赖同时漂移，问题出现时难以定位。除非确实要重建依赖树并承担全量验证，否则不应把删锁文件当作日常“修复”手段。
若 200 个解析节点中一次变化 60 个，变更面是 30%；把升级拆成较小批次更容易归因。安全紧急修复可使用包管理器提供的 override，但要记录原因、范围和移除条件。
peerDependencies 的特殊边界
插件或组件库常用 peerDependencies 声明“由使用方提供且必须兼容”的宿主，例如某个 React 版本范围。它避免库私带另一份宿主造成实例冲突，但现代包管理器可能自动安装 peer，发生冲突时的行为也与工具版本有关。
因此 peer 既不是普通运行依赖，也不是只用于开发的依赖。库自身测试通常还要在 devDependencies 中安装一个宿主版本，并用兼容矩阵验证声明范围的上下界。
七、常见误区与追问
- 误区：
^在任何版本上都表示可以升级 minor。 0.x 的兼容边界更窄，例如^0.2.3不包含 0.3.0。 - 误区：固定直接依赖就不需要 lockfile。 传递依赖仍可能使用范围并发生漂移。
- 误区：lockfile 能证明依赖没有安全问题。 它记录解析结果和完整性，不替代漏洞、来源与恶意行为检查。
- 追问：为什么 CI 更适合 npm ci？ 它在清单与锁不一致时失败，并且不会静默改写锁文件。
- 追问：库项目是否应该发布 package-lock.json？ npm 的 package-lock 面向根项目安装且不会随普通库发布控制使用方依赖树，发布库更应维护合理版本范围。
- 追问：dependencies 与 devDependencies 如何区分？ 前者是包运行所需，后者用于开发构建；应用打包后是否进入产物由模块图决定。
- 追问：lockfile 冲突应该直接选一边吗？ 应先合并清单意图，再用统一包管理器重新解析并验证生成的锁文件。
八、加强记忆
把依赖管理记成“范围定许可、锁文件定现场、冻结安装做复现、工具版本补上下文”：SemVer 只表达兼容预期，lockfile 固定直接与传递解析，CI 拒绝临时改锁，Node、平台和脚本仍需约束。这样能同时回答版本符号、锁文件价值和可复现边界。