composer clear-cache仅删除COMPOSER_HOME/cache下的已下载包、元数据和安装器缓存，不删vendor/或composer.lock；清理后下次install仍重下包，仅跳过本地解压缓存。
composer clear-cache 会删掉哪些文件
它只清理 COMPOSER_HOME/cache 下的已下载包（.zip、.tar）、元数据（repo 目录）和安装器缓存（archived），但不会动 vendor/ 或项目根目录下的 composer.lock。也就是说，执行后下次 composer install 仍会重下包，只是跳过本地解压缓存环节。
常见错误现象：composer clear-cache 后磁盘空间没明显变化——大概率是因为你真正占空间的是 vendor/，不是缓存目录。
- 用
du -sh ~/.composer/cache/*（Linux/macOS）或dir %COMPOSER_HOME%\cache（Windows）先确认缓存实际大小 -
COMPOSER_HOME默认是~/.composer（Unix）或%APPDATA%\Composer（Windows），但可能被COMPOSER_HOME环境变量覆盖 - 某些公司镜像源会把完整包缓存在本地，这类缓存不在
clear-cache范围内，得手动删cache/vcs/或镜像配置目录
vendor 目录才是磁盘占用大头，怎么安全清理
删 vendor/ 本身不危险，但必须确保有可用的 composer.lock，否则 composer install 可能装出不一致的依赖版本。没有 lock 文件时，强制用 composer install --no-dev 也比留着旧 vendor 更可控。
使用场景：CI 构建机、Docker 构建缓存层、本地开发频繁切分支导致 vendor 积累多个版本。
- 删前先检查：
ls -la vendor/ | head -n 5看有没有异常大的包（比如phpstan/phpstan或前端工具类） - 想保留部分包（如私有 repo 的本地路径包），别直接
rm -rf vendor，改用composer dump-autoload+ 手动删特定子目录 - Docker 中建议在
composer install后加RUN rm -rf ~/.composer/cache，避免缓存层膨胀
“强制”删除失败时的三个真实原因
报错 Failed to remove ... Permission denied 或静默无反应，通常不是命令问题，而是权限、进程占用或符号链接干扰。
性能影响：缓存目录被其他 Composer 进程（如后台 composer update）锁定时，clear-cache 会卡住几秒再失败，不是死循环。
- Windows 上杀不干净的
php.exe进程常锁住缓存文件，任务管理器里关掉所有 PHP 进程再试 - macOS/Linux 下用
lsof +D ~/.composer/cache查谁在读写该目录 - 如果
~/.composer/cache是软链接到 NAS 或挂载盘，某些文件系统不支持原子删除，得先cp -r到本地再删原链接
长期节省磁盘的两个硬核配置
不用每次手动清，让 Composer 自己少存东西。这两个配置加进 ~/.composer/config.json（全局）或项目 composer.json（局部）都生效。
- 禁用 ZIP 缓存：
"cache-files-ttl": 0，让包下载后不解压留档，下次直接用网络流安装（适合带宽足、磁盘小的环境） - 限制元数据缓存时间：
"cache-repo-ttl": 1800（单位秒），避免packagist.org元数据越积越多 - 注意：
"cache-files-maxsize"参数在 Composer 2.5+ 才支持，旧版本设了也无效，得升级
最常被忽略的是：composer self-update 升级后，旧版本的缓存结构可能残留，这时 clear-cache 不会自动清理旧格式目录，得手动进 cache/ 看有没有 files-v1/ 这类废弃子目录。
