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 根本没去读它——或者读了但发现不匹配：

Discussion Composer

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

下载

• 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 文件是否稳定——这三个点漏掉任何一个，缓存就形同虚设。