composer update会破坏path软链接，因其重走依赖解析流程，若本地路径失效、权限不足或配置缺失，将静默fallback为硬复制；恢复需手动删除vendor目录后指定包名更新并验证->符号。
composer update 为什么会破坏 path 类型的软链接
因为 composer update 默认重走整个依赖解析流程，会重新判断仓库类型、重新安装包——如果项目配置了 "symlink": true，它会尝试重建 symlink；但如果本地 path 目录结构变化（比如删了 composer.json）、路径失效、或权限不足，Composer 就会 fallback 到硬复制，导致原本的软链接被替换成真实文件夹。
更隐蔽的问题是：即使 symlink 成功重建，composer.lock 里记录的仍是 "source": {"type": "path", ...}，但 CI 或其他环境没配对应 repositories，就会静默拉取 packagist 上的 dist 包，彻底丢失本地改动。
如何确保 path 依赖的 symlink 不被覆盖
关键不是“防止覆盖”，而是让每次安装都稳定走 symlink 路径。必须同时满足四个条件：
- 项目根目录
composer.json的config段明确写"symlink": true（不能只靠全局配置） -
repositories中的url是相对路径（如"../my-local-package"），且该目录下存在合法composer.json - 本地包的
composer.json中name字段与主项目require中的包名完全一致 - 执行的是
composer update vendor/name（指定包名），而不是无参数的composer update——后者可能触发其他 path 包的重解析，连带破坏目标链接
验证是否生效：运行 ls -la vendor/vendor/name，输出中必须含 -> 符号；若显示为普通目录，说明 fallback 到 copy 了。
Windows 下 symlink 失败却不报错，怎么排查
Windows 默认禁止非管理员创建符号链接，Composer 会静默 fallback 到 copy，并只在详细日志里输出一行：Creating symlink for vendor/name failed, falling back to copy。
排查步骤：
- 用
composer update -v vendor/name重跑，搜索日志中的falling back - 确认当前终端是否以管理员身份运行（CMD/PowerShell）
- 手动测试：
cmd /c mklink /D test-link "C:\some\dir"，看是否提示“拒绝访问” - 若确定系统策略限制，就别设
"symlink": true，改用硬复制 +autoload.files补丁方式调试
已有的 symlink 被 update 覆盖成文件夹，怎么恢复
Composer 不会自动把已存在的硬复制目录转回 symlink，必须手动干预：
- 先删掉
vendor/vendor/name整个目录（不要只删内容） - 确认
composer.json中repositories和require配置无误 - 运行
composer update vendor/name（必须指定包名） - 检查
vendor/vendor/name是否变回 symlink；若仍失败，加-v看 fallback 原因
真正容易被忽略的是：一旦 vendor/ 里混入了硬复制的本地包，后续所有 composer update 都不会主动修复它——你得记得它不是“自动同步”的，而是“一次性链入后靠你维护”的状态。
