pnpm highest 仍选旧版：共享解析复用了另一项目的范围

工作区根项目要求 ajv: ^6.0.0，子项目写 ajv: *，即使设置 resolutionMode: highest，子项目仍得到 Ajv 6。先核对是否共享解析，以及另一个项目是否提供了可复用的较低版本，再检查 registry 的候选列表。

这一具体结果在 pnpm 12.15.0 中出现，11.28.6、10.30.1 也有相同表现。星号允许较低版本，并不表达“业务需要 Ajv 8 的接口”；highest 也不能替代消费者自己的兼容约束。

先明确业务真正需要哪个主版本

如果子项目确实使用了 Ajv 8 的接口，把它的依赖要求写成经项目审查的 8 系列范围，而不是 *。下面只说明清单局部形状：

{
  "dependencies": {
    "ajv": "^8.0.0"
  }
}

这项改动要求子项目真的兼容 8 系列，并审查实际锁定版本；不能因为版本更高就跳过 API、schema 与插件兼容性检查。根项目仍需要 6 时，可以保持自己的范围，允许依赖图同时容纳两个主版本。

受影响的共享解析先利用其他项目已有的候选。较低版本满足 * 时，宽范围的项目便可能沿用它。清空 store 不会改变这个约束关系，删除整个锁文件还会连带重选其他依赖，不适合用作默认处理。

独立锁文件会改变工作区管理方式

确实需要各项目独立解析、且团队能接受分开维护锁文件时，可评估 sharedWorkspaceLockfile: false。这会改变锁文件位置、安装和 CI 约定，不是给某一个依赖开启“总选最高”的小开关。需要同时审查工作区脚本、缓存键和可重复安装流程。

已有锁文件还会保留已解析版本，不能只修改 resolutionMode 就认定所有包会重新选择。通过项目既有的定向更新入口调整目标依赖，保存清单与锁文件，并检查其余项目是否发生非预期变化。

当前正式 12.15.0 不应被当作已具备新的独立范围解析行为。后续采用正式版本时，还需分别检查普通安装、pnpm dedupe、autoDedupe 和 peer dependency 条件；它们可能有各自的复用规则，不能从一组普通依赖推到所有情况。

验收对照每个项目自己的清单要求、lockfile importer 与实际解析入口，确认根项目继续使用其兼容版本，子项目得到所需主版本，再完成两边原有测试。目标是依赖图满足各自契约，而不是让所有项目的版本号看起来一致。