临时文件清理频率需按场景定制：CI/CD每次构建后立即清理，生产环境每周cron清理，容器化部署无需额外操作，小容量VPS须在post-install-cmd中同步清理；clear-cache不清理临时文件，因其路径为sys_get_temp_dir()而非缓存目录。
临时文件到底该多久清一次？看使用场景定策略
Composer 本身不定义“清理频率”，它只在 install 或 update 过程中按需写入临时文件（比如解压 ZIP 到 sys_get_temp_dir()），也不自动清理。所谓“合理频率”，其实是你根据部署节奏、磁盘容量和故障模式反推出来的运维策略，不是配置项。
常见判断依据包括：
- CI/CD 每次构建后都运行
composer install --no-interaction→ 建议每次执行后立即清理临时目录（rm -rf $(sys_get_temp_dir())/composer_*.zip等） - 生产服务器手动部署，每月更新一次依赖 → 可每周 cron 清理一次系统临时目录，重点删
composer_*.zip和php*tmp类文件 - 容器化部署（如 Docker）→ 容器退出即销毁临时目录，无需额外清理；但构建镜像时应在
RUN composer install后加&& rm -rf $(sys_get_temp_dir())/* - 共享主机或小容量 VPS（如 10GB 系统盘）→ 必须在
post-install-cmd中同步清理，否则几次composer update就可能触发No space left on device
为什么不能依赖 composer clear-cache 控制临时文件？
composer clear-cache 只清 COMPOSER_HOME/cache/ 下的包缓存（files/、repo/、vcs/），跟临时文件完全无关。后者来自 PHP 的 sys_get_temp_dir()，路径通常为：
- Linux/macOS：
/tmp或$TMPDIR - Windows：
%APPDATA%\Local\Temp或C:\Users\{user}\AppData\Local\Temp
这些目录里堆积的 composer_*.zip、phpXXXXXX、phar-*.phar 是解包、生成 autoloader、运行脚本时创建的，clear-cache 对它们毫无影响。误以为清了缓存就等于清了临时文件，是磁盘爆满最常见的认知偏差。
如何在 post-install-cmd 中安全清理临时文件？
直接在 composer.json 的 scripts 里写系统命令风险高：跨平台兼容差、路径含空格会失败、权限不足静默跳过。更可靠的做法是调用一个封装好的 PHP 脚本：
- 新建
bin/clean-temp.php，用sys_get_temp_dir()获取真实路径，再 glob 匹配composer_*.zip、php*.tmp等前缀文件 - 加判断：
if (is_writable($tempDir)) { ... }，避免因权限失败中断整个 install 流程 - 在
composer.json中声明："post-install-cmd": ["php bin/clean-temp.php"] - 不要在脚本里
unlink()正被 Composer 使用的临时文件（比如刚解压完还没读取的 ZIP），应延后几毫秒或等主流程结束——实际中只要不删正在写的文件句柄，基本安全
inode 耗尽比磁盘空间满更隐蔽，必须单独监控
临时目录下大量小文件（尤其是 ZIP 解压残留）极易耗尽 inode。现象是 df -h 显示磁盘还有 80% 空间，但报错 No space left on device；此时运行 df -i 很可能看到 Use% 是 100%。
应对方式不是“提高清理频率”，而是：
- 定期检查：
find $(sys_get_temp_dir()) -name 'composer_*' -type f | wc -l，超过 500 个就预警 - 清理逻辑中加入
find ... -mmin +30 -delete（30 分钟前创建的才删），避免误伤正在使用的临时文件 - 开发环境可设
export TMPDIR=/tmp/composer-dev隔离测试产生的临时文件，防止污染系统级/tmp
临时文件没有“标准生命周期”，它的危险性不在于体积，而在于数量失控后对 inode 和文件系统元数据的冲击——这点比空间占用更值得警惕。
