简介一份基于HTML5的多图片上传预览源码包面向前端初学者与Web交互开发者主要解决本地图片多选、即时预览与拖拽上传场景无需服务器端参与。资源共18个文件包含页面入口、5个JavaScript逻辑脚本、1个CSS样式表、9张按钮与背景等图片素材整体压缩包仅145KB结构轻量、便于直接套用或改造。目前已有1470人学习下载。通过这份源码可深入理解HTML5 File API的readAsDataURL读取流程、change事件监听、闭包保存文件对象以及拖放事件处理等关键点附带可运行的页面与样式适合用于个人博客、后台管理系统的图片上传模块快速落地。无论是学习原生文件操作还是快速搭建上传模块都能从中获得可复用的代码片段与思路也可作为毕业设计或课程作业的参考资料。整体代码逻辑清晰、目录精简具备实际参考价值。1. 多图片上传预览为什么说选型比接口重要拿到一套 HTML5 多图片上传预览源码很多人第一反应是看上传接口怎么调。我拆完这份已测试的源码后想说的是真正让新手翻车的地方全在预览环节——浏览器对 blob 地址的限制、input 的重复选择、图片方向标记、ObjectURL 的内存回收任何一环没处理功能就像个黑匣子。这套源码解决的是从选择图片、生成缩略图、多选管理到准备上传的完整链路适合做后台表单、商品发布页这类需要连续选图的场景也适合前端新人拿来做入门实战。我会按选型、实现、提交、排错的顺序拆开讲每一步给出能直接运行的代码和参数说明。如果你是熟手可以直接跳到第 5 章看坑点如果是新手建议从头按顺序过一遍。2. 预览选型FileReader 还是 URL.createObjectURL2.1 两种机制dataURL 与 blob 地址的取舍HTML5 多图片上传预览本质是把用户选中的本地图片变成浏览器能识别的地址。常见实现方案有两种FileReader.readAsDataURL 和 URL.createObjectURL两个 API 的机制差别很大选错后面全是坑。FileReader.readAsDataURL 会把文件内容完整读成 base64 字符串形如data:image/jpeg;base64,...把字符串赋给 img 的 src 就能显示。优点是数据是纯字符串不依赖文件对象的生命周期放到哪里都能用缺点是 base64 比原文件大约 33%一张 5MB 的照片读进来就是 6.7MB 左右的字符串连续选十几张页面会明显卡顿。如果再用它重复生成多张缩略图内存很快吃紧。URL.createObjectURL 不去读文件内容而是给浏览器内部的 File 对象生成一个临时地址形如blob:http://localhost:8080/uuid。img src 指向这个地址时浏览器会按需读取磁盘文件生成速度快内存占用小。缺点是这个地址只是当前会话内的引用不用时必须手动调用 URL.revokeObjectURL 释放否则内存只增不减。两个方案的代码差异很小// 方式一FileReader 读成 dataURL const reader new FileReader(); reader.onload (e) { const dataUrl e.target.result; img.src dataUrl; }; reader.readAsDataURL(file); // 方式二ObjectURL 生成 blob 地址 const objectUrl URL.createObjectURL(file); img.src objectUrl; // 图片加载完再释放别在赋值前 revoke img.onload () URL.revokeObjectURL(objectUrl);reader.onload 里的e.target.result是完整 base64 文件数据ObjectURL 则是同步返回地址不需要等待文件读入。revoke 的时机要放在图片加载完成后如果赋值前就 revoke图片地址立即失效预览图裂开。关键区别可以这么记dataURL 适合「要做缩略图压缩后再上传」的场景因为你需要拿到像素数据重新绘制ObjectURL 适合「只做本地预览」的场景因为它快且省内存。很多演示代码习惯用 FileReader但对多图预览来说ObjectURL 才是更常见的首选方案。2.2 input multiple 与 accept参数不设对后面全乱预览入口是 file input两个属性必须设multiple 支持多选accept 限定文件类型。input typefile idfileInput multiple acceptimage/* /multiple 没有参数值只要写入就能一次选多张accept 按 MIME 类型或扩展名写image/*表示所有图片类型。但 accept 只是文件选择器的默认过滤项不是安全限制。在部分系统上用户仍然可以切到「所有文件」选一个 PDF所以前端 JS 要再做一次类型校验不能只靠 accept。另一个高频踩坑是 change 事件。每次选择文件后input.value 会记录所选文件路径如果用户第二次选择同一个文件value 与上一次相同浏览器不会触发 change。解决方式是事件回调末尾把 input.value 清空fileInput.addEventListener(change, function () { const files Array.from(this.files); // 渲染缩略图逻辑 renderThumbs(files); // 关键清空 value让同一文件也能再次触发 change this.value ; });这里有两个细节。Array.from 把 FileList 转成真正的数组因为 FileList 虽然长得像数组但只实现了部分数组方法直接调用 map、filter 会报错。清空 value 要在读取 files 之后因为 input 一旦重置this.files 会变成空列表先取值后清空顺序不能反。有人把清空放到 setTimeout 里等异步渲染完再执行结果 this.files 早就空了功能直接失效。2.3 选型对照什么时候用 FileReader什么时候用 ObjectURL用一张表把差异收拢对比项FileReader.readAsDataURLURL.createObjectURL返回内容base64 字符串blob: 临时地址内存占用约增大 33%大图压力大只生成引用按需读取生成速度需要完整读文件慢同步生成快使用限制无特别限制字符串可用于上传只能在当前页面会话内使用不可传给服务端典型用途缩略图压缩后上传、需要像素数据本地预览、粘贴图片即时回显我一般根据「是否要修改原图」来决定只做本地预览就 ObjectURL要压缩、旋转、加水印再上传就先把文件丢给 canvas 处理再用 canvas.toBlob 得到新文件最后把新文件交给 FormData。ObjectURL 不能作为上传内容因为它指向的是浏览器临时存储服务端拿不到真实二进制这点要特别注意。选型定了后面的代码结构才好搭。下面进入核心流程。3. 构建多图片预览从 FileList 到缩略图网格3.1 容器结构input 与预览区怎么组织实现多图预览先把 HTML 骨架搭清楚。一个完整的上传器由三部分组成选择入口、预览容器、提示文字。div classuploader input typefile idfileInput multiple acceptimage/* / div idpreviewGrid classpreview-grid/div div iduploadTip classupload-tip支持多选最多 9 张/div /divinput 可以保持可见也可以隐藏后通过按钮触发。常见做法是把 input 用绝对定位覆盖在按钮上透明度设为 0这样点击按钮时实际点到的是 input文件选择框照常弹出界面却能完全自定义。previewGrid 是缩略图容器我用 flex wrap 排布每张缩略图带一个删除按钮。基础样式.preview-grid { display: flex; flex-wrap: wrap; gap: 12px; } .preview-item { position: relative; width: 100px; height: 100px; } .preview-item img { width: 100%; height: 100%; object-fit: cover; border-radius: 6px; } .preview-item .remove-btn { position: absolute; top: 4px; right: 4px; }object-fit: cover 的作用是让图片等比裁剪填满容器而不是拉伸变形缩略图看起来整齐。如果业务要求显示完整原图可以改成 contain代价是四周会有留白。删除按钮用 button 而不是 a 标签避免默认跳转行为。3.2 渲染流程files - 预览对象 - DOM核心逻辑在 change 事件里。我习惯把状态集中放在一个 uploader 对象里维护而不是散落在全局变量中。const uploader { selectedFiles: [], // 当前已选文件 maxCount: 9, maxSizeMB: 5, }; document.getElementById(fileInput).addEventListener(change, function () { const files Array.from(this.files); const validFiles filterFiles(files); validFiles.forEach((file) { if (uploader.selectedFiles.length uploader.maxCount) return; uploader.selectedFiles.push(file); addPreviewItem(file); }); this.value ; }); function filterFiles(files) { return files.filter((file) { if (!file.type.startsWith(image/)) { console.warn(忽略非图片文件:, file.name); return false; } if (file.size uploader.maxSizeMB * 1024 * 1024) { console.warn(超过大小限制:, file.name); return false; } return true; }); }filterFiles 在进入数组前拦截类型和大小避免脏数据污染状态。file.size 单位是字节maxSizeMB 是兆换算时要乘 1024 * 1024。console.warn 调试期够用真实产品换成界面提示即可。addPreviewItem 负责生成缩略图function addPreviewItem(file) { const item document.createElement(div); item.className preview-item; const img document.createElement(img); const objectUrl URL.createObjectURL(file); img.src objectUrl; img.dataset.objectUrl objectUrl; const removeBtn document.createElement(button); removeBtn.className remove-btn; removeBtn.textContent ×; removeBtn.dataset.id file.name _ file.lastModified; removeBtn.addEventListener(click, () removePreviewItem(item, file, objectUrl)); item.appendChild(img); item.appendChild(removeBtn); document.getElementById(previewGrid).appendChild(item); }dataset.objectUrl 存的是临时地址删除时靠它释放。删除按钮的 dataset.id 我用 name lastModified 拼接防止同名文件相互覆盖真实场景更稳的是给每个文件分配递增序号或 UUID否则两个同名但不同内容的文件会冲突。3.3 参数设置数量、大小、类型三个边界数量、大小、类型这三个限制一般会集中在配置对象里不要散落在业务代码中。示例const CONFIG { maxCount: 9, maxSizeMB: 5, allowedTypes: [image/jpeg, image/png, image/webp], acceptAttr: image/*, };allowedTypes 如果只允许三种格式accept 可以写成image/jpeg,image/png,image/webp比image/*更严格。JS 里的 allowedTypes 是二次校验用的HTML 的 accept 只是选择器过滤两层职责不同不能互相替代。数量限制有一个容易被忽略的细节如果用户一次选了 12 张而你只允许 9 张应该保留前 9 张并丢弃剩余部分。上面代码用 forEach 加 return 来跳过超出部分但 forEach 不能 break后面的无效文件还是会循环一遍。更严谨的做法用 for...offor (const file of validFiles) { if (uploader.selectedFiles.length uploader.maxCount) { console.warn(超出数量上限剩余文件忽略); break; } uploader.selectedFiles.push(file); addPreviewItem(file); }for...of 可以 breakforEach 不行。这个差异在面试和实际开发中都容易踩。3.4 删除缩略图同步数组、释放地址删除是预览流程最容易漏的一环。上面删除按钮绑定了 removePreviewItemfunction removePreviewItem(item, file, objectUrl) { // 从数组移除 const index uploader.selectedFiles.findIndex((f) f file); if (index -1) uploader.selectedFiles.splice(index, 1); // 释放 ObjectURL防止内存泄漏 if (objectUrl) URL.revokeObjectURL(objectUrl); // 移除 DOM 节点 item.remove(); }三步缺一不可。如果只删了 DOMselectedFiles 里还留着文件最终提交 FormData 时会多传一张用户已经删掉的图如果只删数组DOM 上还是旧预览图如果忘了 revokeObjectURL 会一直挂在内存里。删除按钮事件已经闭包持有 file 和 objectUrl所以不用担心找不到引用。到这里一个完整的「多选 - 校验 - 预览 - 删除」闭环就出来了。测试时打开 DevTools 的 Memory 面板反复添加删除图片观察 blob URL 数量是否稳定。如果只增不减优先检查有没有哪条分支漏了 revoke。4. 把图片真正交到服务端FormData 与上传进度4.1 FormData 组装字段名与 Content-Type 的坑预览只是前半程真正上传要靠 FormData。先看基础版function uploadFiles(files) { const formData new FormData(); files.forEach((file, index) { formData.append(images[], file, file.name); }); return fetch(/api/upload, { method: POST, body: formData, }); }append 的三个参数分别是字段名、文件对象、文件名。字段名写成images[]是后端解析数组的通用写法PHP 的$_FILES[images]会自动收集多文件Node 的 multer 用.array(images)接收。第三个参数必须传真实文件名有些后端依赖它生成存储名不传会变成一串随机串。这里最容易翻车的是 Content-Type。fetch 在传入 FormData 时浏览器会自动生成multipart/form-data并带上 boundary 分隔符。如果你自己手动写headers: {Content-Type: multipart/form-data}反而会丢掉 boundary服务端无法解析出文件这是高发问题。所以使用 FormData 时千万别手动设置 Content-Type。如果上传时需要带业务参数可以继续 appendformData.append(categoryId, 1001); formData.append(description, document.getElementById(desc).value);文本字段会出现在 FormData 的普通字段区后端按同名取值即可。文本字段和文件字段的顺序没有强制要求但习惯上把文本放在前面后端日志读起来更直观。4.2 用 XHR 做上传进度为什么不用 fetchfetch 写起来简洁但没有内置的上传进度事件。要做进度条还是得回退到 XMLHttpRequestfunction uploadWithProgress(files, onProgress) { const formData new FormData(); files.forEach((file) formData.append(images[], file, file.name)); const xhr new XMLHttpRequest(); xhr.open(POST, /api/upload); xhr.upload.onprogress (e) { if (e.lengthComputable) { const percent Math.round((e.loaded / e.total) * 100); onProgress(percent); } }; xhr.onload () { if (xhr.status 200 xhr.status 300) { console.log(上传完成, xhr.responseText); } else { console.error(上传失败, xhr.status); } }; xhr.onerror () console.error(网络异常); xhr.send(formData); }onprogress 只在 lengthComputable 为 true 时才能计算百分比某些服务器不返回 Content-Lengthe.total 会是 0强行除零会得到 Infinity。onload 里必须判断 status只看请求完成不行4xx、5xx 都算失败。取消上传用 xhr.abort()会触发 onerror 或 onabort把 xhr 实例挂到外部变量就能给用户一个取消按钮。XHR 同样不要手动设置 Content-Type它会和 fetch 一样自动生成 multipart 头。进度百分比回调里不要做 DOM 重绘把状态先存到变量里用 requestAnimationFrame 或节流函数再更新 UI否则 1 秒几十次回调会让页面很吃力。4.3 服务端接收和大小限制前后端参数要对齐前端已经限制了 maxSizeMB但服务端才是最终闸门。不同后端配置差异很大; PHP 配置 upload_max_filesize 5M post_max_size 20M// Node multer 示例 const multer require(multer); const upload multer({ limits: { fileSize: 5 * 1024 * 1024, files: 9 }, }); app.post(/api/upload, upload.array(images), (req, res) { console.log(req.files); res.json({ ok: true, count: req.files.length }); });如果前端配置和后端不一致会出现前端校验通过、后端拒绝的尴尬。尤其注意 PHP 有两个配置upload_max_filesize 控制单个文件post_max_size 控制整个请求体多图上传时 post_max_size 必须大于多张文件总和否则传 8 张时会报错但提示很隐晦。Nginx 环境下还有 client_max_body_size默认 1M比 PHP 限制更早拦截请求。层级参数常见默认建议检查浏览器maxSizeMB无前端 UI 提示PHPupload_max_filesize2M单文件上限PHPpost_max_size8M请求体上限Nginxclient_max_body_size1M反向代理上限如果上传返回 413 请求实体过大先查 Nginx返回 500 再查 PHP 错误日志。我一般把 Nginx 的 client_max_body_size 设为前端总上限的 1.2 倍留出 multipart 头的余量。总上限 maxCount * maxSizeMB9 张 5MB 就是 45MBNginx 设 54M 比较稳。5. 多图片上传避坑与排查五个高频现场5.1 预览图裂开blob 地址在本地 file:// 下失效现象双击 HTML 文件直接在浏览器打开选择图片后预览区域显示空图或裂图但放到 http 服务器上就正常。原因本地 file:// 页面没有源浏览器限制 blob: URL 的加载。ObjectURL 生成的地址在 file:// 协议下不被信任img 无法加载它。而 dataURL 不受这个限制。解决本地调试不要直接双击 HTML。常见做法是起一个本地静态服务python3 -m http.server 8080然后访问 http://localhost:8080 再测试。如果没有 Python用代码编辑器的 Live Server 插件也行。如果交付物要求必须双击就能跑那就把预览从 ObjectURL 换回 FileReader 的 dataURL代价是内存占用明显变高。这个坑排在排查清单第一位因为它不是源码 bug是浏览器安全策略很多人会误以为是代码写错了。5.2 同一个文件第二次选择不触发 change现象用户第一遍选 1.jpg预览正常删除缩略图后再点 input 选同一个 1.jpg页面没有任何反应。原因input 内部 value 仍然记录着上一次选择的文件路径浏览器认为「当前值没有变化」于是不触发 change 事件。这是所有 file input 的通病和浏览器版本无关。解决在 change 回调末尾把 input.value 置空代码见 2.2。要注意取值顺序先 const files this.files再 this.value 。如果反过来先清空this.files 已经变成空列表后面什么都取不到。有人把清空放在 submit 后才执行结果删掉一张再补选同一张依然没反应所以这个操作必须紧跟 change。5.3 多图顺序错乱FileList 与异步渲染的锅现象一次选 6 张图预览先显示后选的或者顺序随机尤其图片较大时更明显。原因常见两种情况。一是直接遍历 FileList 时误改了顺序二是更常见的——在 img.onload 回调里 append 到 DOM而每张图加载耗时不同小图先完成于是 DOM 顺序和文件选择顺序不一致。解决按数组顺序先生成 DOM 占位再填充图片或用 Promise.all 统一插入const items await Promise.all(files.map((file) { return new Promise((resolve, reject) { const img new Image(); img.onload () resolve(createPreviewItem(file, img)); img.onerror reject; img.src URL.createObjectURL(file); }); })); items.forEach((item) container.appendChild(item));Promise.all 保证所有图片就绪后再按原数组顺序插入顺序不会乱。注意某张图加载失败时要在 reject 里处理避免整个链路卡住。更轻量的方案是不等 onload直接赋 ObjectURL 后同步 append浏览器会按 DOM 挂载顺序渲染顺序通常不会错。5.4 图片越选越多内存跟着涨现象测试时反复添加删除图片页面越来越卡系统内存持续上升。原因用了 ObjectURL 但没有调用 revoke或者用 FileReader 读 base64 后没有释放引用。ObjectURL 每生成一个就占一段内存映射不及时释放内存只增不减直到页面关闭。解决删除和替换预览时显式 revoke代码见 3.4。另外有一个容易忽略的分支图片加载失败也要 revoke否则失败的死地址依然占内存。在 addPreviewItem 里补上img.onerror () URL.revokeObjectURL(objectUrl);测试时用 DevTools 的 Memory 面板拍快照对比反复增删前后的 detached 节点数量能直观看到有没有泄漏。5.5 手机拍了照片预览方向反了现象用手机竖着拍一张照片预览区和上传后的图片都是横的。原因相机在原始 JPEG 里写入 EXIF Orientation 方向标记img 标签和部分浏览器渲染时没有完整处理该标记或者用 canvas 处理缩略图时丢弃了原数据。解决生成缩略图之前读取并矫正 EXIF。如果用 canvas 压缩要把 Orientation 转成旋转角度再重绘。轻量方案是引图片处理库的 orient 方法不想引库就用 6.1 的 createImageBitmap 方案它在多数现代浏览器里能自动识别 EXIF。PNG 照片通常没有此问题主要针对 JPEG。这五个问题基本覆盖了拆这套源码时会遇到的所有「看起来像 bug 但其实是机制」的情况。按 5.1 到 5.5 顺序过一遍能省下大量排查时间。6. 进阶把预览升级成自动压缩与方向校正6.1 canvas 压缩与 JPEG 质量参数多图片上传场景里用户手机里的原图动不动就是 3MB 以上直接传原图既慢又费流量。在预览阶段做一次压缩上传体积能降不少。示例async function compressImage(file, maxWidth 1280, quality 0.8) { const bitmap await createImageBitmap(file); const scale Math.min(1, maxWidth / bitmap.width); const canvas document.createElement(canvas); canvas.width Math.round(bitmap.width * scale); canvas.height Math.round(bitmap.height * scale); const ctx canvas.getContext(2d); ctx.drawImage(bitmap, 0, 0, canvas.width, canvas.height); const blob await new Promise((res) canvas.toBlob(res, image/jpeg, quality)); return blob; }createImageBitmap 直接拿到像素数据比先 FileReader 再 new Image 省内存而且多数现代浏览器会自动应用 EXIF 方向压缩后不会歪。maxWidth 按业务定后台列表用 1280 足够quality 0.8 在体积和清晰度之间折中。如果原图宽度小于 maxWidthscale 为 1不会把小图放大变糊。6.2 本地验证流程验收多图片上传我习惯按三条用例走重复选同一个文件、一次传 10 张大图、真机拍照方向。打开 DevTools 的 Network 面板点击上传后找到 upload 请求检查 Payload 里 FormData 的类型、字段名和文件数量再切到 Console 确认没有 ObjectURL 泄漏报错。方向问题用真机拍竖图和横图各一张看预览和最终上传是否一致。这份源码已经把这套流程中的核心逻辑打包好下载后对照第 5 章的五个问题先测一遍再按第 6 章改成自己的配置项即可。从那以后我每次验收多图片上传都强制走一遍「重复选同一个文件 10 张大图 真机拍照」三个用例顺序和方向没确认前绝不发版。希望帮到你。本文还有配套的精品资源点击获取
