cache-files-ttl是ZIP/TAR包复用的硬性开关，控制cache-dir/archived/下dist包解压复用时长；它与管packages.json更新的cache-ttl无关，私有Git依赖则由cache-vcs-ttl控制。
cache-files-ttl 不是“建议值”，而是 ZIP/TAR 包是否被复用的硬性开关；设了不生效，90% 是因为没清 archived/ 目录或误用了 --prefer-source。
cache-files-ttl 到底管什么，和 cache-ttl 有啥区别
它只控制 cache-dir/archived/ 下已下载的 dist 包（.zip、.tar）能被直接解压复用多久。不是元数据，不是 Git clone，也不是 vendor/ 目录内容。
-
cache-ttl管的是repo/https---packagist.org/packages.json是否重拉——决定你「看不看得见新 tag」 -
cache-files-ttl管的是archived/xxx.zip是否跳过下载直接解压——决定你「装的到底是不是刚 push 的代码」 - 私有 Git 依赖完全不走这个逻辑，它由
cache-vcs-ttl控制
怎么设才真正起效：三种方式 + 必须同步做的三件事
配置写对只是第一步，缓存层本身得“认账”。尤其发版后想立刻验证，光改配置没用。
- 全局设（开发机推荐）：
composer config -g cache-files-ttl 1800（30 分钟） - 项目级设（写入
composer.json）：composer config cache-files-ttl 60 - 单次覆盖（CI 调试）：
composer install --config-cache-files-ttl=1 - 删旧 ZIP：
rm -rf $(composer config --global cache-dir)/archived/*（clear-cache不清这里） - 确认没被
--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；设太大（比如一年）则磁盘占用高，clear-cache 变慢，且容易卡住旧代码。
- 线上稳态部署：建议
86400（1 天）到604800（1 周）之间 - CI 环境可临时设为
1，但必须配合--prefer-dist和挂载缓存卷，否则反而更慢 - 别设
0或负数——Composer 不识别，会退回到默认的 6 个月（15552000）
最容易被忽略的点是：缓存是否生效，不能只看 composer config --list 输出，得看终端日志里有没有 Writing ... into cache 或 Using dist package from cache 这类明确提示；没有，说明要么路径不对，要么权限冲突，要么 archived/ 里残留着未过期但内容错误的包。
