PHP 5.6升级到7.2后文件上传不兼容怎么办_排查curl_file

upload_err_no_file（4）在php 7.2+中严格触发，不再静默返回upload_err_ok；必须配合is_uploaded_file()和size>0双重校验，且注意多维表单结构与curl_file_create()三参数调用要求。

php 5.6升级到7.2后文件上传不兼容怎么办_排查curl_file_create用法差异

UPLOAD_ERR_NO_FILE 在 PHP 7.2+ 中不再“静默容忍”空字段

PHP 5.6 对未选择文件但提交了 <input type="file"> 表单的情况，有时会返回 UPLOAD_ERR_NO_FILE（值为 4），有时却返回 UPLOAD_ERR_OK（0）——尤其在 CGI/FastCGI 模式下。PHP 7.2 起严格校验：只要浏览器没真正上传任何内容，$_FILES['file']['error'] 就一定是 UPLOAD_ERR_NO_FILE，不会再“假装 OK”。

这意味着你不能只靠 $_FILES['file']['error'] === UPLOAD_ERR_OK 就直接走后续逻辑。

必须同时检查 is_uploaded_file($_FILES['file']['tmp_name']) —— 这是唯一能确认文件真实来自上传流程的判断，file_exists() 或 is_file() 都可能被绕过
额外加一层 $_FILES['file']['size'] > 0，防零字节上传（某些 Nginx + PHP-FPM 组合在旧版中漏判 UPLOAD_ERR_NO_FILE）
如果用的是表单多维嵌套名（如 name="data[files][]" ），注意 PHP 7.4+ 的 $_FILES 结构已变为三维，循环前先 var_dump($_FILES) 看清层级

curl_file_create() 在 PHP 7.2+ 中行为更严格，不能混用字符串路径

PHP 5.6 允许你传一个字符串路径给 curl_file_create()，比如 curl_file_create('/tmp/uploaded.jpg')，它会自动尝试读取并封装。PHP 7.2 开始，这个函数只接受 CURLFile 实例或明确构造的 curl_file_create($filename, $mimetype, $postname) 三参数调用，否则抛出 Warning 并返回 false。

常见错误现象：curl_setopt(): Invalid curl file type 或 POST 请求体为空。

CurlShip Directory Submission

向CurlShip提交产品，这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品，支持OG标签抓取、带徽章的dofollow链接及层级升级。

下载

不要写 curl_file_create($_FILES['file']['tmp_name']) 单参数调用 —— 即使路径存在，PHP 7.2+ 也会拒绝
正确写法是显式传三参数：curl_file_create($_FILES['file']['tmp_name'], $_FILES['file']['type'], $_FILES['file']['name'])
如果 $_FILES['file']['type'] 为空（浏览器未提供 MIME 类型），建议 fallback 到 mime_content_type($_FILES['file']['tmp_name'])，但注意该函数在 PHP 8.0+ 已废弃，可用 finfo_file(finfo_open(FILEINFO_MIME_TYPE), ...) 替代

move_uploaded_file() 权限检查变激进，目标目录 umask 必须显式重置

PHP 7.2+ 对 move_uploaded_file() 的目标路径权限校验更严格：如果目标目录由 Web 服务器（如 nginx 用户）创建且继承了系统 umask（如 0022），那么生成的文件可能因缺少组/其他用户写权限而失败，尤其在配合某些 SFTP 或 NFS 存储时。

典型报错：move_uploaded_file(): Unable to move ... Permission denied，但 is_writable() 返回 true。

创建目标目录时，务必在 mkdir() 前调用 umask(0)，再执行 mkdir($dir, 0755, true)
避免依赖 chmod() 后置修正 —— move_uploaded_file() 是原子操作，不走普通文件写入流程，chmod 不影响其权限判定
若用 stream_copy_to_stream() 手动复制替代 move_uploaded_file()，需自行处理临时文件清理和并发安全，不推荐用于生产上传主路径

高像素图片上传失败不是 PHP 版本问题，而是 GD/Imagick 库限制

WordPress 用户常遇到 8000×5000px 图片上传报 HTTP 错误，误以为是 PHP 5.6 升级到 7.2 后“修复”了——其实不是 PHP 解析层的问题，而是 GD 库在内存不足时提前 abort，PHP 7.2+ 只是让这个 abort 更早暴露为 500 错误，而非静默卡死。

关键点：PHP 本身不限制图片像素，限制来自图像处理扩展。

GD 默认有 memory_limit 和 max_execution_time 双重压制，大图缩略图生成极易超限；改用 Imagick 扩展可缓解（支持流式处理）
检查 phpinfo() 中 gd.jpeg_ignore_warning 是否为 On，否则损坏 JPEG 元数据会直接中断上传
WordPress 插件如 WP Offload Media 或自定义上传钩子中若调用了 wp_get_image_editor()，需确保后端扩展支持对应尺寸，否则失败发生在 upload 完成后、生成缩略图阶段