PHP 上传临时文件没有进入 upload_tmp_dir 怎么定位回退目录

PHP 上传临时文件没有进入 upload_tmp_dir，通常不是 PHP 忽略了配置，而是当前请求读到的配置、目录权限或 open_basedir 范围与预期不一致。PHP 官方手册说明：这个目录必须对 PHP 运行用户可写；如果没有设置，或设置的目录不可写，PHP 会回退到系统默认临时目录。

排查时不要先改 move_uploaded_file() 的目标路径。先记录当前请求的有效配置、PHP 运行用户能否写入目标目录，以及 $_FILES['file']['tmp_name'] 的实际路径，这三组证据能把“配置没加载”“目录不可写”和“系统目录被限制”区分开。

官方资料：https://www.php.net/manual/en/ini.core.php

先分清临时目录和永久保存目录

上传请求到达 PHP 后，文件会先落到上传临时目录，文件信息再通过 $_FILES 暴露给脚本。tmp_name 是当前上传文件的临时路径；调用 move_uploaded_file() 后，文件才会进入应用指定的永久保存路径。本文只追踪前一段，不讨论业务保存目录。

因此，“最终文件没有出现在 /data/uploads”不能证明 upload_tmp_dir 失效。应该在文件还没移动前记录临时路径，并同时记录当前 SAPI 看到的配置。

读取当前请求真正加载的配置

命令行执行的 php -i 和 PHP-FPM 处理请求的配置可能不同。把下面的诊断脚本放在与上传接口相同的 SAPI 下运行，重点看 ini_get('upload_tmp_dir')、配置文件来源和扫描目录。

upload_tmp_dir 为空时，PHP 会按系统默认临时目录处理；它不是“配置读取失败”的唯一证据。若配置文件来源不是你修改的那一份，先确认 PHP-FPM 池、Apache 模块或容器里的实际 SAPI。

检查配置目录是否真的可写

官方要求这个目录对 PHP 运行用户可写。目录存在但只有登录用户可写，仍可能触发回退。下面的代码只做路径和权限判断，不能替代服务器上的最小权限设置。

如果配置目录 exists=yes 但 writable=no，这已经足以解释为什么上传文件看起来落到了系统目录。修复时要以 PHP-FPM 或 Web Server 的运行用户为准，并检查目录的父级遍历权限；不要简单地把目录改成全员可写。

把 open_basedir 放进同一条判断链

open_basedir 会限制 PHP 能访问的目录。PHP 手册特别说明：当上传目录不可用而回退到系统默认目录时，如果启用了 open_basedir，这个系统默认目录也必须在允许范围内，否则上传可能直接失败。

这里的结论要结合服务器权限和错误日志解释。open_basedir 的字符串看起来包含某个父目录，不代表真实路径一定允许；符号链接解析、目录存在性和 PHP 运行用户都要分别确认。

从 $_FILES[tmp_name] 追踪实际落点

真正上传时，在处理文件之前记录 tmp_name、realpath 和当前配置。日志中只保留路径和状态，不把上传内容、Cookie 或授权头写进去。

 $tmpName,
    'realpath' => $tmpName !== '' ? (realpath($tmpName) ?: '') : '',
    'upload_tmp_dir' => (string) ini_get('upload_tmp_dir'),
    'system_temp' => sys_get_temp_dir(),
];

error_log('upload-temp-diagnosis ' . json_encode($record, JSON_UNESCAPED_UNICODE));
echo '临时文件路径：', $tmpName;

如果 tmp_name 的父目录与配置目录不同，优先回看本次请求的 php.ini 来源和配置目录权限。sys_get_temp_dir() 可以提供系统临时目录的对照线索，但最终判断仍以 tmp_name 和服务器日志为准。

按证据修复，不要先改上传业务代码

可以按下面的顺序收敛问题：

1. 如果 php_ini_loaded_file() 指向错误的配置文件，修正 PHP-FPM 或 Web SAPI 的加载方式并重载对应服务。
2. 如果 upload_tmp_dir 为空，按部署方式在正确的系统级配置中设置目录，然后让运行中的 SAPI 重新加载配置。
3. 如果目录不存在或对 PHP 运行用户不可写，创建目录、设置归属和最小权限，并保留父级目录的遍历权限。
4. 如果配置目录可写但回退后上传失败，检查 open_basedir 是否允许配置目录和系统默认目录，再结合错误日志判断。
5. 修复后重新记录 tmp_name。只有实际路径、有效配置和权限证据同时一致，才说明回退问题被解决。

不要把上传临时目录设置到公开 Web 根目录，也不要通过放宽权限来掩盖运行用户配置错误。临时文件仍然是不可信输入，业务层应该在移动到永久目录前完成类型、大小和内容检查。

几个容易误判的情况

命令行看到了配置，网页请求却没有。 CLI 和 PHP-FPM 可能加载不同的 php.ini，必须在同一个请求入口输出配置来源。

配置目录存在，但文件还是出现在系统目录。 目录存在不等于 PHP 运行用户可写；同时检查 is_writable()、父目录遍历权限和运行用户。

临时文件路径为空。 先看 $_FILES['file']['error']。文件过大、请求体超限或没有选择文件时，不能继续按“目录回退”分析。

修复后仍然失败。 把 open_basedir、系统临时目录权限和 PHP-FPM 错误日志放在一起看，不要只盯着 upload_tmp_dir 一行。

结论：用三组证据定位回退目录

PHP 上传临时文件没有进入 upload_tmp_dir 时，最短路径是：用同一 SAPI 读取有效配置来源，用 PHP 运行用户检查配置目录是否可写，再从 $_FILES['tmp_name'] 记录实际路径。配置未加载、目录不可写和 open_basedir 限制分别对应不同修复动作。

只要保留普通上传错误处理、最小目录权限和不暴露临时文件内容的日志策略，就能在不改永久保存流程的前提下把回退目录查清楚。

相关问题

upload_tmp_dir 为空是不是一定配置错误？

不一定。PHP 允许未设置该项，并在这种情况下使用系统默认临时目录。是否符合部署预期，要看实际的 tmp_name、权限和安全策略。

可以在业务代码里用 ini_set 修改 upload_tmp_dir 吗？

不要把它当作通用修复方式。该配置属于系统级配置，实际可修改级别取决于 PHP 运行方式；应在正确的 php.ini 或对应部署配置中设置，并确认 SAPI 已重新加载。

怎么确认 PHP-FPM 用的是哪个用户？

查看 PHP-FPM 池配置中的运行用户，并结合进程管理工具和服务配置确认。应用内的 get_current_user() 不能可靠代表 Web 请求进程的系统用户。