Composer临时跳过缓存TTL验证的唯一正解是设置环境变量COMPOSER_CACHE_TTL为极大值（如315360000），而非--no-cache或COMPOSER_CACHE_DIR；该变量仅对dist包缓存生效，单位秒，命令级临时覆盖，退出终端即失效。
composer install/update 时如何临时跳过缓存验证
Composer 默认会检查本地包缓存（vendor/composer/cache 或全局 ~/.composer/cache）中 dist 包的完整性与有效期，若缓存过期（默认 15 天），就会重新下载。但有时你只想强制复用现有缓存、跳过「是否过期」判断——--no-cache 并不能实现这点，它只是完全禁用缓存；真正需要的是让 Composer 忽略缓存 TTL 检查。
关键参数是 --prefer-dist 配合环境变量 COMPOSER_CACHE_DIR 不起作用，真正生效的是：COMPOSER_CACHE_TTL。
-
COMPOSER_CACHE_TTL=3600：设为 1 小时（单位秒），下次composer install就只认这个新有效期 - 该变量仅影响当前命令生命周期，不修改配置文件，退出终端即失效
- 必须在命令前导出，不能写进
composer.json或config.json - 注意：仅对 dist 包（zip/tar）缓存有效；source clone 缓存走另一套逻辑，不受此控制
为什么 set COMPOSER_CACHE_TTL=0 不等于「永不过期」
设成 0 的实际效果是「立即过期」，不是跳过检查——Composer 会认为所有 dist 缓存都已失效，强制重下。真正想绕过 TTL 判断，得设一个极大值，比如 COMPOSER_CACHE_TTL=315360000（10 年），这比改源码或 patch vendor 更安全可靠。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 常见误操作：
COMPOSER_CACHE_TTL=0→ 触发全量重下载，反而更慢 - Composer 源码中判断逻辑是
time() > $cacheTime + $ttl，所以$ttl = 0会让几乎所有缓存立刻不满足条件 - 如果项目 CI 环境网络受限，建议固定设为
315360000，配合--prefer-dist --no-interaction使用
如何验证当前缓存是否被命中且未因 TTL 被丢弃
执行命令时加 -v（verbose）即可看到缓存决策过程，重点关注含 Using cached 或 Downloading 的行。
- 成功命中缓存：输出类似
Downloading https://api.github.com/... (cached) - TTL 导致未命中：会出现
Cache is older than TTL, redownloading（实际日志无此原文，但你会看到先读缓存、再删缓存、再下载的三段式行为） - 可配合
ls -la $(composer config cache-dir)/files/手动检查文件 mtime，和COMPOSER_CACHE_TTL值比对
不推荐但偶尔有用的替代方案：临时改 composer.json 的 cache-dir
极少数情况下（如多项目共享缓存但需隔离策略），可通过 --config-cache-dir 指向一个空目录，实现「本次命令无缓存可用」，从而强制走 dist 下载——但这不是延长有效期，而是彻底绕开缓存机制。它和 COMPOSER_CACHE_TTL 解决的是不同问题。
composer install --config-cache-dir=/tmp/composer-empty-cache -v- 该路径必须存在且可写，否则报错
Failed to create cache directory - 适合调试缓存逻辑，不适合日常提效；每次执行都会新建空白缓存目录，无复用价值
真正要改缓存有效期，只认 COMPOSER_CACHE_TTL 这个环境变量。别碰 config.json 里的 cache-ttl 字段——那是全局持久配置，改了会影响后续所有命令，而且 Composer v2.2+ 已标记该字段为 deprecated。
