symfony 7 文件上传需手动触发验证并确保临时文件清理：绕过表单时须调用 $validator->validate()，验证前先检查 $file->isvalid()，验证后立即 moveto() 清理临时文件，协程环境下需隔离 upload_tmp_dir 并避免依赖 __destruct()。
Symfony 7 的文件上传本身不难，难的是在虚拟线程或协程环境下保持验证可靠、临时文件不泄露、错误信息不混淆。直接用 UploadedFile 类配合表单类型是安全起点，但绕过表单（比如 API 直传 multipart）时，validate() 不会自动触发，必须手动调用校验器。
如何正确绑定 UploadedFile 到表单并触发验证
很多人以为只要写了 FileType::class 就万事大吉，其实验证逻辑默认是“懒加载”的——只有调用 $form->handleRequest($request) 后，且表单提交成功，验证才会执行。若跳过表单（如用 Request::files 手动取文件），ConstraintViolationList 就不会生成。
- 必须确保表单配置中启用了
constraints，例如new File(['maxSize' => '5M']) -
UploadedFile实例不能提前调用moveTo()，否则验证时会因文件已移动而失败（报错"The file could not be found."） - 若使用自定义验证器（如检查图片 EXIF 或 PDF 内容），需在
validate()方法里显式调用$file->isValid()和$file->getError() === UPLOAD_ERR_OK，否则上传失败的文件可能被静默忽略
API 场景下手动验证 UploadedFile 的关键步骤
REST 接口通常不走 Symfony 表单，而是从 $request->files->get('document') 获取 UploadedFile 实例。此时没有表单上下文，验证器不会自动运行，必须手动注入并调用。
- 获取文件后，先检查
$file instanceof UploadedFile和$file->isValid()，避免空值或上传中断导致崩溃 - 手动创建验证约束：例如
new File(['mimeTypes' => ['application/pdf'], 'maxSize' => '10M']) - 用
$validator->validate($file, $constraint)获取ConstraintViolationListInterface，再遍历输出错误 - 切勿在验证前调用
$file->getClientOriginalName()或$file->getClientMimeType()—— 这些方法在文件无效时会抛出异常，应放在isValid()之后
虚拟线程/协程环境下的临时文件清理风险
Symfony 默认把上传文件暂存到系统临时目录（如 /tmp），但在 Swoole 或 Fiber 环境中，PHP 进程长期运行，$_FILES 的底层资源不会像 FPM 那样随请求结束自动释放。若忘记手动 unlink() 或未启用自动清理，临时文件会越积越多。
- 推荐做法：验证通过后立即用
$file->moveTo($targetPath)，该方法内部会自动清理原始临时文件 - 若需预处理（如缩略图生成），应在新路径操作完再删除原文件，不要依赖
__destruct()—— 协程调度下析构时机不可控 - 禁用
upload_tmp_dir的全局设置，改用ini_set('upload_tmp_dir', sys_get_temp_dir() . '/symfony-upload-' . getmypid())隔离协程间临时目录（需配合进程生命周期管理）
最易被忽略的是：上传验证错误时，UploadedFile 对象仍持有临时文件句柄，若没捕获异常或没做兜底清理，这个文件会在内存中滞留直到协程退出——而协程可能持续数小时。务必在每个分支结尾确认文件是否已被移动或删除。
