composer clear-cache仅清理全局缓存中的repo/、files/、vcs/子目录，不触碰vendor/、composer.lock、项目文件、php临时目录（如sys_get_temp_dir()下的composer_*.zip）及opcache；vcs/默认被跳过，需手动删除以释放空间。
composer clear-cache 能清掉什么、不能清什么
composer clear-cache 是最常用也最安全的缓存清理命令，但它只作用于全局缓存目录下的 repo/、files/、vcs/ 三个子目录，不会碰 vendor/、composer.lock、项目文件或 Composer 全局配置。它也不清理 PHP 的临时目录（sys_get_temp_dir()），那里堆积的 composer_*.zip 或 php*.phar 文件得手动删。
常见误判：看到磁盘没变小，就以为命令失效——其实你真正想删的是 vendor/（一个 Laravel 项目常占 300–800 MB），而缓存本身可能才 42 MB；或者卡在 vcs/ 目录，它默认被 clear-cache 跳过，但单个 Git 裸仓库就能吃掉 300–800 MB 并耗尽 inode。
怎么确认缓存路径和真实占用？别删错地方
执行 composer config --global cache-dir 才能拿到 Composer 实际用的路径。这个路径可能被 COMPOSER_CACHE_DIR 环境变量或公司私有镜像覆盖，~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）未必是真实位置。
- Linux/macOS 查大小：
du -sh $(composer config --global cache-dir) - Windows：把
%APPDATA%\Composer\Cache粘贴进资源管理器地址栏 → 右键“属性” - 不到 200 MB 基本不用管；超 1.5 GB 且半年没碰老项目，才值得动手
CI/CD 里卡住？必须加 --no-interaction
在 GitHub Actions、GitLab CI 等无交互终端中，composer clear-cache 默认会等待确认，直接 hang 住。必须加 --no-interaction 参数。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
更稳妥的做法是先预检：composer clear-cache --no-interaction --dry-run，看输出路径是否指向预期位置（比如 NFS 挂载点而非本地磁盘）。如果仍卡住，说明有后台进程锁着缓存目录：
- Linux/macOS：
lsof +D $(composer config --global cache-dir) - Windows：
handle.exe -p php.exe（需 Sysinternals 工具）
手动删 vcs/ 和临时目录才是释放空间的关键
composer clear-cache 不清 vcs/，但它是缓存里最占空间的子目录。一个旧项目的 Git 裸仓库就可能占满几百 MB，还容易耗尽 inode。必须手动清理：
- Linux/macOS：
rm -rf ~/.composer/cache/vcs/* - Windows：
rd /s /q "%APPDATA%\Composer\Cache\vcs"
另外，sys_get_temp_dir() 下的残留文件也要扫一遍，尤其是 composer_*.zip 和 php*.phar——这些 clear-cache 完全不碰，却常是磁盘告警的真凶。
真正危险的操作不是 clear-cache，而是手动删时没确认 Composer 进程是否已退出；删到一半被写入，后续可能报 Corrupted cache。缓存路径、vcs 占比、临时目录这三处，漏掉任何一环，清理就等于白干。
