执行 composer clear-cache 前必须先运行 composer config --global cache-dir 确认真实路径，再用 du -sh（linux/macos）或资源管理器属性（windows）检查占用，超1.5 gb且半年未用才值得清理；它默认不删vcs/目录，需手动补删或禁用 cache-vcs。
执行 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：把路径粘贴进资源管理器地址栏 → 右键“属性”
不到 200 MB 基本不用管；超 1.5 GB 且半年没碰老项目，才值得清理。
composer clear-cache 默认不清理 vcs/ 目录，但它最占空间
这是最容易被忽略的坑。clear-cache 只清 files/（ZIP/TAR 包）、repo/（元数据），但默认跳过 vcs/——而一个 Git 裸仓库（比如 Laravel 或 Symfony 的完整克隆）就吃掉 300–800 MB，还耗尽 inode。
手动补删才能真正释放空间：
- Linux/macOS：
rm -rf ~/.composer/cache/vcs/* - Windows：
rd /s /q "%APPDATA%\Composer\Cache\vcs"
若想一劳永逸，可禁用该缓存：composer config --global cache-vcs false，后续所有 Git 包强制走 --prefer-dist 安装。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
CI/CD 或无交互环境里卡住，是因为缺 --no-interaction
在 GitHub Actions、GitLab CI 或 Docker 构建中，composer clear-cache 默认会等待用户确认，导致构建直接 hang 住。
必须加参数避免阻塞：
- 安全预检：
composer clear-cache --no-interaction --dry-run，确认输出路径是否指向预期位置（比如 NFS 挂载点而非本地 SSD） - 正式执行：
composer clear-cache --no-interaction
如果仍卡住，说明有后台进程锁着缓存目录：
- Linux/macOS：
lsof +D $(composer config --global cache-dir) - Windows：
handle.exe -p php.exe（需 Sysinternals 工具）
清完后装包变慢、装错版本？不是命令问题，是机制使然
clear-cache 后首次 composer install 变慢，是设计行为，不是故障：
-
repo/缺失 → 每次都要 HTTP 请求拉取packages.json -
files/缺失 → 所有 ZIP 都得重下，含大前端资产的包（如laravel/ui）尤其明显
装错版本？大概率不是缓存没清干净，而是：
-
composer.lock锁死了版本（它不受clear-cache影响） - 镜像源元数据 TTL 未更新（通常 24 小时）
- 你改了私有包 tag 却没触发远程校验——这时清缓存才真有用
真正影响代码生效的从来不是 Composer 缓存，而是 PHP OPcache；clear-cache 对它完全无效，必须重启 php-fpm 或调用 opcache_reset()。
