composer update默认不走本地缓存，因其核心是重新解析依赖树，优先读取过期的元数据（如~/.composer/cache/repo/https---packagist.org/packages.json），而非复用已下载包；若元数据过期或composer.lock锁定版本，即使本地有新包zip也不会拉取。
composer update 为什么默认不走本地缓存？
因为 composer update 的核心逻辑是“重新解析依赖树”，它会优先读取 ~/.composer/cache/repo/https---packagist.org/ 下的元数据（如 packages.json、provider-*.json），而不是直接复用已下载的包归档（.zip 或 .tar）。但这些元数据可能已过期，导致它“以为”没新版本；而实际包文件哪怕本地已有，也不会被跳过校验或复用——除非缓存目录结构完整、时间戳有效、且镜像源配置正确。
必须确认的三处缓存状态
本地缓存加速生效的前提，是以下三处都处于可用且未过期状态：
-
~/.composer/cache/files/：存放已下载的包压缩包（.zip），update会尝试复用这里的内容，前提是 SHA256 校验通过且版本匹配 -
~/.composer/cache/repo/https---packagist.org/：存放远程元数据快照；若该目录下packages.json的Last-Modified时间太旧（比如 >15 分钟），Composer 会认为它失效，转而发起 HTTP 请求 -
vendor/composer/installed.json和composer.lock：它们不属“下载缓存”，但影响是否触发重下载；若composer.lock锁死了版本，update就不会拉新包，哪怕缓存里有 2.1.0 的 zip 文件
如何让 composer update 真正复用本地缓存
不是靠加参数“开启缓存”，而是靠清理+配置+约束组合达成：
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 repo.packagist composer https://mirrors.aliyun.com/composer/（否则元数据请求本身就会超时或失败） - 运行
composer clear-cache后，立刻执行composer update --dry-run -v，观察日志中是否出现Downloading https://mirrors.aliyun.com/composer/packages.json—— 若出现，说明元数据缓存没生效；若只显示Reading /path/to/cache/repo/.../packages.json，才表示在读本地 - 对单个包更新（如
composer update monolog/monolog），比全量update更容易命中缓存，因依赖图更小、校验路径更短 - 加上
-o（--optimize-autoloader）参数不会加速下载，但能减少后续 autoload 延迟；它不影响缓存复用逻辑
常见缓存失效场景与绕过方式
即使缓存目录存在，也常因以下原因被跳过：
- 镜像源 URL 末尾多了一个
/（如https://mirrors.aliyun.com/composer//），会导致缓存路径错位，Composer 新建一个空目录，元数据无法命中 -
composer.lock中某包的dist.sha256与本地cache/files/中对应 zip 的实际哈希不一致（比如手动改过 lock 文件），Composer 会强制重下载 - PHP 进程内存不足（
Allowed memory size exhausted），导致缓存写入中断，后续读取时发现文件不完整而丢弃 - 使用
--no-cache或环境变量COMPOSER_CACHE_DIR=""，会显式禁用全部缓存行为
最稳的做法：先删 composer.lock 和 vendor/，再跑 composer install —— 它比 update 更信任缓存，且不重新解析整个依赖图。
