每次 pnpm run 都先安装：检查 dedupePeers 与 pnpmfile 的组合

pnpm run 每次都先显示 Already up to date，再警告下次还会安装；脚本能运行，启动前却不断重复依赖检查。若刚切到 pnpm 12.15.0，检查 dedupePeers: true、活动的 pnpmfile 和最近的锁文件变化是否同时存在。

这一组合中，反复出现的提示包括 a lockfile setting drifted from the current configuration。即使 pnpmfile 的 readPackage 只是原样返回对象，也可能触发；不能单凭钩子存在就认定它篡改了依赖。

确认循环发生在运行前的证明阶段

先对照实际包管理器版本、workspace 设置、加载的钩子及锁文件变化。问题需要这三项共同条件：dedupePeers 为 true、确实加载 pnpmfile、锁文件相对上次验证发生变化。一次 Git checkout 带来的锁文件字节变化就可能重新触发。

12.15.0 的运行前检查策略把 dedupe_peers 写死为 false，而锁文件保存的是 true。比较结果因而一直漂移；启动的冻结安装发现依赖无需变化，却不能让这条检查记录成已证明的新鲜状态，下次 run 或 exec 又走一遍。

这不同于真正新增依赖后需要一次安装。先查重复提示是否指向 dedupePeers，不把所有运行前安装都当成缺陷。

保留配置时，普通 install 可恢复当前状态

保存清单、配置和锁文件，在受控工作目录按项目正常流程单独执行一次普通 pnpm install，审查它实际产生的差异，再重复原来的 run 或 exec，检查是否不再每次进入安装。安装会操作依赖目录，并可能调整锁文件，不能在含未备份手工修改的目录里随意验证。

这是一种当前状态的临时恢复：后续锁文件再次变化，12.15.0 的同一组合仍可能重现。不要把“刚装完能直接跑”写成这条版本缺陷已经消失。

如果团队准备临时固定其他已验证版本，应先确认其与锁文件、workspace 功能及原钩子的兼容性，统一本地和 CI 的实际入口。仅修改 packageManager 字段，而启动器仍调用另一份 pnpm，不能建立版本边界。

不要为了消除一次安装而撤掉有效策略

把 dedupePeers 改为 false、删除 pnpmfile 或跳过运行前依赖检查，都可能让这组条件不再成立，也会改变依赖策略或检查保障。尤其 pnpmfile 若承载必要包修正，移除后安装成功不代表生成了正确依赖树。

这里应保留原策略，等待并核对目标正式版是否让运行前检查使用真实 dedupePeers 配置。12.15.0 正式源码仍保留 false，不能在该版本上承诺永久恢复。

验收包含两步：普通安装后连续运行原脚本，确认没有无意义重复安装；再在隔离分支经历一次正常锁文件变化，确认目标版本只做必要的一次验证，并且脚本实际结果正确。保留新旧配置与锁文件成套回退，避免为了缩短启动而留下未验证的依赖。