清除缓存后仍报错，根本原因在于权限残留、元数据滞后、zip损坏或autoload未重建；需分别修复属主权限、手动清理repo目录、精准删除损坏zip、执行composer dump-autoload -o。
清除缓存后仍报错，说明问题根本不在缓存文件本身，而是缓存清理没触达真正出问题的环节——比如权限残留、元数据滞后、ZIP 文件损坏或 autoload 未重建。直接重跑 composer clear-cache 通常无效。
缓存目录权限错乱导致 clear-cache 静默失败
常见现象是命令返回 “Clearing cache (cache-dir)” 却 du -sh $(composer config --global cache-dir) 依然几百 MB，或者后续 install/update 还报 Permission denied。
- 根本原因是之前用
sudo composer install写入过缓存，导致部分子目录属主为 root，普通用户运行clear-cache会跳过这些目录，不报错也不清理 - 验证方式：
ls -ld $(composer config --global cache-dir)看输出里是不是root root - 修复命令（Linux/macOS）：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - Windows 用户需右键
%APPDATA%ComposerCache→ 属性 → 安全 → 编辑 → 给当前用户勾选“完全控制”
metadata 缓存未刷新导致 update 拉不到新版
composer update 显示 “nothing to install or update”，但 Packagist 上已有新版本，大概率是 repo 元数据卡在旧状态。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer clear-cache不会删~/.composer/cache/repo/https---packagist.org/下的 provider 和 packages.json，而 Composer 默认复用这些索引 - 必须手动清 repo 子目录：
rm -rf $(composer config --global cache-dir)/repo/https---packagist.org/ - 同时删掉
vendor/composer/installed.json（当前安装快照），否则update可能按旧快照做差异计算 - 删完立刻跑
composer update -v，盯住输出里是否开始拉取新的packages.json
ZIP 文件损坏但 clear-cache 没删干净
报 Failed to extract 或 Corrupted zip file，不是网络问题，而是 ~/.composer/cache/files/ 下某个 ZIP 实际结构损坏（如下载中断、磁盘写异常）。
-
composer clear-cache会清空整个files/，但 Composer 在重装时只比对哈希，不校验 ZIP 结构，可能跳过校验直接复用坏包 - 先定位具体包：看
composer install -v最后几行，找到类似Extracting vendor/symfony/console的日志，提取包名symfony/console - 进
files/目录模糊搜索并仅删对应 ZIP：ls -l *symfony*console*.zip（Linux/macOS）或 PowerShell 中Get-ChildItem "$env:APPDATAComposerCacheFiles" -Recurse -Filter "*console*.zip" - 别碰
repo/和vcs/目录——它们不参与解压 - 删 ZIP 后若还报错，说明
composer.lock里硬编码的dist.sha256值与新下载内容不匹配，必须同步删掉vendor/和composer.lock
autoload.php 没重建导致 Class not found
清完缓存、重装依赖后新类仍报错，不是缓存没清干净，而是 vendor/autoload.php 根本没被触发重建。
-
composer install默认会重建 autoload，但加了--no-scripts或--no-autoloader就会被跳过 - 改过
composer.json的autoload段（比如新增"App\": "src/"），但没手动运行composer dump-autoload - 最稳妥补救：
composer dump-autoload -o（必须加-o，否则 PSR-4 映射不会写入autoload_static.php） - 如果用了
classmap，加-a；开发中引入了autoload-dev类，加--dev - 验证是否真更新：
ls -l vendor/composer/autoload_*.php看修改时间，再var_dump(class_exists('Your\Class'))确认结果
最容易被忽略的是：缓存清理和 autoload 重建是两套独立机制。清完缓存不等于重装依赖，重装依赖也不等于 autoload 刷新——每个环节都得单独确认是否真正执行到位。
