Composer临时文件存于sys_get_temp_dir()目录且不自动清理，需按磁盘压力定期清理；cache-clear仅用于救急，日常应配置cache-files-ttl和cache-files-maxsize实现自动回收，并确认COMPOSER_HOME路径避免双倍占用。
临时文件不归 Composer 管，得盯紧 sys_get_temp_dir()
Composer 本身不把构建中间产物写进项目目录或 vendor，它用的是 PHP 的系统临时目录——也就是 sys_get_temp_dir() 返回的路径。Linux/macOS 通常是 /tmp，Windows 是 %LOCALAPPDATA%\Temp 或 C:\Users\{user}\AppData\Local\Temp。这些目录里会堆积大量 composer_*.zip、php*.phar、解压残留等，且不会自动清理。
所以“清理频率”不能按 Composer 命令频次来定，而要看你本地或 CI 环境的磁盘压力：
- CI/CD 构建机：每次构建后清一次（用
rm -rf $(sys_get_temp_dir())/composer_*），避免跨任务污染 - 开发机（日常
composer install不频繁）：每周手动跑一次find $(sys_get_temp_dir()) -name 'composer_*' -mmin +1440 -delete（删 24 小时前的） - 磁盘空间紧张（
df -h显示/tmp或 Temp 盘 >85%）：立即清，别等周期
composer cache-clear 不是日常操作，而是“救急开关”
composer cache-clear（或等价的 composer clear-cache）清的是 ~/.composer/cache/ 下的全部内容，包括元数据、zip 包、解压缓存。它不是为“提速”设计的，而是为解决以下情况：
- 缓存损坏导致
Corrupted cache file错误 - 镜像源切换后旧缓存干扰（比如从 packagist.org 切到公司私仓，但 repo/ 里还存着旧 packages.json）
- 磁盘告警，且
du -sh $(composer config --global cache-dir)确实占了几个 GB
每月执行一次已属高频；日常开发中如果没遇到错误或空间问题，完全不用碰它。清完首次 composer install 会明显变慢，这是预期行为，不是故障。
真正该设周期的，是缓存自动回收参数
比起手动清，更可持续的做法是让 Composer 自己管住缓存体积和时效。在全局配置里设这两个值：
-
cache-files-ttl：建议设为2592000（30 天），比默认 6 个月更激进，避免老旧 zip 长期霸占空间 -
cache-files-maxsize：设为"500MiB"或"1G"，防止缓存无节制增长；Composer 在每次命令结束时自动触发 GC，只删最老的文件
设置命令：
composer config --global cache-files-ttl 2592000 composer config --global cache-files-maxsize "500MiB"
注意：cache-files-maxsize 对 repo/（元数据）无效，只管 files/ 和 archives/；元数据体积小，一般不用干预。
别忽略 COMPOSER_HOME 路径是否踩坑
很多人清了半天缓存，发现空间没释放——因为 composer config --global cache-dir 指向的是 C 盘小容量分区，而你本以为它在 D 盘。先确认真实路径：
composer config --global cache-dir
如果返回的是 C:\Users\xxx\AppData\Roaming\Composer\Cache，但你有空余的 D 盘，就立刻迁移：
composer config --global cache-dir "D:\composer-cache"
迁移后记得手动删掉旧路径，否则两处都存、双倍占用。这个动作比调频率重要得多——路径错了，再勤快清理也没用。
