必须分开调，因为cache-ttl控制packages.json元数据刷新（默认600秒），cache-files-ttl控制ZIP包复用（默认6个月），cache-vcs-ttl管理Git克隆缓存（默认900秒），三者作用域独立、单位均为秒，换镜像不改变本地缓存策略。
中文镜像环境下，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）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “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，否则会因平台要求不兼容报错
