symfony 6.1 不管理 php 上传临时文件生命周期，问题根源在 php 配置、环境权限或代码未闭环：需确认 upload_tmp_dir 可写、上传限制匹配、moveto() 正确调用，并排查 systemd-tmpfiles 等系统级清理干扰。
Symfony 6.1 本身不负责管理 PHP 上传临时文件的生命周期，临时目录清理异常不是 Symfony 框架层的问题，而是底层 PHP 配置、运行环境或应用代码处理逻辑未闭环导致的。
确认 upload_tmp_dir 是否有效且可写
PHP 接收上传文件时，会先写入 upload_tmp_dir 指定的路径（如 /tmp 或 C:\Windows\Temp）。若该目录不存在、权限不足或被系统自动清理，就会出现“文件无法上传”或 moveUploadedFile() 失败。
- 在控制器或命令中执行
var_dump(ini_get('upload_tmp_dir'));查看实际路径 - 检查该路径是否存在，且 Web 服务器用户（如
www-data、nginx或_www）有读写权限 - Linux 下可运行
ls -ld $(php -r "echo ini_get('upload_tmp_dir');")快速验证 - Windows 用户注意：IIS 或 Nginx+PHP-FPM 场景下，
upload_tmp_dir可能继承自服务账户而非当前登录用户
检查 PHP 和 Web 服务器的上传限制是否匹配
上传失败常表现为静默中断或 500 错误，本质是请求在到达 Symfony 前已被截断。
- 确认
post_max_size≥upload_max_filesize（例如都设为20M） - Apache 用户检查
LimitRequestBody；Nginx 用户必须配置client_max_body_size，且值要 ≥ PHP 的限制 - 调用
$file->getError()获取具体错误码：UPLOAD_ERR_NO_TMP_DIR（找不到临时目录）、UPLOAD_ERR_CANT_WRITE（写入失败）等，比猜测更直接
验证 UploadedFile 是否被正确 move 并避免残留
Symfony 的 UploadedFile 对象仅包装 PHP 原生 $_FILES 数据，其 getRealPath() 指向的就是 upload_tmp_dir 中的临时文件。若未调用 moveTo()，该文件将在请求结束时由 PHP 自动清理——但前提是 PHP 配置未禁用此行为。
- 确保业务逻辑中明确调用
$file->move($targetDir, $safeName)，且$targetDir已存在并可写 - 不要在 move 前做耗时操作（如大文件解析、远程调用），否则可能触发超时，导致临时文件滞留
- 避免重复 move：
moveTo()成功后再次调用会报错，也可能干扰清理逻辑 - 临时文件不会“堆积”在 Symfony 层，但若 move 失败又没捕获异常，就等于放任 PHP 临时文件留在原地等待系统清理
排查系统级自动清理干扰
Linux 的 /tmp 目录常被 systemd-tmpfiles 按规则清理（如 10 天未访问即删除），而 PHP 临时文件默认就在其中。Tomcat、Node.js 等其他进程创建的同名子目录可能被误删，间接影响 PHP 上传上下文。
- 运行
systemd-analyze cat-config tmpfiles.d查看清理策略 - 如需长期稳定，建议显式配置
upload_tmp_dir = /var/tmp/php-uploads，并设置该目录的专属清理规则（如保留 24 小时） - 避免将 Symfony 应用与 Java/Tomcat 共用默认
/tmp，防止跨进程目录冲突
