Composer 不支持动态 TTL 调整，其元数据缓存完全静态、依赖本地文件时间戳和全局 cache-files-ttl 配置，无法按包或源差异化设置，也无钩子机制；如需高频请求触发更快回源，须在外部部署支持动态缓存策略的反向代理。
Composer 本身不支持动态 TTL 调整
直接说结论：Composer 没有“根据请求频率动态调整 TTL”的能力，也不提供任何钩子或配置项来实现该逻辑。它的元数据缓存策略是静态的、本地文件驱动的，只认 cache-files-ttl 配置值（默认 900 秒），且完全忽略 HTTP 响应头中的 Cache-Control、ETag 等字段。
所谓“智能回源”是常见误解——Composer 不会因某包被频繁请求就提前刷新其 packages.json，也不会因为某个镜像连续成功响应就延长缓存时间。它只做一件事：检查本地缓存文件的修改时间戳，超时即全量重拉。
-
cache-files-ttl是全局统一值，不能按包、按源、按 URL 分别设置 - 即使你用
composer config --global cache-files-ttl 300把 TTL 改成 5 分钟，所有镜像源的元数据都一视同仁 - 没有插件机制、没有事件回调、没有运行时 hook 可注入自定义缓存逻辑
想实现类似效果，只能绕过 Composer 自身缓存
真要达成“高频请求触发更快回源”，得在 Composer 外围加一层可控代理，而不是改 Composer 配置。
- 部署一个反向代理（如 Nginx 或 Envoy），把
https://composer.mirror.internal指向它 - 代理层记录每个包路径（如
/p/laravel/framework.json）的 1 分钟内请求数，超过阈值则主动向后端镜像发起HEAD请求校验 freshness - 代理自身缓存使用
X-Accel-Expires或proxy_cache_valid动态控制，比如：proxy_cache_valid 200 60s;+proxy_cache_valid 304 300s; - Composer 客户端只配这个代理地址：
composer config -g repo.packagist composer https://composer.mirror.internal/
注意：代理必须透传 Accept 和 User-Agent，否则镜像站可能拒绝返回 JSON；同时要正确处理 304 Not Modified 响应，避免误判为失败。
高频场景下更实际的优化点
与其折腾动态 TTL，不如优先解决真正卡顿的环节。Composer 的慢，90% 不出在元数据缓存，而出在 ZIP 包下载和解压阶段。
- 确认是否启用了
parallel-downloads：Composer ≥ 2.2 默认为 3，可尝试调高到 5（但别超过 8，否则镜像站限流会反噬） - 检查
vendor/所在磁盘是否为机械硬盘或 NFS 共享——解压耗时可能占整个 install 的 70% - 禁用杀毒软件实时扫描
vendor/目录，某些国产软件会对每个 .zip 解压前做全文件扫描 - 如果用 CI，确保每次构建前清理
~/.composer/cache/files/，避免旧包 hash 冲突导致重复下载
强制刷新元数据时最容易踩的坑
很多人以为 composer clear-cache 就能解决“新包装不上”，其实它只清 ZIP 缓存，对元数据无效。
- Composer ≥ 2.5：必须用
composer update --refresh，它会删掉~/.composer/cache/repo/下所有packages.json和provider-*.json - Composer rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer
- 切记：项目级
repositories配置会屏蔽全局设置，此时要查composer config repo.packagist，而非带-g的命令 - 验证是否生效，唯一可靠方式是加
-v运行composer update，看终端输出的真实请求 URL 是否命中你配的镜像地址
动态 TTL 是个诱人的概念，但 Composer 的设计哲学就是简单可靠——它宁可多花几百毫秒重拉 JSON，也不引入复杂缓存状态管理。真需要智能调度，就得在它外面套一层基础设施，而不是试图改造它内部。
