简介这是一份面向前端初学者与Web开发者的HTML5多图片上传预览实战源码重点演示如何借助File API与拖放API在不依赖服务器端处理的前提下完成本地图片的读取与即时预览。资源包共18个文件包含9个png图片素材、5个js脚本、2个url快捷方式、1个css样式表与1个html页面压缩包约145KB其中js承担文件读取与上传控制逻辑css负责预览区样式html搭建文件输入与预览结构素材图片用于界面展示。已有1470人学习下载。源码完整呈现了FileReader的readAsDataURL转换、change事件遍历文件、闭包保存文件对象以及drop与dragover事件处理等关键实现并附带jQuery简化DOM操作读者可据此理解多图预览的完整流程掌握拖拽上传与本地预览的排错思路快速迁移到自己的项目中。1. 多图上传预览这件事难点从来不在上传做过表单的人都知道单张图片上传预览半小时能搞定一旦变成多图问题就全冒出来了用户连选十张图页面卡成幻灯片选完想删中间某一张索引全乱提交时后端收到的字段名对不上移动端 Safari 上 FileReader 直接给你摆烂。我见过太多项目在这块翻车最后退回「一张一张传」的原始方案。html5的多图片上传预览核心就三件事用input[typefile]的multiple拿到文件列表用FileReader或URL.createObjectURL把文件变成能塞进img.src的地址再用一个数组维护「待上传队列」和「已预览列表」的映射关系。听起来简单但每一步都有坑。这篇不讲空泛概念直接给你一份我反复用过、在 Chrome、Firefox、Safari 和主流安卓机上跑通的源码结构顺带把参数、内存回收和排错讲透。适合正在写后台管理系统、电商商品图上传、社区发帖配图的前端同学也适合想搞明白html5文件 API 到底怎么用的后端兼全栈。2. 先搞懂 FileReader 和 createObjectURL 到底选哪个2.1 两种预览方式的本质区别FileReader走的是「读文件内容 → 转成 base64 字符串 → 赋给 img.src」这条路。它把整个文件读进内存生成一个data:image/jpeg;base64,...的长字符串。优点是兼容性极好IE10 都能用而且这个 base64 可以直接发给后端存库。缺点是文件一大字符串体积膨胀约 33%十张 5MB 的图就是 66MB 的字符串挂在 DOM 上页面不卡才怪。URL.createObjectURL(file)走的是另一条路浏览器给这个 File 对象在内存里建一个临时引用返回一个blob:http://...的短地址。img 加载时直接读原始二进制不经过 base64 编码。优点是快、省内存十张图几乎瞬间出预览。缺点是必须手动URL.revokeObjectURL()释放否则只要页面不刷新这些 blob 就一直占着内存属于典型的「不释放就泄漏」。我的选型习惯很明确纯前端预览、不需要把图片内容传给后端做即时处理的一律用createObjectURL需要把图片 base64 存进 localStorage 或者直接 POST 给接口的才用FileReader。下面这张表是我整理的关键差异选型时对着看就行。对比项FileReadercreateObjectURL返回结果base64 字符串blob 短地址内存占用高约原文件 1.33 倍低仅引用是否需要手动释放否字符串随 DOM 回收是必须 revoke能否直接发后端能字符串直接传需配合 FormData大图性能差十张以上明显卡顿好基本无感兼容性IE10IE10部分老安卓有坑2.2 用 createObjectURL 跑通最小预览先看一段能直接跑的最小代码HTML 部分只需要一个多选 input 和一个预览容器。input typefile idfileInput acceptimage/* multiple div idpreviewBox/divconst input document.getElementById(fileInput); const box document.getElementById(previewBox); // 用数组记录每个预览对应的 blob 地址方便后续 revoke let blobUrls []; input.addEventListener(change, (e) { const files Array.from(e.target.files); files.forEach((file) { // 只处理图片类型防止用户选了 pdf 之类 if (!file.type.startsWith(image/)) return; const url URL.createObjectURL(file); blobUrls.push(url); const img document.createElement(img); img.src url; img.style.width 120px; img.style.margin 4px; // 把原始 File 对象挂在 img 上提交时直接取 img.dataset.fileName file.name; img.fileRef file; box.appendChild(img); }); });这段逻辑的关键点有三个。第一Array.from(e.target.files)把类数组转成真数组因为FileList没有forEach这是新手最常踩的坑。第二file.type.startsWith(image/)做类型过滤acceptimage/*只是给选择器加过滤用户仍可手动切到「所有文件」所以 JS 层必须再挡一次。第三把file对象直接挂在img.fileRef上这是后面提交时能拿到原始文件的关键比用索引去files里查更稳因为用户删图后索引会错位。2.3 参数怎么调尺寸、数量、格式三道闸预览不是把图原样塞进去就完事生产环境必须加限制否则用户传一张 8000×6000 的图浏览器渲染直接跪。我一般设三道闸。第一道是数量闸multiple本身不限制个数得自己数。常见做法是设一个MAX_COUNT 9超过就 alert 并截断。第二道是大小闸单文件超过5 * 1024 * 1024字节就拒绝这个值按业务调商品图可以放到 10MB头像 2MB 足够。第三道是尺寸闸用img.naturalWidth判断超过 4096 像素的图在预览时用 CSS 缩到 120px 显示但提交前最好用 canvas 压缩一遍否则后端存储压力大。const MAX_COUNT 9; const MAX_SIZE 5 * 1024 * 1024; function validate(files) { if (files.length MAX_COUNT) { alert(最多上传 ${MAX_COUNT} 张); return false; } for (const f of files) { if (f.size MAX_SIZE) { alert(${f.name} 超过 5MB); return false; } } return true; }这三个参数没有标准答案但有一条经验数量别超过 9因为九宫格是用户心智里最自然的布局单图别超过 5MB因为 4G 网络下上传 5MB 大约要 3 到 5 秒再大用户就以为卡死了。3. 把预览列表做成可增可删的队列3.1 用数组维护状态别直接操作 DOM新手最容易犯的错是「删图时直接img.remove()」结果提交时不知道还剩哪些文件。正确做法是用一个数组selectedFiles存所有待上传的 File 对象DOM 只是这个数组的渲染结果。删图时先从数组里 splice再重新渲染整个预览区。这样状态永远和界面一致不会出现「界面删了但数组还在」的玄学问题。let selectedFiles []; function renderPreview() { // 先释放旧的 blob防止内存泄漏 blobUrls.forEach((u) URL.revokeObjectURL(u)); blobUrls []; box.innerHTML ; selectedFiles.forEach((file, index) { const url URL.createObjectURL(file); blobUrls.push(url); const wrap document.createElement(div); wrap.className preview-item; const img document.createElement(img); img.src url; const del document.createElement(span); del.textContent ×; del.onclick () { selectedFiles.splice(index, 1); renderPreview(); // 重新渲染索引自然重排 }; wrap.appendChild(img); wrap.appendChild(del); box.appendChild(wrap); }); }这段代码里renderPreview每次全量重绘看起来「浪费」但九张图的量级下性能完全没问题换来的是状态绝对一致。真正要小心的是每次重绘前必须revokeObjectURL旧的地址否则删了又加、加了又删内存里会堆一堆没用的 blob这就是前面说的「不释放就泄漏」。3.2 提交时用 FormData 组装字段名要对齐后端预览做完最后一步是提交。多图上传的标准做法是FormData把所有 File 追加到同一个字段名下后端用数组接收。async function submit() { if (selectedFiles.length 0) { alert(请先选择图片); return; } const fd new FormData(); // 字段名 images 要和后端约定一致多个文件用同名 append selectedFiles.forEach((file) { fd.append(images, file, file.name); }); // 附加普通表单字段 fd.append(title, document.getElementById(title).value); const res await fetch(/api/upload, { method: POST, body: fd, // 千万不要手动设 Content-Type浏览器会自动带 boundary }); const data await res.json(); console.log(上传结果, data); }这里有个血泪经验用fetch发FormData时绝对不能手动写headers: { Content-Type: multipart/form-data }。一旦手写boundary 就丢了后端解析必然失败报的错还特别含糊往往只告诉你「文件为空」。让浏览器自己设它会带上正确的multipart/form-data; boundary----WebKitFormBoundary...。后端那边Node 的 multer、Java 的 MultipartFile[]、PHP 的$_FILES[images]都能直接接住同名多文件。3.3 上传进度和并发控制九张图一次性fetch出去用户看不到进度体验很差。常见做法是逐张上传用Promise串行或限并发。我一般限并发 3既不让浏览器同时开太多连接又能比串行快。async function uploadWithLimit(files, limit 3) { const results []; const queue [...files]; async function worker() { while (queue.length) { const file queue.shift(); const fd new FormData(); fd.append(images, file, file.name); const res await fetch(/api/upload, { method: POST, body: fd }); results.push(await res.json()); } } // 启动 limit 个 worker 并行消费队列 await Promise.all(Array.from({ length: limit }, worker)); return results; }worker函数用while (queue.length)不断从队列取任务Promise.all等所有 worker 跑完。这个模式比for循环里await快又比Promise.all(files.map(...))一次性全发出去更可控不会瞬间打满浏览器对同域名的并发限制。4. 避坑与排查那些让我加班到凌晨的细节4.1 现象Safari 上预览图显示不出来原因老版本 Safari 对URL.createObjectURL返回的 blob 地址在img上有渲染时机问题尤其是图片还没解码完就插入 DOM。解决给img加onload回调或者干脆在赋值src前先new Image()预加载。更稳的做法是加img.decoding async让浏览器异步解码避免阻塞主线程。4.2 现象删了图再选新图预览区出现重复或空白原因renderPreview里没有先清空box.innerHTML或者blobUrls没重置旧地址被 revoke 后新图复用了同一个引用。解决每次渲染前严格按顺序执行「revoke 旧地址 → 清空数组 → 清空 DOM → 重新生成」顺序不能乱。我见过有人先清 DOM 再 revoke结果 revoke 时拿不到旧地址泄漏照旧。4.3 现象后端收到的文件数量对不上或者字段名是 images[]原因前端FormData.append(images, file)用了单数后端按images[]接收或者反过来。解决前后端字段名必须逐字对齐PHP 那边如果写$_FILES[images]前端就必须 appendimages不能带方括号。这个错排查起来最费时间因为两边都觉得自己没错。4.4 现象大图预览时页面滚动卡顿原因十张 4000×3000 的原图直接以原始分辨率渲染浏览器每帧要处理上亿像素。解决预览用的img必须用 CSS 限制显示尺寸同时给容器加overflow: hidden。更彻底的做法是预览前用 canvas 把图缩到 800px 宽再生成 blob这样 DOM 里挂的就是缩略图内存和渲染压力都小一个量级。4.5 现象移动端选完图后 input 的 change 不触发第二次原因部分安卓浏览器里用户取消选择后input.value没清空再次选同一个文件不触发change。解决在change回调最后加一句e.target.value 把 input 重置。注意要在读取完files之后再清否则files会被一起清掉。5. 进阶用 canvas 压缩后再预览顺带解决方向问题前面讲的都是「原图预览」但生产环境我更推荐「压缩后预览」。原因有两个一是省内存二是能顺手解决手机拍照图片的 EXIF 方向问题——很多安卓机拍出来的图原图是横的靠 CSS 旋转不靠谱必须在 canvas 里处理。核心思路是读文件 → 用createImageBitmap或Image解码 → 画到 canvas 上按最大边缩放 →canvas.toBlob生成新的压缩 File → 用这个新 File 做预览和上传。async function compressImage(file, maxEdge 1600, quality 0.8) { const bitmap await createImageBitmap(file); let { width, height } bitmap; // 按最长边等比缩放 if (width maxEdge || height maxEdge) { const ratio Math.min(maxEdge / width, maxEdge / height); width Math.round(width * ratio); height Math.round(height * ratio); } const canvas document.createElement(canvas); canvas.width width; canvas.height height; const ctx canvas.getContext(2d); ctx.drawImage(bitmap, 0, 0, width, height); bitmap.close(); // 释放 ImageBitmap 占用的内存 return new Promise((resolve) { canvas.toBlob( (blob) { // 用压缩后的 blob 造一个新 File名字沿用原文件 const newFile new File([blob], file.name, { type: image/jpeg }); resolve(newFile); }, image/jpeg, quality ); }); }参数上maxEdge 1600是我在商品图和社区配图场景下的常用值再大对手机屏幕没意义quality 0.8是 JPEG 压缩质量肉眼几乎无损体积能降 60% 以上。createImageBitmap比new Image()好在它能直接吃 File 对象而且bitmap.close()能显式释放内存这是Image做不到的。注意createImageBitmap在部分老浏览器没有需要降级到ImageURL.createObjectURL的方案。用压缩后的 File 替换selectedFiles里的原始文件预览和上传都用新的整个链路的内存占用能降一个数量级。我现在的习惯是只要业务允许压缩一律先压再预览原图只在用户明确要求「上传原图」时才保留。这个习惯帮我省过好几次线上内存告警。最后说个我自己的教训多图上传这块别想着一次写完就完事一定要在真机上把「选十张 → 删中间三张 → 再选两张 → 提交」这条路径走三遍。我当年就是没走这条路径上线后用户反馈「删了图提交还是九张」查了一晚上才发现是索引没重排。希望帮到你。本文还有配套的精品资源点击获取