composer clear-cache 仅清理 ~/.composer/cache/ 下的包归档、解压包及元数据缓存，不触碰 vendor 目录、lock 文件或重装依赖；执行后项目正常，但下次 install 会重新下载压缩包。
composer clear-cache 命令到底清什么
它只清理 ~/.composer/cache/ 下的包归档（.zip/.tar）、已解压的 dist 包、以及部分元数据缓存，**不碰 vendor 目录、不删 lock 文件、不重装依赖**。你执行后项目照常运行，但下次 composer install 会重新下载压缩包——这点常被误以为“清缓存=重装”，其实不是。
常见错误现象：composer clear-cache 后磁盘空间几乎没变化？大概率是因为你真正占空间的是 vendor/，不是缓存目录。
- Linux/macOS 缓存路径固定为
~/.composer/cache/；Windows 是%APPDATA%\Composer\Cache - 该命令不会提示“成功”，只在终端输出类似
Clearing cache (12.4 MiB)的行，没输出≠失败 - 若提示
Permission denied，说明某些缓存文件属主不是当前用户（比如用sudo composer install留下的），得手动chown -R $USER ~/.composer/cache
vendor 目录才是磁盘占用大头
一个中等规模 Laravel 项目，vendor/ 动辄 300MB+，而缓存通常不到 50MB。想真正释放空间，得处理这里，但不能乱删——rm -rf vendor 后不 composer install，项目直接崩。
使用场景：CI 构建机磁盘告急、本地开发环境多年未清理、或切换 PHP 版本后旧扩展残留。
- 安全清理方式是先删
vendor/，再用composer install --no-dev（省掉测试依赖） - 如果只是临时腾空间，可改用
composer install --prefer-dist --no-dev，跳过源码克隆，强制走压缩包安装，体积更小 - 注意
composer.lock必须存在，否则install会按composer.json重新解析依赖树，可能升版、出错
怎么查清楚到底哪块吃空间
别猜，直接看。Composer 自己不提供磁盘分析工具，得靠系统命令定位热点。
Linux/macOS 下快速定位：
du -sh ~/.composer/cache/* | sort -hr | head -5 du -sh vendor/* | sort -hr | head -5
常见错误现象：看到 vendor/composer 占几十 MB 就慌——其实那是 autoload 映射和安装脚本缓存，删了下次 autoload 慢一点，但无害；真要命的是 vendor/nikic/php-parser 这类带大量测试/文档的包。
-
vendor/bin/下的二进制（如phpunit、phpstan）本身不大，但它们的依赖可能被重复安装（比如多个包都 requiresymfony/console），这是 Composer 无法自动 dedupe 的 - Windows 用户注意：
du不可用，改用Get-ChildItem vendor -Recurse | Group-Object Extension | Sort-Object Count -Descending（PowerShell）
长期节省空间的配置项
不是每次都要手动清，几个配置能从源头压体积。
生效位置：全局配置（~/.composer/config.json）或项目级 composer.json 的 config 段。
- 加
"apcu-autoloader": true：减少vendor/composer/autoload_*.php的文件 IO，不省磁盘但降 I/O 压力 - 设
"fxp-asset": {"enabled": false}：禁用已废弃的fxp/composer-asset-plugin，避免额外拉取前端包 - 慎用
"archive-format": "tar"：虽然 tar 比 zip 略小，但某些网络环境解压失败率高，得不偿失
最有效的其实是定期删掉不用的全局工具：比如 composer global remove phpunit/phpunit，全局 vendor 往往比项目里还臃肿，而且没人记得它存在。
