composer怎么清理已下载缓存_composer怎么释放磁盘占用空间【手册】

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%ComposerCache
• 该命令不会提示“成功”，只在终端输出类似 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）本身不大，但它们的依赖可能被重复安装（比如多个包都 require symfony/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 往往比项目里还臃肿，而且没人记得它存在。