cache-files-ttl 控制已下载 zip/tar 包在 cache-dir/archived/ 下的复用时长；它与 cache-ttl 无关，后者管元数据缓存，前者只管归档包解压行为。
改 cache-files-ttl 是控制 ZIP/TAR 包本地缓存“保质期”的唯一方式，但设完不生效，90% 是因为没清旧包或误用了 cache-ttl。
cache-files-ttl 控制什么？为什么它和 cache-ttl 完全无关
cache-files-ttl 只管已下载的 dist 包（.zip、.tar）在 cache-dir/archived/ 下能复用多久；它不碰元数据、不碰 Git 仓库、也不影响 vendor/ 目录内容。很多人发版后 composer install 还装旧代码，就是卡在这儿——Composer 检查到本地 ZIP 包没过期，直接解压用了，根本不去远程拉新包。
-
cache-ttl管的是repo/https---packagist.org/packages.json缓存，决定「是否看到新 tag」 -
cache-files-ttl管的是archived/xxx.zip缓存，决定「解压的到底是不是你刚 push 的代码」 - 私有 Git 依赖走的是
cache-vcs-ttl，这个值对它完全无效
三种设置方式：优先级、写法、常见翻车点
命令行参数 > 项目 composer.json > 全局 config。别手写 config.json，容易格式错；也别在项目里建 config.json，Composer 不读。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 全局生效（推荐开发机）：
composer config -g cache-files-ttl 1800（单位秒，这里设 30 分钟） - 仅当前项目生效：
composer config cache-files-ttl 60（会写入composer.json的"config"段） - 单次覆盖（CI 调试用）：
composer install --config-cache-files-ttl=1（注意双横线 + 下划线，不是--cache-files-ttl） - 手动改配置文件时，必须是合法 JSON：
{"config": {"cache-files-ttl": 300}}，多一个逗号就失效
设了不生效？先做这三件事
配置写对只是第一步，真正起效要绕过缓存层本身。尤其当你刚发了一个 patch 版本，想立刻验证安装结果时。
- 删掉旧 ZIP 包：
rm -rf $(composer config --global cache-dir)/archived/*（clear-cache不清 archived，它只清 repo 和 files） - 确认你没被
--prefer-source绕过：该选项强制走 Git clone，cache-files-ttl完全不参与 - 检查是否命中了
cache-files-maxsize触发自动清理：运行composer config --global cache-files-maxsize，如果太小（如 100MB），大包一多就挤掉旧包，导致 ttl 失效
生产环境怎么设才稳
设太小（比如 1）会导致每次 install 都重下 ZIP，浪费带宽还可能触发 Packagist 的 429 Too Many Requests；设太大（比如 31536000 即一年）又占磁盘、拖慢 clear-cache。折中方案看场景：
- 日常开发机：
3600（1 小时），配合composer clear-cache手动清 - CI/CD 流水线：
86400（24 小时），配合固定 PHP minor 版本 +hashFiles('**/composer.lock')缓存 key - 离线构建环境：直接设为
0，让 Composer 每次都校验哈希再决定是否跳过下载
真正容易被忽略的是：改完 cache-files-ttl 后，旧 ZIP 文件不会自动过期，它们的时间戳是下载那一刻写的，ttl 判断发生在每次 install/update 开始时——也就是说，你得等一次命令执行完，下一次才会按新规则走。
