Composer自身不产生可被脚本安全清理的“构建临时文件”，真正需清理的临时文件藏在系统临时目录（如/tmp或%LOCALAPPDATA%\Temp），由sys_get_temp_dir()返回，用于解压ZIP、生成autoload等，而composer clear-cache仅清理~/.composer/cache，无法释放该目录空间。
Composer 自身不产生可被脚本安全清理的“构建临时文件”，真正要清的临时文件，基本都藏在系统临时目录（sys_get_temp_dir()）里，不是 vendor 或 ~/.composer/cache。
临时文件在哪？为什么 composer clear-cache 清不掉
执行 composer install 或 update 时，Composer 会高频使用 PHP 的 sys_get_temp_dir()（Linux/macOS 通常是 /tmp，Windows 是 %LOCALAPPDATA%\Temp），用来解压 ZIP、生成 autoload 映射、运行脚本等。这些过程产生的 composer_*.zip、php*.phar、temp_*.php 等文件，不会被 composer clear-cache 触及——它只清 ~/.composer/cache/ 下的内容。
常见错误现象：df -h 显示磁盘满，但 composer clear-cache 后空间没释放；du -sh ~/.composer/cache 只有几十 MB，/tmp 却占了几十 GB。
- 先确认真实临时路径：
php -r "echo sys_get_temp_dir();" - 检查该目录下是否堆积大量
composer_*.zip或带时间戳的临时目录 - 用
df -i查 inode 是否耗尽（尤其/tmp在内存文件系统 tmpfs 时）
post-install-cmd 能不能自动删临时文件
不能直接删系统临时目录里的文件，因为 post-install-cmd 运行时，Composer 已退出，那些临时文件早就不属于当前上下文，且权限/路径不可控。但它能安全清理项目内衍生的“伪临时”产物：
-
public/build/、dist/、node_modules/.cache/：前端构建残留，可放心rm -rf -
bootstrap/cache/*.php、storage/framework/views/：框架生成的缓存，适合在钩子里清 - 别碰
vendor/composer/autoload_*.php：这是 Composer 运行必需的，删了后续命令会报错 - Windows 用户避免直接写
rm，改用del /q或统一调用 PHP 脚本（如php clean.php）
怎么安全清理系统级临时文件
必须绕过 Composer 钩子，用外部脚本或手动干预。关键原则是：不暴力扫 /tmp，只清明确归属 Composer 的文件，并加时间约束。
- Linux/macOS 示例：
find $(php -r "echo sys_get_temp_dir();") -name 'composer_*.zip' -mmin +10 -delete（10 分钟前创建的才删） - Windows 示例：
forfiles /p "%TEMP%" /s /m composer_*.zip /d -1 /c "cmd /c del @path" - 所有临时路径应带随机后缀或时间戳（如
tmp_build_20261103_abc），避免多实例冲突 - 禁用
register_shutdown_function()做清理：Composer 进程可能异常终止，shutdown 不保证执行
插件里的 deactivate() 方法根本不会被调用
别在 Composer 插件中依赖 deactivate() 做资源释放——它只是接口定义，Composer 生命周期极短，进程退出即结束，这个方法永远不会被自动触发。你看到的日志没输出、文件没删掉，不是代码写错了，是设计如此。
真正可行的清理时机只有两个：
- 显式绑定到
post-install-cmd或post-update-cmd钩子（适合项目级可控路径） - 在脚本内部做「创建即标记」：生成临时文件时同时写一个
.lock文件，下次启动前检查该 lock 是否超时（如 >30 分钟），超时则强制清理
系统临时目录的清理永远需要独立于 Composer 生命周期之外的机制，靠不住的 deactivate() 和没落地的 shutdown 函数，只会让你误以为问题已解决。
