cache-ttl控制packages.json元数据缓存时效，决定是否重新请求版本列表；cache-files-ttl控制ZIP包文件缓存时效，决定实际安装哪个版本；二者独立，不可混淆。
cache-ttl 和 cache-files-ttl 到底管啥？别混了
很多人设了 cache-ttl，发现发版后 composer install 还是装旧代码，其实是配错了地方。cache-ttl 控制的是「是否重新请求 packages.json」——也就是包版本列表的更新频率；而真正决定你装到哪个 ZIP 包的，是 cache-files-ttl。私有 Git 仓库则由 cache-vcs-ttl 管，三者完全独立。
常见错误现象：
- 改了 tag 或主分支，
composer update却不拉新包 → 检查cache-files-ttl - 依赖列表没刷新（比如新包没出现在
composer show里）→ 检查cache-ttl - 私有 Git 仓库总在 clone，CI 跑得慢 → 检查
cache-vcs-ttl是否被覆盖
三种配置方式优先级和写法必须对
命令行参数 > 项目 composer.json > 全局 config。但写错位置或格式，Composer 就直接忽略。
正确操作：
- 全局生效（所有项目）：
composer config -g cache-files-ttl 15552000（6个月） - 仅当前项目生效：
composer config cache-files-ttl 86400（会写进composer.json的config段） - 单次命令覆盖：
composer install --config-cache-files-ttl=3600（注意是双横线 + 下划线，不是--cache-files-ttl）
手动编辑 composer.json 时，确保结构合法：
{"config": {"cache-files-ttl": 86400}}
别在项目根目录瞎建 config.json —— Composer 不认这个文件名。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
设太小会触发 Packagist 限流，设太大又拿不到新包
cache-files-ttl 设成 1 秒？后果是每次 composer install 都去重下 ZIP，Packagist 很快返回 429 Too Many Requests，本地也卡在 “Loading from cache” 阶段不动。反过来，设成 30 天以上，发版后 CI 可能持续装错包好几天。
推荐值参考：
- 日常开发：86400（24 小时）
- 稳定上线项目：15552000（6 个月）
- 高频发版/灰度环境：3600（1 小时）
注意：cache-ttl 建议保持默认（15552000），除非你真需要秒级感知新包发布。
验证有没有生效，别只看 composer config --list
composer config --list 只显示配置值，不反映实际行为。真正起作用的是 Composer 请求时的日志输出。加 -v 参数运行命令，观察关键行：
-
Downloading https://packagist.org/packages.json出现 →cache-ttl已过期 -
Downloading vendor/package/version.zip出现 →cache-files-ttl已过期 - 只有
Loading from cache→ 缓存命中，但你要确认它是不是你想要的那个版本
最稳妥的办法：改一个包的 tag，清空 vendor，然后用 composer install -v 看它到底下哪个 ZIP。
