composer clear-cache 是 Composer 自身保证的原子操作，确保缓存目录完整删除或完全不删，但依赖用户权限与路径正确性；清空后装包变慢属正常设计，非命令失效。
composer clear-cache 是原子操作，但实际效果取决于权限和路径
它不是系统级原子（比如 SQLite 的事务），而是 Composer 自身保证「删完或不删」——不会出现只删一半子目录的情况。但前提是：当前用户对 ~/.composer/cache 下所有子目录都有写权限，且没被其他进程锁住文件。
常见失败现象：Cache directory does not exist 或删完后 du -sh $(composer config --global cache-dir) 体积不变。这时候不是命令失效，而是它清的是另一个路径（比如你设过 COMPOSER_CACHE_DIR 环境变量但 shell 没重载），或者缓存目录属主是 root（之前用 sudo composer install 过）。
- 先运行
composer config --global cache-dir确认真实路径 - 再用
ls -ld $(composer config --global cache-dir)看属主和权限 - 如果属主是 root，就该用
sudo composer clear-cache；如果是普通用户但提示 permission denied，检查父目录~/.composer是否可写
想只清某类缓存，得手动进目录删子目录
composer clear-cache 没有 --type=files 这类参数，所谓“精准”只能靠手操。它默认删 repo/（包索引）、files/（zip 包）、vcs/（git 克隆裸库）、archives/（解压中间产物）四个子目录。其中：
-
files/占空间最大，删它最能释放磁盘（尤其含大前端资产的包） -
vcs/安全可删，下次需要时自动重建，不影响功能 -
repo/删了会导致首次composer update卡很久（要重新拉 packages.json） - 别碰
repo/packagist.org/外的其他 repo 子目录，有些私仓配置会依赖它
示例（Linux/macOS）：rm -rf ~/.composer/cache/files/*、rm -rf ~/.composer/cache/vcs/*
CI/CD 或 Docker 里清理缓存容易权限错乱
构建镜像时如果用 root 跑过 composer install，后续非 root 用户（如 GitHub Actions 的 runner 用户）执行 composer clear-cache 就会失败——因为 ~/.composer/cache 下某些子目录属主是 root。
- Dockerfile 中统一用非 root 用户安装依赖：加
USER app再跑composer install - GitHub Actions 中避免混用
run: sudo composer ...和run: composer ... - CI 脚本开头加一句
sudo chown -R $USER:$USER ~/.composer/cache（仅限 Linux runner）
Windows GitHub Runner 或 macOS 上注意：环境变量 %APPDATA%\Composer\Cache 或 ~/Library/Caches/composer 可能被 IDE（如 PHPStorm）独占锁定，建议在 CI 中禁用 IDE 相关插件或加 sleep 2 避开扫描窗口。
清完缓存后装包变慢，这不是 bug 是设计
这是最常被误判为「命令没生效」的地方。清空 repo/ 后，composer install 第一次必须发起 HTTP 请求拉取所有包的元数据；清空 files/ 后，所有 .zip 都得重下——尤其是 laravel/ui、symfony/webpack-encore 这类带大 JS/CSS 的包，延迟更明显。
- 这不是缓存没清干净，是 Composer 故意不缓存「网络不可控部分」
- 如果你频繁清理又频繁装包，不如改用
composer self-update升级到 2.7+，新版对 ZIP 包做了 LZ4 压缩复用，长期看比反复清缓存更稳 - 真正吃磁盘的往往不是
~/.composer/cache，而是项目vendor/或/tmp下残留的解压临时文件，别只盯着一个地方猛删
