Composer update 生成大量缓存因默认缓存dist包、VCS仓库及元数据；禁用dist缓存执行composer config -g cache-dist false，禁用source缓存需配合cache-vcs false（但该选项不存在，实际需避免使用--prefer-source或手动清理vcs/）。
Composer update 为什么会生成大量缓存？
Composer 在执行 composer update 时，默认会把下载的包（包括 zip、dist、source）全部解压并缓存到 ~/.composer/cache/（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）。这些缓存包含：已下载的 dist 包（.zip/.tar.gz）、VCS 克隆的完整仓库（尤其是 dev 分支）、以及 Composer 自己生成的 packages.json 等元数据。缓存不自动清理，久而久之可达数 GB。
如何用 config 命令禁用 dist 缓存和 source 缓存？
最直接有效的控制方式是关闭非必要缓存类型。Composer 提供了两个关键配置项：
-
cache-dist：控制是否缓存 dist 包（即 zip/tar.gz 归档），设为false后每次 download 都重新获取，但跳过本地解压缓存 -
cache-dir：可临时指向一个空目录（如/tmp/composer-cache），配合脚本实现“一次一清”
执行以下命令即可全局禁用 dist 缓存：
composer config -g cache-dist false
若只想对当前项目生效，去掉 -g 并在项目根目录运行：
composer config cache-dist false
注意：cache-dist false 不影响 cache-files（即 vendor 下的安装行为），只是跳过 ~/.composer/cache/files/ 下的归档存储。
为什么不能简单删掉 ~/.composer/cache？
手动删除缓存目录看似彻底，但存在几个隐性问题：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 下次
composer update会重建所有 dist 和 VCS 缓存，网络+解压开销反而更大 - VCS 缓存（
~/.composer/cache/vcs/）里可能有带修改的 fork 或私有 repo 的克隆，误删会导致composer update拉取失败或回退到旧 commit - 某些 CI 环境（如 GitHub Actions）依赖缓存复用，盲目清空反而延长构建时间
更稳妥的做法是定期清理而非全删。可用 Composer 内置命令精准清理：
composer clear-cache
它只清除无效/过期缓存，保留仍在使用的 VCS 克隆和最近命中的 dist 包。
CI 场景下怎样最小化缓存体积？
在 GitHub Actions、GitLab CI 等环境，推荐组合使用以下三步：
- 设置
cache-dist=false和cache-files=false（后者禁用 vendor 目录级缓存，避免污染） - 用
COMPOSER_CACHE_DIR环境变量指向一个临时路径，例如/tmp/composer-cache - 在 job 结束前加一步
rm -rf $COMPOSER_CACHE_DIR，确保不残留
示例 GitHub Actions 片段：
env: COMPOSER_CACHE_DIR: /tmp/composer-cache run: | composer config cache-dist false composer config cache-files false composer install --no-interaction
这样既规避了长期缓存膨胀，又不会因缓存缺失导致重复下载——因为 CI 通常通过 actions/cache 单独缓存 vendor/，与 Composer 自身缓存解耦。
真正难控的是 VCS 缓存里的深度克隆（比如 dev-main 分支频繁提交后，vcs/https---github.com-vendor-pkg.git/ 下会积累大量 reflog 和 object）。这种场景下，cache-dist false 无能为力，必须靠 git gc 或定期重置 vcs 缓存目录，但要小心私有仓库认证失效的问题。
