清 Composer 缓存不能解决镜像源未生效的问题，但能强制重新拉取元数据——前提是镜像配置已正确写入 repositories.packagist.org 且未被项目级 repositories 字段覆盖，否则清缓存无效。
清 Composer 缓存不能解决镜像源未生效的问题，但能强制让 Composer 重新拉取镜像元数据——前提是镜像配置已正确写入，否则清了也白清。
先确认镜像源是否真生效
很多人切了阿里云或腾讯云镜像后还报 404，第一反应是“缓存没清”，其实根本没配对。执行以下命令验证：
-
composer config -g repos.packagist—— 输出必须含"url": "https://mirrors.aliyun.com/composer/"这类地址，不是packagist.org - 若输出为空或仍是官方源，说明
config -g repos.packagist没执行成功，或被COMPOSER_HOME覆盖导致写错位置 - 私有源用户还要检查
auth.json是否在~/.composer/auth.json（Linux/macOS）或%APPDATA%\Composer\auth.json（Windows），token 是否过期
清缓存前必须看真实路径和大小
默认路径不等于实际路径。公司环境常通过 COMPOSER_CACHE_DIR 或 CI 配置挂到 NFS，composer clear-cache 只清 composer config --global cache-dir 返回的那个目录。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 查路径：
composer config --global cache-dir - 看大小：Linux/macOS 执行
du -sh $(composer config --global cache-dir)；Windows 直接打开资源管理器，粘贴路径后右键“属性” - 不到 200 MB 别清；超 1.5 GB 且半年没碰老项目，才值得动手
- 如果路径显示
/mnt/nfs/composer-cache，说明缓存不在本地磁盘，清它可能影响其他构建节点
用 --dry-run 和 --no-interaction 避免 CI 卡住
GitHub Actions、GitLab CI 等无 TTY 环境下，composer clear-cache 默认会卡在交互确认。不加参数就是等死。
- 预检用：
composer clear-cache --dry-run—— 只输出将删的路径，不删文件，确认是否指向预期位置 - 真正执行加：
composer clear-cache --no-interaction - 如果仍卡住，可能是后台有
composer install进程锁着缓存目录，Linux/macOS 用lsof +D $(composer config --global cache-dir)查，Windows 用handle.exe -p php.exe
vcs/ 目录最占空间，但 clear-cache 默认不删它
composer clear-cache 默认清 files/、repo/、vcs/，但某些旧版 Composer 或 CI 镜像里，vcs/ 被跳过——而它单个 Git 裸仓库就能吃掉 300–800 MB。
- 手动清 vcs：
rm -rf ~/.composer/cache/vcs/*（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows） - 清完再跑
du -sh $(composer config --global cache-dir)，才能看到真实释放量 - 别乱动
repo/packagist.org/—— 这是核心索引，删了会导致首次composer update明显变慢 - 清完后首次装包变慢是正常现象，不是命令失败；缓存本就是加速层，不是永久存储
真正容易被忽略的是：镜像源的 CDN 缓存（比如阿里云、腾讯云）和私有源的 X-Composer-Cache-TTL 响应头，本地清了缓存也刷不掉它们。要验证是否真同步，得临时切回官方源对比结果。
