Composer 临时目录由 sys_get_temp_dir() 决定，可能被 PHP 配置或环境变量覆盖；需用 php -r "echo sys_get_temp_dir();" 确认真实路径，而非默认 /tmp 或 %TEMP%。
先确认 Composer 用的是哪个临时目录
Composer 在解压 ZIP、生成 autoloader、运行脚本时，会重度依赖 sys_get_temp_dir() 返回的路径。这个路径不一定是系统默认的 %TEMP%（Windows）或 /tmp（Linux/macOS），它可能被 PHP 配置、环境变量或 Composer 自身覆盖。
执行以下命令查真实路径：
php -r "echo sys_get_temp_dir();"
常见误判点：
-
composer clear-cache只清~/.composer/cache，和临时目录无关 - Windows 下若 PHP 启用了
open_basedir，sys_get_temp_dir()可能返回一个受限子目录，空间更小 - Docker 容器里常挂载
/tmp为内存文件系统（tmpfs），容量极小，容易瞬间写满
临时目录爆满的典型现象和快速验证方法
不是所有“磁盘满”都来自 Composer 缓存——当 composer install 或 update 卡在解压、校验、生成 autoload 阶段，并报 No space left on device，但 df -h 显示磁盘还有空间，大概率是临时目录所在分区 inode 耗尽，或 tmpfs 满了。
快速验证步骤：
- 运行
df -i $(php -r "echo sys_get_temp_dir();")看 inode 使用率（>95% 就危险） - Linux/macOS：检查
df -h $(php -r "echo sys_get_temp_dir();")，确认是不是 tmpfs - Windows：进资源管理器，粘贴
%TEMP%或%SystemRoot%\Temp，看是否真有上万个小文件堆积 - 临时目录下常见爆炸文件名：
composer_archive_*.zip、composer_autoload_*.php、composer_script_*.php
清理临时目录的实操建议（安全优先）
别直接 rm -rf /tmp/* ——可能删掉其他进程正在用的临时文件。按优先级操作：
- 先停掉所有 Composer 进程（包括后台的
composer update、IDE 的 Composer 插件自动扫描） - 只清 Composer 相关临时文件：
find $(php -r "echo sys_get_temp_dir();") -name "composer_*" -type f -mtime +1 -delete - Windows 用户可用：
forfiles /p "%TEMP%" /m "composer_*" /d -1 /c "cmd /c del @path" - 若确认是 tmpfs（如 Docker 中的
/tmp），且无其他服务依赖，可重启容器或服务释放 - 长期方案：改 PHP 的临时目录，比如在命令前加
PHP_TEMP_DIR=/var/tmp php -d sys_temp_dir=/var/tmp composer install
为什么清完还报错？注意这三处隐藏占用
临时目录只是表象。真正让磁盘“越清越满”的三个常被忽略位置：
-
%APPDATA%\Composer\Cache\vcs\（Windows）或~/.composer/cache/vcs/（Linux/macOS）：Git 克隆的裸仓库，单个项目可达几百 MB，composer clear-cache会清，但很多人没意识到它也算“临时用途” -
C:\Users\{user}\AppData\Local\Temp\下残留的composer-setup.php临时解包目录（尤其 Windows 上用php -r "..." > composer-setup.php方式安装后未清理） - WSL2 用户要注意：
/tmp是内存挂载，但/mnt/c/Users/...下的临时文件实际落在 C 盘 NTFS，sys_get_temp_dir()可能回退到那里，而df -h看的是 Linux 层，误判空间余量
临时目录本身没有智能清理机制，它的生命周期完全依赖外部干预。最稳妥的做法，是在 CI 或 Docker 构建中显式指定并挂载独立临时卷，而不是指望 Composer 自己收尾。
