Composer缓存分为三层：全局包缓存（~/.composer/cache/files/）、VCS缓存（~/.composer/cache/vcs/）和运行时缓存（如vendor/composer/installed.json与autoload_classmap.php）。
Composer缓存存在哪几个层级？
Composer 的缓存不是单一层级，而是分三块：全局包缓存（~/.composer/cache/files/）、已下载 ZIP 包缓存（~/.composer/cache/vcs/）、以及构建时生成的 vendor/composer/installed.json 和类映射（vendor/composer/autoload_classmap.php）这类运行时缓存。
其中真正影响构建速度的是前两者：VCS 缓存用于加速 git clone 或 hg clone 操作，文件缓存则复用已下载过的 .zip 或 .tar 包。如果你用的是私有 Packagist 或镜像源，这些缓存会自动适配对应域名，但不会跨源共享。
如何验证缓存是否生效？
执行 composer install --verbose 时，留意输出里是否出现 Downloading ... (cached) 或 Cloning ... (from cache)；没有的话说明缓存没被命中。常见原因包括：
-
composer.json中依赖版本写成"dev-master"或带@dev标签，强制跳过文件缓存 - 本地修改了某个包的
composer.json（比如加了repositories），导致 VCS 缓存 key 变更 - 运行了
composer clear-cache但没意识到它清的是全部三级缓存 - CI 环境未复用缓存目录（例如 GitHub Actions 没配置
cacheaction 保存~/.composer/cache）
构建中怎么安全地复用缓存？
在 CI/CD 流水线中直接挂载 ~/.composer/cache 是最有效的提速方式，但要注意两点：
- 不同 PHP 版本或 Composer 版本产生的缓存不兼容——比如用 Composer 2.5 下载的包，不能被 Composer 1.x 读取，反之亦然
- 私有仓库认证信息（如 GitHub token）必须提前注入环境变量
COMPOSER_AUTH，否则即使缓存存在，VCS 克隆阶段仍会失败并回退到重新拉取 - 如果项目启用了
config.platform（例如指定"php": "8.1"），该配置会影响包筛选逻辑，缓存内容虽存在，但安装时可能因平台约束被跳过
示例（GitHub Actions）：
uses: actions/cache@v4
with:
path: ~/.composer/cache
key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
什么时候该主动禁用缓存？
缓存不是万能的，遇到以下情况建议临时关掉：
- 调试依赖冲突时，加
--no-cache可绕过所有缓存层，确保看到原始报错（比如Your requirements could not be resolved是真冲突，而非缓存污染导致的假象） - 私有包正在频繁迭代且未打 tag，用
dev-main+--prefer-source时，缓存反而会让本地改的代码不生效——因为 Composer 默认优先用缓存里的 ZIP，除非显式加--prefer-source并配合--no-cache - 执行
composer update后发现vendor/里少了某些类，大概率是类映射缓存（vendor/composer/autoload_*.php）没刷新，此时应运行composer dump-autoload --optimize而非清全局缓存
缓存机制本身很稳定，但它的“隐形性”容易让人忽略它对构建结果的影响——尤其是当 composer.lock 没变、PHP 环境变了、或者私有源权限策略更新了的时候，缓存会照常工作，只是工作对象已经不是你预期的那个版本。
