PHP无法实现实时图片上传预览，因其运行在服务端，无法访问用户未提交的本地文件；实时预览需前端用FileReader读取文件并渲染，PHP仅负责上传后的校验与保存。

PHP 本身无法“实时输出图片上传预览”，因为它是服务端语言，不直接操作浏览器 DOM 或读取本地文件；所谓“实时预览”，纯前端行为，PHP 在这里只负责接收、校验、保存上传的文件。真正实现上传前预览，靠的是 FileReader + input[type="file"] 的客户端 JS 能力。

为什么不能靠 PHP 实现实时预览？

PHP 运行在服务器上，用户点击“选择文件”时，文件还完全没发出去——它甚至没离开浏览器内存。此时 PHP 根本无从获取文件内容，更不可能生成预览 URL 或返回缩略图。试图用 PHP 输出预览，本质是混淆了前后端职责。

常见误解场景：

• 用户改完 $_FILES 就以为能立刻显示——其实这时还没提交表单
• 用 header("Location: ...") 跳转后才显示图片——这属于“上传完成后的展示”，不是“上传前实时预览”
• 把 base64 编码传给 PHP 再 echo 回来——多此一举，base64 完全可以在前端直接渲染

前端如何用 FileReader 实现真·实时预览？

只需监听 input[type="file"] 的 change 事件，用 FileReader 读取选中文件的 data URL，然后赋给 的 src 属性即可。整个过程不发请求，毫秒级响应。

关键代码片段（无需 PHP 参与）：

@@##@@

注意点：

• accept="image/*" 可限制文件类型，但仅作提示，不可信，后端仍需校验
• FileReader 不支持 IE9 及以下；如需兼容，得用 URL.createObjectURL()（但记得调用 revokeObjectURL 避免内存泄漏）
• 大图（如 >5MB）用 readAsDataURL 可能卡顿，可改用 createObjectURL 直接生成 blob URL

PHP 该做什么？——上传接收与安全校验

当用户点击“上传”按钮（比如表单提交或 AJAX 发送），PHP 才真正介入。它的核心任务是：确认文件合法、防止恶意上传、存到安全位置、返回结构化结果（成功/失败 + 图片路径等）。

必须做的几件事：

• 检查 $_FILES['xxx']['error'] === UPLOAD_ERR_OK，排除上传中断、超限等基础错误
• 用 finfo_open(FILEINFO_MIME_TYPE) 检查真实 MIME 类型，拒绝 text/plain 假装成 image/jpeg
• 验证文件扩展名是否在白名单内（['jpg','jpeg','png','gif']），且与 MIME 匹配
• 重命名文件（用 uniqid() . '.' . $ext），避免中文/特殊字符或覆盖攻击
• 保存到非 Web 可直接访问目录（如 /var/www/uploads/），并通过 PHP 脚本（如 show.php?id=abc123）控制输出，防止执行任意代码

示例校验逻辑节选：

$finfo = finfo_open(FILEINFO_MIME_TYPE);
$mimeType = finfo_file($finfo, $_FILES['photo']['tmp_name']);
finfo
_close($finfo);

$allowedTypes = ['image/jpeg', 'image/png', 'image/gif'];
if (!in_array($mimeType, $allowedTypes)) {
    die('非法文件类型');
}

$ext = pathinfo($_FILES['photo']['name'], PATHINFO_EXTENSION);
if (!in_array(strtolower($ext), ['jpg','jpeg','png','gif'])) {
    die('扩展名不合法');
}

真正容易被忽略的是：预览和上传是两个独立阶段，前者纯前端、后者需后端参与；混用会导致逻辑错乱、安全漏洞或体验断层。别让 PHP 背不该背的锅——它管好接收和校验，就足够了。