composer clear-cache能安全清理全局缓存中的files/、repo/、vcs/子目录，但不触碰vendor/、composer.lock、composer.json及项目文件；它仅作用于composer config --global cache-dir指定路径，不处理环境变量覆盖路径或内存/OPcache等其他缓存。
composer clear-cache 能清什么、不能清什么
直接运行 composer clear-cache 就能安全清掉全局缓存里的 files/（ZIP 包）、repo/（元数据快照）、vcs/（Git 克隆缓存），但它完全不碰 vendor/、composer.lock、composer.json，也不改任何环境变量或配置文件。
常见误判是：清完缓存后 composer install 还装旧版 → 那不是缓存没清干净，而是 composer.lock 锁死了版本，或者镜像源的 packages.json 还没更新（TTL 通常 24 小时）。
- 它只清理
composer config --global cache-dir指向的那个目录下的子目录，不会遍历其他路径（比如被COMPOSER_CACHE_DIR覆盖的位置） - Windows 用户要注意：
%APPDATA%\Composer\Cache是默认路径，但 CI 环境中可能被挂载到 NFS 或容器卷，clear-cache不会自动识别这些 -
vcs/目录默认被清，但单个 Git 裸仓库常占 300–800 MB 且耗尽 inode；如果空间没释放，大概率是这里卡住了，得手动删：rm -rf ~/.composer/cache/vcs/*（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows）
怎么确认当前缓存路径和真实占用
很多人执行 composer clear-cache 后发现磁盘空间没变化，根本原因是删错了位置。Composer 实际用的缓存路径可能被 COMPOSER_CACHE_DIR 环境变量或公司镜像覆盖，~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）未必是真实路径。
- 查真实路径：
composer config --global cache-dir - Linux/macOS 查大小：
du -sh $(composer config --global cache-dir) - Windows：把
%APPDATA%\Composer\Cache粘贴进资源管理器地址栏 → 右键“属性” - 不到 200 MB 基本不用管；超 1.5 GB 且半年没碰老项目，才值得动手
镜像配置写对了但没生效？三要素必须全对
命令跑完没报错，但 composer install -vvv 日志里仍出现 packagist.org 或 codeload.github.com，说明镜像根本没接管。静默失效最常见于三个细节出错：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 键名必须是
repo.packagist（不是repos.packagist，多一个s就写进无效字段） - 中间必须显式写
composer作为type值：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - URL 必须带末尾斜杠且为 HTTPS：
https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少/会拼错路径，返回 404 后静默回退）
验证是否生效：运行 curl -I https://mirrors.aliyun.com/composer/，应返回 200 OK 或 301 Moved Permanently；再跑 composer install -vvv | grep "resolving packages"，看请求域名是不是镜像地址。
CI/CD 里卡住或清缓存不生效？先看执行主体和锁进程
在 GitHub Actions、GitLab CI 等无交互环境中，composer clear-cache 默认会等待确认，直接 hang 住。
- 必须加
--no-interaction；建议先加--dry-run预检：composer clear-cache --no-interaction --dry-run，确认输出路径是否指向预期位置（比如 NFS 挂载点而非本地磁盘） - 如果仍卡住，说明有后台进程锁着缓存目录：
lsof +D $(composer config --global cache-dir)（Linux/macOS），或handle.exe -p php.exe（Windows，需 Sysinternals 工具） - 更隐蔽的问题是执行用户错位：你在 root 下配了
repo.packagist，但 PHP 进程以www-data或git用户运行，它只读自己家目录下的配置。查composer config --global home输出的路径，必须和当前运行 Composer 的用户实际可访问的$HOME/.composer一致
真正难搞的从来不是命令本身，而是缓存路径、执行用户、镜像 URL 三者之间那层看不见的错位——漏掉任意一环，clear-cache 就只是在正确的地方做了一件无关的事。
