PHP上传文件的临时目录由upload_tmp_dir配置项决定，而非sys_get_temp_dir()；其必须存在、可写且未被open_basedir限制，否则move_uploaded_file()将静默失败。
PHP上传文件的临时目录由 upload_tmp_dir 决定
PHP 接收上传文件时，不会直接写入目标路径，而是先存到一个临时目录，再由脚本用 move_uploaded_file() 搬走。这个“中转站”就是 upload_tmp_dir 配置项指定的位置——它不等于系统临时目录（如 /tmp），也不一定是 sys_get_temp_dir() 返回的值。
常见错误现象：$_FILES['xxx']['tmp_name'] 是空字符串、move_uploaded_file() 失败但没报错、或报 Unable to move uploaded file；本质往往是临时目录不可写、不存在，或被 open_basedir 限制了访问。
- 检查当前生效值：运行
ini_get('upload_tmp_dir')，返回空字符串说明用了系统默认（此时才看sys_get_temp_dir()） - 修改方式：优先在
php.ini中设upload_tmp_dir = /var/tmp/php-uploads（确保目录存在且 PHP 进程用户可读写） - Web 服务器（如 Nginx + PHP-FPM）下，若用
php_admin_value或php_flag动态设置，需重启 FPM 才生效 - 共享主机或容器环境里，
upload_tmp_dir常被禁用或锁定，此时即使改了php.ini也无效
为什么 sys_get_temp_dir() 不一定可靠
这个函数返回的是 PHP 认为“安全”的系统级临时目录，比如 /tmp 或 C:\Windows\Temp。但它和文件上传流程无关——上传逻辑只认 upload_tmp_dir，哪怕后者为空，PHP 也只会 fallback 到系统默认（可能和 sys_get_temp_dir() 一致，也可能不一致，取决于编译选项和 SAPI）。
- CLI 模式下
sys_get_temp_dir()可能返回/tmp，但 Web SAPI（如 Apache mod_php）可能因open_basedir被限制到某个子目录 - 某些 Docker 镜像（如官方
php:alpine）默认没配upload_tmp_dir，又没挂载/tmp可写，导致上传必挂 - 别用
sys_get_temp_dir()替代upload_tmp_dir做路径判断，它们职责不同
move_uploaded_file() 失败的真正原因往往不在函数本身
这个函数只是个“搬运工”，它失败几乎全是前置条件问题：源文件（$_FILES['x']['tmp_name']）已丢失、权限不对、目标目录不可写，或源路径根本不是上传产生的临时文件（比如手动拼了个路径）。它不会告诉你具体卡在哪一环。
立即学习“PHP免费学习笔记（深入）”；
- 务必先检查
$_FILES['x']['error'] === UPLOAD_ERR_OK，否则tmp_name无效 - 确认
tmp_name确实指向一个真实存在的文件：file_exists($_FILES['x']['tmp_name']) - 目标目录要提前创建好，并确保 PHP 进程用户有写权限（
chown www-data:www-data /path/to/upload） - 如果用了
opcache.enable_cli=1或 APCu，极少数情况下缓存干扰了临时文件清理逻辑（罕见但真有）
容器与云环境里临时目录更得手动管
Docker、K8s 或 Serverless（如 AWS Lambda）环境下，/tmp 可能是内存盘、只读，或每次请求重置。PHP 默认行为在这里大概率失效。
- 容器启动时挂载可写卷到自定义路径，然后在
php.ini显式设upload_tmp_dir = /var/www/tmp - 阿里云函数计算等平台会限制写入位置，必须用它提供的临时路径（如
/tmp），且需在代码里硬编码，不能依赖ini_get() - 无持久存储场景下，上传大文件前先用
ini_set('upload_max_filesize', '2M')降级容错，避免临时磁盘爆满
临时目录这事，看着是配置项，实际是权限、路径、生命周期三者咬合的结果。漏掉任意一环，上传就静默失败——而且错误日志里常常只有一行 PHP Warning: move_uploaded_file(): Unable to move...，没更多线索。
