根本原因是 symlink 未生效或 name/path 不匹配；需确认本地包 composer.json 含 "options": {"symlink": true}、主项目 require 与 repositories 中 name/url 严格一致，并执行 composer dump-autoload -o 刷新 autoload 映射。
Composer 更新 path 本地依赖无效，根本不是缓存没清干净，而是 symlink 没生效或 name/path 不匹配——清缓存本身对 path 仓库几乎没用。
为什么 composer update 后本地 path 包代码没变？
path 类型仓库默认优先创建符号链接（symlink），但失败时会静默 fallback 到 copy 模式。你改了本地源码，vendor/ 里还是旧副本，说明 symlink 根本没建成功。
-
composer.json中的name必须和require字段逐字一致：大小写、分隔符（只允许短横线-）、vendor 名全对齐，"acme/utils"≠"Acme/utils" - 本地包的
composer.json必须含"options": {"symlink": true}—— 主项目配这个没用，必须在本地包自己里面声明 - 路径
url必须指向**含composer.json的目录**，且是相对于主项目根目录的路径（如"../my-utils"），末尾不能带/ - Windows 下必须以管理员身份运行终端；Docker 容器需加
--cap-add=SYS_ADMIN，否则 symlink 创建失败且无提示
怎么确认 symlink 是否真生效？
别猜，直接看文件系统行为。符号链接一旦建立，修改本地源码会实时反映到 vendor/，无需重装。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- Linux/macOS：
ls -la vendor/acme/utils，输出含->箭头才表示是 symlink - Windows：
dir vendor\acme\utils，看到JUNCTION或SYMLINKD才对 - 如果显示为普通文件夹，说明 fallback 成了 copy，立刻检查本地包的
composer.json是否漏了options段
autoload 不更新、类找不到怎么办？
symlink 生效 ≠ 类能自动加载。Composer 只管把包“挂”进来，autoload 映射是否包含真实路径，得靠 dump-autoload 显式刷新。
- 执行
composer dump-autoload -o（优化模式）强制重建映射，尤其当你改过本地包的autoload配置后 - IDE（如 PhpStorm）断点不触发？检查 IDE 设置里的路径映射是否与磁盘真实路径一致（例如 WSL 路径 vs Windows 路径）
- 若本地包用了
psr-4或classmap，确保其composer.json里路径写的是相对自身根目录的路径（如"src/"），不是相对于主项目的
哪些操作纯属浪费时间？
很多人一遇到 path 依赖不更新就狂清缓存，结果毫无作用——因为 path 仓库压根不走 ~/.composer/cache/files/ 这套 ZIP 缓存逻辑。
-
composer clear-cache对 path 仓库完全无效：它只清远程包的 ZIP 和元数据，不影响本地路径解析 -
composer update --no-cache也不会触发 symlink 重建：它只跳过远程缓存，不干预本地仓库挂载逻辑 - 手动删
vendor/acme/utils再composer update，大概率又 fallback 成 copy，除非先修复 symlink 条件
真正关键的只有三件事：本地包 composer.json 里有 "options": {"symlink": true}、主项目 require 和 repositories 中的 name/url 完全匹配、执行 composer dump-autoload -o 刷新映射。其他所有“清缓存”动作，都是在掩盖配置问题。
