必须先执行composer clear-cache再换镜像，否则repo/下残留的旧源packages.json快照会导致Composer仍按旧规则解析，即使镜像配置正确也会404或拉错源；清空后下次update才从新镜像获取元数据。
镜像配置改了但还从旧地址拉包，先清 repo/ 子目录
改完 composer config -g repo.packagist 指向阿里云或腾讯云镜像后，composer update 仍请求 repo.packagist.org，不是配置没生效，而是 ~/.composer/cache/repo/packagist.org/ 里还存着旧源的 packages.json 快照。Composer 不会主动对比配置变更，它只按缓存里的元数据走。
- 必须运行
composer clear-cache，否则新镜像配置等于没开 - 更精准的做法是只删
~/.composer/cache/repo/下对应目录：rm -rf ~/.composer/cache/repo/packagist.org - 别碰
~/.composer/cache/files/——重下 ZIP 包耗带宽；也别动vcs/——重建裸仓库反而拖慢下次安装
clear-cache 不等于重装依赖，它不碰 vendor 和 lock 文件
composer clear-cache 只影响下载加速层，和版本决策完全无关。很多人清完缓存发现 composer install 还是装旧版，是因为 composer.lock 严格锁定版本号，缓存里有没有包、是不是最新版，对它毫无影响。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 想升级包，得改
composer.json里的约束（比如把"monolog/monolog": "^2.0"改成"^3.0"），再跑composer update monolog/monolog - 删
composer.lock后composer install会重算整棵树，容易引入冲突，慎用 -
clear-cache不会触发任何包重装，也不会修改vendor/或composer.json
升级 Composer 后必须手动清缓存，否则元数据解析失败
从 Composer 2.5 升到 2.6+ 时，repo/ 下的元数据格式、HTTP 缓存头校验逻辑都变了。旧缓存里的 packages.json 可能含已弃用字段，导致 composer update 报 Could not load package xxx in http://repo.packagist.org，甚至静默跳过某些包。
-
composer self-update只换二进制文件，完全不清理~/.composer/cache/ - 推荐组合执行：
composer self-update && composer clear-cache --no-interaction - CI/CD 中尤其要注意：加
--no-interaction，否则在 GitHub Actions 等非交互环境会卡住 - 如果只是小版本升级（如 2.6.1 → 2.6.3），通常不用清；但跨 minor 版本（2.5.x → 2.6.x）基本都要清
缓存占空间最多的是 vcs/ 目录，clear-cache 默认不删它
composer clear-cache 会清 files/、repo/、vcs/ 三个子目录，但实际使用中，vcs/ 单个 Git 裸仓库就能占 300–800 MB，而 files/ 通常只有几十 MB。默认命令清完你可能根本感觉不到磁盘释放——因为最肥的那块肉它没动。
- 查真实占用：
du -sh $(composer config --global cache-dir) - 确认路径是否被覆盖：公司可能通过
COMPOSER_CACHE_DIR把缓存挂到 NFS 或自建镜像目录，clear-cache默认只清cache-dir指向的位置 - 要真释放空间，得手动删：
rm -rf ~/.composer/cache/vcs/*（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows） - 删前确保没
composer install或update进程在后台跑，否则可能触发Corrupted cache file
clear-cache 执行后空间没变化，大概率是因为你删的根本不是 Composer 当前正在用的那个目录。 
