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免费学习笔记（深入）”；
关键代码片段（无需 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 背不该背的锅——它管好接收和校验，就足够了。
