Composer缓存过期由cache-files-ttl（默认6个月）控制，仅针对下载的.zip/.tar包；cache-files-maxsize（默认300MiB）是硬限制，超限时按访问时间清理旧文件；/tmp中临时解压文件不受二者影响，需外部清理。
Composer缓存文件过期时间由 cache-files-ttl 控制
Composer 默认不会“自动过期并回收”临时文件——它只对下载下来的压缩包（.zip、.tar）做基于时间的淘汰，且这个行为完全依赖 cache-files-ttl 配置。它不清理 /tmp 下的解压中间产物，也不管 vendor/composer/ 里的生成文件。
该参数单位是秒，默认值 15552000（6个月），意味着只要缓存文件在 6 个月内被至少访问过一次，就不会被 GC 清掉。
- 设太小（如
86400即 1 天）会导致频繁重下载，尤其在 CI 环境里拉取同一版本多次时明显拖慢构建 - 设太大（如
31536000即 1 年）会让磁盘空间缓慢堆积，但对单机开发影响不大 - 修改方式：在项目级
composer.json中加"cache-files-ttl": 2592000（30 天），或全局执行composer config -g cache-files-ttl 2592000
cache-files-maxsize 才真正触发主动回收
cache-files-ttl 是“软限制”，而 cache-files-maxsize 是硬性水位线——一旦缓存目录总大小超过该值，Composer 在下次运行 install 或 update 时，会按最后访问时间倒序删旧文件，直到低于阈值。
- 默认值是
"300MiB"，对现代 PHP 项目往往不够用，尤其含大量私有包或大体积扩展（如 Laravel Nova、Sylius）时 - 建议设为
"1GiB"或"2GiB"，避免 CI 流水线因磁盘满失败 - 注意单位必须带后缀（
K/M/G），写成1073741824这种纯数字会被忽略 - 该配置不影响
/tmp下的临时解压目录，那些得靠外部脚本或系统定时任务清理
临时解压文件（composer_*.zip）不在 Composer 缓存管理范围内
你在 /tmp（Linux/macOS）或 %APPDATA%\Local\Temp（Windows）看到的 composer_*.zip、composer_*.tar 文件，是 Composer 解包过程中的中间产物，不是缓存，也不会受 cache-files-ttl 或 cache-files-maxsize 影响。
- 它们通常在安装成功后自动删除，但进程崩溃、权限不足或磁盘满时容易残留
- 检查是否堆积：用
df -i看 inode 是否耗尽（常见于大量小文件场景） - 安全清理方式：定期运行
find $(sys_get_temp_dir()) -name 'composer_*' -mmin +60 -delete 2>/dev/null（仅删 1 小时前的） - CI 环境建议在 job 开头加一步清理，避免跨 job 污染
钩子脚本无法替代缓存配置，但能补上关键缺口
post-install-cmd 和 post-update-cmd 可以清理你项目自己产生的中间文件（如 bootstrap/cache/*.php、public/build/*），但它对 Composer 自身的缓存和临时文件完全无感。
- 别在钩子里尝试
rm -rf ~/.composer/cache——这会清掉所有包缓存，下次 install 直接变全量下载 - 如果想让钩子“配合”缓存策略，可以加一层判断：比如只在
COMPOSER_CACHE_DIR使用率超 90% 时才触发警告或日志 - 真正需要自动化回收的，还是得靠
cache-files-ttl+cache-files-maxsize组合，再辅以外部定时清理/tmp
实际部署时最容易被忽略的是：缓存过期逻辑只作用于「已下载的归档文件」，而解压中途失败留下的碎片、以及各类构建工具（如 Laravel Mix、Vite）塞进 public/ 的产物，根本不在 Composer 的视野里。
