“disk full”错误源于php进程的sys_get_temp_dir()目录被临时文件占满，需手动清理或重定向至专用路径。
phpEnv 运行时提示 “Disk full” 本质不是 PHP 本身报错，而是底层临时目录（sys_get_temp_dir()）被撑爆，必须手动干预清理或重定向。
为什么 phpEnv 的临时文件会失控
phpEnv 是 Windows 下的 PHP 多版本环境管理工具，它本身不生成大量临时文件，但其启动的 PHP 进程、Composer、Xdebug 日志、OPcache 文件缓存、以及你运行的脚本（比如 php -r "file_put_contents(tempnam(...))"）都会往系统默认临时目录写入内容。Windows 默认将临时文件放在 C:Users\AppDataLocalTemp，而 phpEnv 不会自动轮转或清理这些文件。
- 常见诱因：频繁执行
composer install、启用xdebug.log、使用tmpfile()或tempnam()创建未清理的文件 - 容易被忽略：即使你删了项目里的
vendor，Temp目录里残留的 Composer 缓存（packages/子目录）、PHP 编译中间产物仍存在 - Windows 特性：该目录不会随系统重启清空，且部分文件可能被占用导致资源管理器无法直接删除
快速定位并清空真正占空间的临时路径
不要盲目删 C:WindowsTemp 或 C:Temp —— phpEnv 实际用的是 PHP 进程看到的 sys_get_temp_dir() 返回值，这个值可能被环境变量或 php.ini 覆盖。
- 新建一个
check_temp.php，内容为：<?php echo sys_get_temp_dir(); ?>，然后用 phpEnv 切换到对应 PHP 版本执行：php check_temp.php - 典型返回可能是：
C:UsersAliceAppDataLocalTemp或D:phpenv mp（如果你改过TEMP/TMP环境变量） - 进该目录后，按「修改日期」倒序排列，重点看：
composer_*.phar、php*.tmp、xdebug_*.log、php-opcache-*.bin这类文件 - 用命令行强制清理（避免被占用卡住）：
del /f /q "%TEMP%composer_*" "%TEMP%bug_*.log"
让 phpEnv 启动的 PHP 永久用指定临时目录
硬编码改 sys_get_temp_dir() 返回值最可靠，比改系统环境变量更精准，且不影响其他程序。
- 找到 phpEnv 当前激活的 PHP 版本目录，例如：
D:phpenv ersions8.2.12php.ini - 在该
php.ini文件末尾添加：sys_temp_dir = "D:phpenv mp"（路径需手动创建，确保有写权限） - 重启你的终端或 CMD，再执行
php -r "echo sys_get_temp_dir();"验证是否生效 - 好处：所有通过该 PHP 版本运行的脚本（包括 Composer、phpunit、自定义脚本）都会写入新目录，便于集中监控和定时清理
自动化防止下次再满
临时目录满了再救是被动响应；加一层防御机制才省心。
- 在 phpEnv 启动脚本（如
phpenv.bat）末尾追加一行：if exist "%TEMP%*.tmp" del /f /q "%TEMP%*.tmp" >nul 2>&1 - 用 Windows 任务计划程序，每天凌晨执行一次清理：
PowerShell -Command "Remove-Item '$env:TEMPcomposer_*', '$env:TEMPbug_*.log' -Force -ErrorAction SilentlyContinue" - 如果用的是较新 phpEnv（v4+），检查是否支持
phpenv config set temp_dir D:phpenv mp—— 有些分支已内置该配置项
关键点在于：phpEnv 本身不管理磁盘空间，它只是 PHP 的“启动器”。真正要盯住的是 PHP 进程的 sys_get_temp_dir() 输出路径，以及该路径下那些没被主动 unlink() 的文件 —— 它们不会自己消失，也不会被 phpEnv 清理。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
