确认 symlink 是否生效：Linux/macOS 运行 ls -la vendor/vendor/name，输出含 -> 才成功；Windows 用 dir vendor endor ame，需见 JUNCTION，否则已静默 fallback 至复制模式。
软链接失效不是 Composer “坏了”，而是它已经静默 fallback 到复制模式——你改本地代码，运行时加载的仍是 vendor 里那份旧副本。必须用 ls -la 看真实文件类型，不能信 composer install 的输出。
怎么确认 symlink 真生效了？
别看 composer show --path，它只返回 vendor 下路径，不反映底层是链接还是复制。
- Linux/macOS：运行
ls -la vendor/vendor/name，输出中含->（如monolog/monolog -> /abs/path/to/monolog）才表示链接成功 - Windows：用
dir vendor endor ame，看到JUNCTION或<symlinkd></symlinkd>才对；普通目录结构说明已 fallback - Docker/WSL 中
ls -la显示<symlink></symlink>但readlink -f vendor/vendor/name报错，大概率是宿主机路径挂载不一致，链接目标不可达
为什么本地改了代码，项目里完全没反应？
根本原因不是 autoload 没刷新，而是 symlink 根本没建起来，运行时加载的是 vendor 里的静态副本。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 关键不在主项目的
repositories里配"symlink": true，而在于**本地包自己的composer.json必须包含"options": {"symlink": true}** - Windows 用户必须以管理员身份运行终端，否则
mkdir和symlink权限被拒，Composer 不报错、直接走复制逻辑 - 路径末尾不能带
/，"url": "../my-pkg/"会被 Composer 完全忽略该仓库 - Docker 场景需加
--cap-add=SYS_ADMIN，且挂载方式要透传权限（例如-v $(pwd)/../my-pkg:/workspace/my-pkg不行，得用绑定挂载并确保宿主机路径可被容器内解析）
如何强制重建 path 依赖的关联？
删 vendor + composer install 不一定管用——如果 symlink 条件仍不满足，它会再次 fallback 到复制。
- 先验证本地包
composer.json是否有"options": {"symlink": true}，没有就补上 - Linux/macOS：删掉对应 vendor 子目录，再运行
composer install --no-cache（避免从缓存解压旧副本） - Windows：管理员权限打开 PowerShell，删
vendor endor ame，再执行composer install - CI/CD 环境中，
repositories.path指向的目录往往不存在，Composer 会静默 fallback 到 dist 安装（如果有 dist 配置）或失败——务必确保该路径在构建阶段真实存在且可读
autoload 映射为何不包含本地包？
即使 symlink 成功，类仍 Class not found，大概率是 autoload 没扫到你的命名空间。
- 运行
composer dump-autoload -v，看输出里是否出现你的命名空间（如App）；没出现说明composer.json的autoload配置根本没被识别 - 检查本地包
composer.json中 PSR-4 前缀末尾是否有反斜杠（"App\": "src/"✅，"App": "src/"❌） - 打开
vendor/composer/autoload_psr4.php，搜索你的前缀，确认映射路径是绝对路径（如$baseDir . '/src'），再手动检查该路径下是否存在对应 PHP 文件 - 文件含 BOM、短标签未启用、或存在
.php.bak这类非法后缀文件，也会导致 autoload 解析中断
最隐蔽的坑是：你以为在改源码，其实运行的是 vendor 里的副本；最常被忽略的点是——本地包自己的 composer.json 缺 options，其他所有操作都白搭。
