composer install忽略已存在的vendor符号链接，因它不校验软链目标有效性，仅按composer.lock安装；损坏链接需用find -type l ! -exec test -e {} \; -print手动排查，dump-autoload不检查路径存在性，故无法暴露该问题。
composer install 时为什么忽略已存在的 vendor 符号链接
Composer 默认在执行 composer install 或 composer update 时，不会主动校验 vendor/ 下现有符号链接是否仍指向有效路径。它只关心 composer.lock 声明的包版本和安装逻辑，若某个软链目标被手动删除或移动（比如开发中误删了本地 path repo 的源目录），Composer 不报错、不提醒、也不修复——导致后续 require 失败或类加载器找不到文件。
用 find + test 检查 vendor 中所有损坏的符号链接
最直接可靠的方式是绕过 Composer 自身命令，用系统工具扫描：find 配合 test -L 和 test -e 判断“是符号链接但目标不存在”：
find vendor -type l ! -exec test -e {} \; -print
说明：
-
-type l：只匹配符号链接文件 -
! -exec test -e {} \;：对每个链接执行test -e，取反（即目标不存在） -
-print：输出所有损坏链接路径
这个命令不依赖 PHP 环境，速度快，适用于 CI 脚本或本地快速诊断。注意：某些 Composer 插件（如 hirak/prestissimo）或自定义脚本可能在 vendor/ 写入非包级链接，需人工甄别是否属于误报。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
为什么 composer dump-autoload 不会暴露符号链接问题
composer dump-autoload 只重新生成自动加载映射（vendor/autoload.php 和相关 classmap），它读取的是 vendor/composer/autoload_*.php 中已记录的路径，而这些路径在安装时就被固化为绝对或相对字符串。即使某个符号链接已失效，只要 autoload 文件里还存着那个路径，dump-autoload 就照常运行，不会触发文件存在性检查。
换句话说：autoload 是“信任 vendor 目录结构完整”的前提下工作的。一旦链接损坏，错误通常出现在运行时（Class not found），而非 dump 阶段。
修复前先确认是否真由符号链接引起
遇到类加载失败时，别急着删 vendor 重装。先定位具体缺失路径：
- 看报错中的类名，反推它该在哪个包里，例如
MyCompany\Utils\Helper→ 查vendor/mycompany/utils/src/Helper.php - 用
ls -la vendor/mycompany/utils看是否为指向不存在路径的软链 - 检查该包是否是
path类型仓库：查看composer.json中"repositories"是否含"type": "path"，且对应"url"路径是否仍可访问
真实项目里，符号链接失效往往只影响少数几个本地开发用的 path 包；生产环境用 dist 方式安装的包几乎不会出现此问题。盲目 rm -rf vendor && composer install 可能掩盖配置偏差，不如精准定位再清理。
