Composer本地全局目录结构及各缓存目录生命周期深度剖析-composer-PHP中文网

composer config --global cache-dir 输出的是 composer 全局缓存根目录，包含 files/（下载归档）、vcs/（git裸仓库）、repo/（元数据）三个核心子目录，受 composer_cache_dir 环境变量优先控制，docker/ci 中需注意 uid/gid 权限问题。

composer本地全局目录结构及各缓存目录生命周期深度剖析

composer config --global cache-dir 输出的路径到底对应什么

它指向的是 Composer 全局缓存根目录，不是项目 vendor，也不是临时下载区。这个路径下必然包含 files/、vcs/、repo/ 三个核心子目录——它们各自职责分明，不能混为一谈。

运行 composer config --global cache-dir 得到的结果，比如 ~/.composer/cache 或 %APPDATA%\Composer\Cache，是 Composer 所有缓存行为的“总控室”。但要注意：COMPOSER_CACHE_DIR 环境变量优先级更高，如果设了它，cache-dir 配置就失效；Docker 或 CI 中常因 UID/GID 不匹配导致写入失败，表面没报错，实际退化成无缓存模式。

files/ 目录里存的到底是哪些文件，什么时候会被删

files/ 存的是所有下载过的 .zip 和 .tar.gz 包归档，文件名形如 monolog/monolog/1234567890abcdef.zip，其中 hash 对应包内容 SHA-256 校验值。它不按项目隔离，而是全局复用——同一个 zip 可被十个不同项目共用。

composer clear-cache 默认清空 files/，但不会动 vcs/ 和 repo/
cache-files-ttl 控制过期时间，默认 6 个月（15552000 秒），超时后垃圾回收（composer install --gc）才清理
cache-files-maxsize 设为 "500MiB" 后，Composer 会在缓存满时自动删最旧的 zip，但只限于“未被任何 composer.lock 引用”的文件
别手动删整个 files/：你删掉的某个 zip，可能正被另一个项目依赖，下次 install 会重复下载，浪费带宽和时间

vcs/ 目录为什么比 files/ 更危险

vcs/ 存的是 Git 裸仓库（.git 目录全量），每个包一个目录，单个常达 300–800 MB，含数千个文件。它吃的是 inodes，不是磁盘空间——df -i 显示 Use% 99% 却 df -h 还剩 20 GB，基本就是它干的。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

composer clear-cache 默认跳过 vcs/，这是设计使然：Git 仓库用于 --prefer-source 场景，重用可加速更新。但多数项目根本不用它，尤其用了镜像源后，--prefer-dist 成默认。

安全清理：直接 rm -rf ~/.composer/cache/vcs/*（Linux/macOS）或清空 Windows 下 %APPDATA%\Composer\Cache\vcs\
一劳永逸：执行 composer config --global cache.vcs false，之后所有包强制走 dist，vcs/ 不再生成
注意副作用：首次 update 会慢一点（重下 dist 包），但后续不再偷偷耗 inodes，CI 构建更稳定

repo/ 目录的作用常被低估，但它决定解析速度

repo/ 缓存 Packagist 的元数据（JSON 列表、包信息、版本约束等），不是代码本身。Composer 解析 composer.json 时，先查这里，命中则跳过网络请求；没命中或过期（默认每 15 分钟刷新一次），才去拉 API。

它体积小（通常几 MB），但直接影响 composer update 开头的“Loading composer repositories”阶段耗时。长期不清理不会爆磁盘，但元数据陈旧可能导致版本解析错误（比如某包已弃用却仍被选中）。

cache-repo-ttl 可调，单位秒，默认值未公开，但实测约 900 秒（15 分钟）
composer clear-cache 会清 repo/，但 --gc 不碰它
CI 中若频繁换分支或 tag，建议在 composer update 前加 composer clear-cache --no-interaction，避免元数据污染

真正麻烦的从来不是磁盘空间，而是 inodes 耗尽后连 ls 都卡住，或者 clear-cache 执行完发现 vcs/ 里的裸仓库还在那儿——那说明你根本没看清缓存目录里到底有什么。