pnpm 部署后冻结安装报锁文件过期：检查工作区包的 peer 记录

工作区里的安装正常，deploy 输出目录中再执行冻结安装却报 ERR_PNPM_OUTDATED_LOCKFILE，原因是本地目录包的 dependencies 与锁文件不匹配。若该工作区包声明了 peer，且 injectWorkspacePackages 为 false，应检查部署锁文件有没有保留 peer 元数据。

这里的旧路径会把 workspace 包转成 file: 包，snapshot 中已有解析后的 peer 依赖边，packages 对应项却没有原包的 peerDependencies、peerDependenciesMeta。pnpm 11 的冻结检查会据此拒绝；某些 12 版本会接受同一锁文件，元数据缺项仍需单独检查。

看的是包的声明，不只是快照里有无依赖

示意结构如下，lib 与路径都是占位：

packages:
  lib@file:../packages/lib:
    resolution: {directory: ../packages/lib, type: directory}
snapshots:
  lib@file:../packages/lib:
    dependencies:
      peer-provider: 1.0.0

如果原 lib 清单还声明 peer-provider 的 peer 范围，而 packages 项完全没有这项记录，便需要沿部署转换检查。snapshot 里的精确版本与包声明的 peer 范围用途不同，不应直接把一个复制到另一个位置就视为等价。

先保留源工作区的包清单、设置、锁文件和 deploy 输出，比较声明是否确实在转换时丢失。如果源清单刚改了依赖而没有更新锁文件，冻结失败本来就是应有保护，应先正常审查源锁文件。

用含元数据复制修正的正式实现重新部署

pnpm 12.15.0 的正式部署代码已从工作区包清单取得 peer 声明，并把 peerDependencies 与 peerDependenciesMeta 写进转换后的 packages 记录；发行说明也明确包含这项修正。项目允许采用该版本时，应从源工作区重新生成部署产物，不要只在旧目录里改一行 YAML。

跨主版本更新还要核对项目的配置、脚本许可、锁文件与 Node 支持范围。必须保留 11 系列时，应核实对应维护发行是否包含同一项元数据处理，再在独立输出中回归；不能由 12.15.0 的修正推定任意 11.x 同样具备。

关闭 --frozen-lockfile 可能让输出重新解析，也可能改变版本或 peer 绑定，掩盖部署转换的缺口。它不是长期的 CI 修复。将 injectWorkspacePackages 改为 true 也会改变工作区链接与复制语义，需要独立评估，不宜只为压掉错误而切换。

验收先检查部署包的 peer 声明与 packages 元数据一致，再用实际交付环境的包管理器完成冻结安装，确认没有无关锁文件变化。最后从消费 lib 的入口检查 peer 由预期依赖提供。安装成功与 peer 解析到正确实例必须分别确认；重复部署也应保持相同记录。