Composer 缓存是否生效需通过 -v 日志中“Loading from cache”、installed.json 时间戳变化、--no-cache 对比耗时三方面综合判断，diag 命令仅校验目录权限，无法反映实际缓存使用情况。
看日志里有没有“Loading from cache”
执行 composer update -v（加 -v 是关键），滚动日志中如果出现类似 Loading from cache: /home/user/.cache/composer/files/vender/package/xxx.zip 的行，说明 Composer 正在复用已下载的 ZIP 包；若出现 Downloading https://...，则表示跳过了缓存、重新拉取。
注意：仅靠 composer update 默认静默模式无法判断——它既不报错也不提示是否用了缓存，必须加 -v 或 -vv 才能观察真实行为。
检查 vendor/composer/installed.json 时间戳是否变化
vendor/composer/installed.json 是 Composer 解析完依赖后生成的本地安装快照，它的修改时间可间接反映是否真走缓存路径：
- 如果只更新一个包（如
composer update monolog/monolog），但installed.json里大量包的time字段全变了，说明 Composer 没走缓存、重新解压了所有包 - 如果只有目标包和它的直系依赖时间更新，其余不变，大概率复用了缓存 ZIP
这个方法比看日志更稳定，因为日志可能被 CI 环境截断或重定向，而文件时间戳是落地事实。
对比 --no-cache 和默认行为的耗时差异
缓存是否生效，最朴素的办法就是测速：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先跑一次
composer update --no-cache -v，记下耗时（尤其关注 “Downloading” 和 “Extracting” 阶段） - 再跑一次
composer update -v，同样记录 - 若第二次明显快（尤其 ZIP 解压阶段几乎为 0s），且日志里有
Loading from cache，基本可确认缓存命中
注意：这个对比要在同一台机器、同一 Composer 版本、同一 vendor 目录状态下做；CI 环境中常因每次清空 vendor 导致缓存失效，不是命令问题，是流程设计问题。
别被 composer diag 的输出骗了
composer diag 会显示 Cache directory: /xxx 和 Cache is not writable 这类信息，但它只验证缓存目录是否存在、可写，**完全不反映 update 过程中是否实际用了缓存**。
常见误判场景：
- 缓存目录存在且可写，但镜像源配置错误（比如指向了一个挂掉的私有源），Composer 会 fallback 到远程包地址下载，绕过缓存
- 你改过
composer.json的 PHP 版本约束（如从"php": "^8.1"改成"php": "^8.2"），Composer 必须重新解析整个依赖图，哪怕包 ZIP 在缓存里，也会强制重解压并校验兼容性
真正决定缓存是否参与的，是依赖解析结果是否复用 + ZIP 文件哈希是否匹配 + 安装路径是否干净——这些细节，diag 不告诉你。
