Composer中文镜像环境下Composer缓存过期策略优化-composer-PHP中文网

必须分开调，因为cache-ttl控制packages.json元数据刷新（默认600秒），cache-files-ttl控制zip包复用（默认6个月），cache-vcs-ttl管理git克隆缓存（默认900秒），三者作用域独立、单位均为秒，换镜像不改变本地缓存策略。

composer中文镜像环境下composer缓存过期策略优化

中文镜像环境下，cache-ttl、cache-files-ttl、cache-vcs-ttl 三者必须分开调，不能靠“换镜像”自动解决缓存过期问题。

为什么换了阿里云镜像，`composer update` 还看不到新 tag？

根本不是镜像慢，而是 cache-ttl 没过期——它控制的是 packages.json 元数据是否重拉，和镜像速度无关。默认 600 秒（10 分钟），意味着即使你刚在私有 Git 打了 v2.1.0 tag，Composer 在这 10 分钟内仍用本地缓存的旧元数据，压根不查镜像站有没有更新。

验证方式：composer update -v 看日志里是否出现 Downloading https://mirrors.aliyun.com/composer/packages.json
开发阶段建议设为 30：composer config -g cache-ttl 30（全局）或 composer config cache-ttl 30（项目级）
设太小（如 1）会导致每条命令都触发 HTTP 请求，镜像站可能返回 429 Too Many Requests，本地也会卡在 Loading from cache
改完必须清元数据缓存才生效：composer clear-cache 或手动删 $COMPOSER_HOME/cache/repo/https---mirrors-aliyun-com-composer/ 下的 packages.json

`cache-files-ttl` 决定你装的到底是新代码还是旧 ZIP

你发版后 composer install 还是旧逻辑？问题大概率出在这儿。它控制本地已下载的 dist 包（.zip、.tar）“保质期”，默认 15552000 秒（6 个月）。哪怕远程包已更新，只要 ZIP 文件没过期，Composer 就直接解压它，不走网络。

Discussion Composer

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

下载

日常开发推荐设为 86400（24 小时）：composer config -g cache-files-ttl 86400
高频发版环境可临时设为 3600：COMPOSER_CACHE_FILES_TTL=3600 composer install
它不自动清理磁盘，只让 Composer 下次安装时跳过过期缓存；要立刻生效，得配 composer clear-cache 或等自然过期
注意：cache-files-ttl 不影响 Git 依赖，私有仓库走的是 cache-vcs-ttl

Docker 构建中，`cache-ttl` 和 `cache-files-ttl` 基本无效

因为 Docker 构建每次都是全新容器，~/.composer/cache 默认不存在，cache-ttl 和 cache-files-ttl 配置根本没机会加载。真正起作用的是构建层顺序 + composer.lock 的稳定性。

必须最早单独 COPY composer.json composer.lock ./，且这两个文件必须已提交到 Git
RUN composer install --no-dev --prefer-dist --optimize-autoloader --no-interaction 才能复用 vendor 层
CI 中缓存 ~/.composer/cache 目录时，key 必须基于 composer.lock 的 SHA256，否则哈希不一致就 miss（CRLF/LF 差异也会导致）
别缓存 vendor/ 目录本身——PHP autoloader 里硬编码了绝对路径，容器重建后路径失效，运行时报 Class not found

中文环境最容易被忽略的缓存陷阱

不是配置没写对，而是缓存根本没被用上：比如 cache-dir 落在 NFS 或 Docker volume 上，IO 延迟高；又或者 CI runner 没显式挂载 ~/.composer/cache，导致每次构建都从零下载。更隐蔽的是 cache-vcs 目录——它默认启用，每个 Git 包一个裸仓库，吃 inode 更猛，但绝大多数项目完全不需要它。

禁用方式：composer config --global cache.vcs false，之后所有 Git 包强制走 --prefer-dist
已存在的 cache/vcs/ 可安全手动删（rm -rf ~/.composer/cache/vcs/）
确认 cache-dir 是否落在 SSD 或高速路径：composer config -g cache-dir，避免默认落到慢速存储
CI 中若用了 BuildKit 的 --mount=type=cache，务必确保不同 PHP 版本 job 不共享同一 id=composer-cache，否则会因平台要求不兼容报错