Composer install复用缓存不靠猜测，而是先检查~/.composer/cache/files/中是否存在对应ZIP包，再校验其SHA256是否匹配composer.lock中dist.sha256，全部匹配才跳过下载直接解压。
composer install 为什么能复用缓存
它不靠“猜”，而是按明确路径和规则复用：先查 ~/.composer/cache/files/ 里有没有对应 ZIP 包，再校验 hash 是否匹配 composer.lock 中的 dist.sha256，全对才跳过下载直接解压。只要缓存目录存在、可写、没被清空，且 lock 文件没变，90% 的包都能跳过网络请求。
缓存命中失败的常见原因
不是缓存不存在，而是 Composer 根本没去读它——或者读了但发现不匹配：
-
composer config -g cache-dir输出为空或指向不可写路径（如 Docker 容器里挂载失败的/tmp/composer-cache） - CI 环境没显式缓存
~/.composer/cache/，每次构建都是全新 home 目录 -
composer.lock被改过（哪怕只改一行），导致所有包的 hash 校验失败，缓存全部失效 - 项目级配置覆盖了全局缓存：
"config": {"cache-files-dir": null}或"cache-files-dir": ""会禁用缓存 - 用了
--no-cache参数（极少用，但 CI 脚本里可能误加）
如何验证缓存是否真正生效
别只看 composer clear-cache 是否成功，要看安装时日志有没有跳过下载：
- 运行
composer install -vvv，观察输出中是否出现Downloading https://mirrors.aliyun.com/composer/dists/...—— 如果没这行，而是直接Extracting archive，说明缓存命中 - 检查
~/.composer/cache/files/下是否有大量.zip文件，且修改时间接近最近一次 install - 执行
composer show --platform后，再跑composer install -vvv，对比两次日志中Downloading行数是否明显减少
缓存目录设在 RamDisk 或 tmpfs 的实际效果
它只加速“已有 ZIP 包”的解压和元数据读取，不加速首次下载：
- 机械硬盘上，
cache-dir设为 RamDisk 可把 vendor 构建从 6 分钟压到 45 秒内；但前提是 RamDisk 启用了关机镜像保存（Windows）或tmpfs挂载带size=2G（Linux/macOS） - 如果只是建了个空 RamDisk 盘、没设置开机加载镜像，重启后
cache-dir为空，Composer 会重下所有 ZIP，反而更慢 -
cache-dir必须是 Composer 进程有权限写的路径；Docker 中需确保用户 UID 匹配，否则file_put_contents(): failed to open stream会静默失败
缓存机制本身很朴素，但它的效果高度依赖路径是否真实可写、是否被 CI 工具正确挂载、以及 lock 文件是否稳定——这三个点漏掉任何一个，缓存就形同虚设。
