pnpm 和 npm 有什么区别？lockfile 为什么应该提交？

知识点详解：包文件复用与依赖版本固定怎么配合

共用的是包内容，不是整个应用环境

假设两个项目都使用同一个工具库版本。pnpm 的内容寻址存储可以复用包内容，不必每个项目都从零保存同样的文件。

项目中仍然要建立依赖关系。官方结构示意中，包文件进入虚拟存储，链接组织“谁依赖谁”，直接依赖再成为项目可见入口。文件导入的具体方式会受配置和文件系统影响，不必把所有安装都说成同一种硬链接操作。

项目 A 依赖库的一个版本、项目 B 依赖另一个版本，可以各自形成相应依赖图。共用存储不是让两个项目在同一个全局 node_modules 里互相覆盖。

默认结构也不代表绝对没有提升依赖的行为。hoist 等配置会影响可见性；不能把“更明确的依赖关系”说成所有环境下都禁止任何未声明依赖访问。

版本范围回答允许什么，锁文件回答选中了什么

例如清单允许某个库的兼容版本。今天和下个月重新解析，可能得到不同版本，间接依赖也可能变化。

lockfile 保留这一轮解析结果，让团队安装时尽量回到同一张依赖图。它不仅服务直接依赖，间接依赖和 peer dependency 组合也需要被处理。

所以它通常应当跟随应用项目提交。更新依赖时，应同时审查清单与锁文件变化，而不是只看清单中一行数字。本文讨论 Node 包管理器，Python 有自己的锁定方案，不把 pnpm 的目录结构伪装成 Python 实现。

冻结安装，是让意外变化早点暴露

冻结锁文件安装要求清单与锁文件匹配，需要更新时就失败，而不是悄悄重新选择一组版本。pnpm 在满足条件的 CI 环境中有相应默认行为，也可以显式使用 --frozen-lockfile。

安装失败后，先确认是不是清单改了但锁文件没提交、包管理器版本不一致，或者 peer 关系变了。删锁文件虽然可能让安装继续，却也可能把本次无关的依赖全部更新。

锁文件冲突同样要按依赖变更意图解决，然后重新验证。保留下来的文件能够被解析，不代表依赖组合就满足项目需求。

可复现，还需要把环境一起固定

Node 版本、包管理器版本、操作系统、CPU 架构、原生模块和安装脚本，都可能影响结果。锁文件不会把这些条件自动冻结。

团队可以声明包管理器版本，在 CI 中使用一致运行时，并明确哪些依赖需要构建脚本。私有 registry 和包完整性也要纳入检查。

验收时用干净环境安装和构建，记录真实失败原因。不要把缓存命中后的“这次能跑”，当成任何机器都能复现的证明。

本题机制参考：pnpm：node_modules structure、pnpm：install。

面试官继续追问

pnpm 所有项目共用同一个 node_modules 吗？

不是。复用包内容与项目依赖树是两层，每个项目仍有自己组织的依赖关系。

package.json 写死直接依赖版本，就不需要 lockfile 了？

间接依赖、peer组合和其他解析条件仍可能变化，应用项目通常仍需要锁文件。

冻结安装失败，可以关闭冻结继续发版吗？

先查失败原因。只有明确需要更新依赖并完成审查验证时，才更新锁文件，不把关闭检查当通用修复。

面试速记卡

• 存储：内容寻址复用包文件。
• 结构：每个项目仍有独立依赖图，链接组织关系。
• 清单：表达依赖要求；锁文件：记录解析结果。
• CI：冻结安装，让清单和锁文件不一致早点失败。
• 复现：运行时、包管理器、平台与脚本也要固定。