Composer update 读缓存仍慢的主因是元数据未强制刷新，而非缓存失效；需用 --refresh 强制重载 packages.json，配合镜像源配置、缓存策略调优及排查环境配置陷阱。
为什么 composer update 读缓存还慢？
不是缓存没生效，而是 Composer 在 update 过程中默认不「信任」本地缓存的元数据（packages.json、provider-*.json），尤其当它检测到 composer.lock 里有旧约束或 vendor 已存在时，会跳过远程索引刷新，直接基于本地快照做依赖解析——这看似快，实则可能用错版本、漏更新、甚至卡在“找不到新 tag”。真正的瓶颈常藏在元数据陈旧 + 镜像未强制拉取这两步。
强制刷新元数据：用 --refresh，别用 clear-cache + update
composer update --refresh 是唯一能绕过所有本地启发式推导、直连镜像源重载 packages.json 的方式。它不重下 ZIP 包，只刷新元数据，快且可靠。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须确保 Composer ≥ 2.5：
composer --version查看，过旧就先composer self-update - 执行前确认镜像源生效：
composer config --global repo.packagist应返回类似https://mirrors.aliyun.com/composer/，而非https://packagist.org/ - 加
-v验证是否真刷新：composer update --refresh -v日志里必须出现Downloading https://mirrors.aliyun.com/composer/packages.json - 别混用
--no-cache：它跳过全部缓存（包括已下载 ZIP），反而更慢、更耗流量
调优缓存策略：让 Composer 少删多留
Composer 默认的缓存 TTL（6个月）和大小限制（300MiB）对高频更新项目太保守。频繁 GC 会导致重复下载，拖慢后续 update。
- 延长 ZIP 缓存有效期：
composer config -g cache-files-ttl 2592000（30 天） - 增大缓存上限：
composer config -g cache-files-maxsize "1G"，避免小包被误删 - 禁用自动 GC（可选）：
composer config -g cache-files-gc false，改用手动composer clear-cache --gc控制时机 - 注意：
cache-read-only不适合开发机，只用于容器等只读环境
容易被忽略的三个坑
再快的缓存也救不了配置错的源头。
-
COMPOSER_CACHE_DIR环境变量可能覆盖全局配置，导致你以为清了缓存，其实删的是另一个目录 - CI 环境里 alias（如
comcc）不生效，clear-cache必须写全称；且要确认 CI runner 是否复用 Composer 进程（PHP-FPM 场景下内存缓存可能残留） - 某些私有包仓库未配置
type: composer或 URL 拼错，Composer 会 fallback 到 packagist.org，但你根本看不到报错，只感觉“莫名变慢”
