pnpm deploy 成功却少了依赖别名软链：检查项目复制阶段

pnpm deploy --prod 成功退出，依赖也能从部署目录正常加载，应用却因 .next/node_modules 下的别名缺失而启动失败。若这些别名是指向项目根 node_modules 的符号链接，先确认缺的是项目复制出的别名，还是依赖本身。

pnpm 12.15.0 中，默认与 legacy deploy 都可能丢掉这种选中的目录软链：源链接有效、最终目标也会安装进输出，但目标不属于复制项目文件的同一批集合。退出码 0 不足以证明生成产物完整。

依赖稍后出现，不能让复制阶段重新补回链接

例如项目的 files 包含 .next，其中有：

.next/node_modules/repro-dependency-alias
  → ../../node_modules/repro-dependency

repro-dependency 是说明结构的占位包名。源目录里链接有效，部署后根 node_modules 也有该包，缺少的可能恰好是中间这个 alias，而不是依赖本体。

正式 12.15.0 的复制实现会检查目标是否在当前导入文件集合中。未包含的目录目标可被视为已处理，却不创建链接；后面的依赖安装提供目标，也不会重跑这项项目别名复制。加 --legacy 因而不是这条路径的保证。

先核对 files、忽略规则、链接文本和目标的实际位置。如果 alias 本来就没被文件清单选中，或源链接已经悬空，应先修正生成与打包输入，不能把所有丢文件都归因于目录目标过滤。

在完整输出内核对并重建明确的别名

临时处理可在部署完成、依赖安装成功后，按经过审查的生成清单补建这些别名。必须确认输出里的目标已存在、链接最终仍落在允许的部署目录内，以及 alias 位置没有真实文件或已有不同链接。

对于上面这一种已核对的相对结构，下面只是 POSIX 命令形状，应在部署输出根执行，并替换占位名称：

ln -s ../../node_modules/repro-dependency .next/node_modules/repro-dependency-alias

命令假定父目录已存在，不带覆盖选项。发现已有条目时先停下核对，不能用强制覆盖去消除差异。Windows 的链接权限与部署协议另有要求，不要照搬 POSIX 命令。补建应来自可信产物清单，不能盲目恢复任意指向输出外部的软链。

这项步骤应纳入可重复的构建交付流程，保存链接路径与原始 readlink 文本，并同时检查下一次重新部署。它不修改 pnpm 的复制规则；后续采用正式修复时，应先在原产物上确认无需补建，再撤回临时步骤。

验收从 alias 路径解析依赖，确认最终真实路径位于部署输出内，再从应用原启动入口访问对应功能。还要比较应包含的普通文件和其他链接，避免只补一个显眼别名而遗漏同类条目。不要通过让生产进程继续引用源码工作区的 node_modules 来掩盖不完整产物。