HTML5多图片上传预览核心实现与内存优化：从FileReader到ObjectURL

简介面向前端学习者的HTML5多图片上传预览完整源码包基于File API与拖放API实现本地图片批量选择、拖拽上传与即时预览无需服务器端处理即可完成数据URL转换兼顾传统文件选择与拖放两种交互方式。压缩包共18个文件压缩后大小145KB包含演示index.html、样式表zyUpload.css、脚本demo.js、zyUpload.js、zyFile.js等5个js文件以及9张png素材图片并附jquery-1.7.2.js和两个常用URL快捷入口控制与核心模块分工明确目录结构简洁便于对照学习。已有1469人浏览/学习该源码案例。代码通过监听change事件、调用FileReader的readAsDataURL方法把图片转为Base64字符串并嵌入img标签来实时预览同时用闭包保存当前文件对象清晰展示了drop/dragover事件处理等关键知识点并提供已测试的可运行环境适合希望掌握原生JavaScript实现前端文件上传与拖拽交互的开发者快速上手、修改与复用。1. HTML5 多图片上传预览为什么说这是前端最容易被低估的难点如果你没亲手写过一次多图片上传预览你大概率会认为它不过是一个input multiple加几行FileReader的事。但真等你在生产环境里被连续选中同一张图、竖拍照片方向错乱、连续上传大图把手机浏览器卡白屏之后你就会明白这套交互的水远比看起来深。本文拆的这份 html5 多图片上传预览源码是已经跑通完整链路选图 → 预览 → 删除 → 表单提交的可用实现涵盖了格式校验、数量限制、老图回显和内存释放这些实战必踩的点。适合正在做后台管理系统、移动端 H5 页面或课程设计里的上传模块的人直接参考。你可以把它当成一套可靠的地基而不是自己从FileReader文档第一行开始踩坑。2. 从 FileReader 到 URL.createObjectURL两种预览方案的选型与实现2.1 FileReader 的 readAsDataURL兼容性最好但内存开销翻倍几乎所有 HTML5 多图片上传预览的教程都会先告诉你用FileReader。这东西确实历史悠久兼容性覆盖到 IE10 都没问题但它有一个在移动端特别明显的短板readAsDataURL会把图片转成 Base64 字符串而 Base64 编码会让数据体积膨胀约 33%也就是说你选了一张 5MB 的照片浏览器内存里实际驻留了近 7MB 的字符串如果再渲染成img的src那又是一份解码后的位图缓存。手机浏览器在连续选十张图之后页面卡顿几乎是可以预见的。// 这是不太推荐用于多图场景的写法单图或小图可以用 const input document.getElementById(singleInput); input.addEventListener(change, function () { const file this.files[0]; if (!file) return; const reader new FileReader(); reader.onload function (e) { document.getElementById(preview).src e.target.result; }; reader.readAsDataURL(file); });这段代码的逻辑很直白监听change拿到File对象创建FileReader在onload里把e.target.result即 Base64 字符串赋给img的src。readAsDataURL是异步的所以结果只能通过回调拿。它的优点是没有任何兼容性顾虑缺点是如果图片较大且数量多内存会飙升。我一般只在做头像上传这种单张小图的场景才用FileReader多图预览我会直接换下一种方案。2.2 URL.createObjectURL推荐方案但必须手动静默释放URL.createObjectURL是比FileReader更现代的方案。它的机制是给浏览器内部的 Blob或 File生成一个临时对象 URL形式类似blob:http://localhost:8080/xxxxxx-xxxx-xxxx。这个 URL 直接指向浏览器内存中的原始文件数据不需要 Base64 编解码因此内存效率高得多。代价是这个 URL 占用的资源不会随img被移除而自动释放必须手动调用URL.revokeObjectURL(url)来显式回收否则就会形成内存泄漏。这是多图预览里最典型、也最容易被新手忽略的坑。// 使用 URL.createObjectURL 的预览方案 const input document.getElementById(multiInput); const previewBox document.getElementById(previewBox); input.addEventListener(change, function () { const files Array.from(this.files); // FileList 转普通数组方便 forEach files.forEach(file { if (!isValidImage(file)) return; const url URL.createObjectURL(file); const img document.createElement(img); img.src url; img.dataset.url url; // 存下 URL 供后续 revoke 使用 img.dataset.name file.name; previewBox.appendChild(img); }); this.value ; // 关键操作见第四章避坑 });这里每个文件都执行了一次createObjectURL每个生成的 URL 都存在dataset.url里就是为了后面删除某张图时能精确调用revokeObjectURL来释放。this.value 这行很重要如果不清空input的 value用户第二次选择同一个文件时change事件可能不会触发导致「同一张图选第二次没反应」。2.3 完整代码落地多图存储、预览渲染与表单提交这一小节给出一个可直接复制的完整多图上传预览实现。它比前面示例多了几个关键能力文件数组管理、删除时同步撤销预览与内存、提交时把文件列表装进FormData。!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 titleHTML5 多图片上传预览/title style #previewBox { display: flex; flex-wrap: wrap; gap: 10px; } .preview-item { position: relative; border: 1px solid #ddd; border-radius: 4px; } .preview-item img { width: 120px; height: 120px; object-fit: cover; display: block; } .preview-item .remove-btn { position: absolute; top: 4px; right: 4px; background: rgba(0,0,0,0.6); color: #fff; border: none; border-radius: 50%; width: 22px; height: 22px; cursor: pointer; line-height: 22px; text-align: center; } /style /head body input typefile idfileInput acceptimage/* multiple div idpreviewBox/div button idsubmitBtn提交/button script // 文件数组存储 { file, url, id } 三个字段 const fileList []; const fileInput document.getElementById(fileInput); const previewBox document.getElementById(previewBox); const submitBtn document.getElementById(submitBtn); const MAX_COUNT 9; // 最大9张 const MAX_SIZE 5 * 1024 * 1024; // 单张最大5MB const ACCEPT_TYPES [image/jpeg, image/png, image/gif, image/webp]; function isValidImage(file) { if (!ACCEPT_TYPES.includes(file.type)) { alert(不支持 ${file.type || 未知} 格式仅支持 ${ACCEPT_TYPES.join(, )}); return false; } if (file.size MAX_SIZE) { alert(${file.name} 超过 5MB 限制); return false; } if (fileList.length MAX_COUNT) { alert(最多上传 ${MAX_COUNT} 张); return false; } return true; } function renderPreview(file, url) { const item document.createElement(div); item.className preview-item; const img document.createElement(img); img.src url; const btn document.createElement(button); btn.className remove-btn; btn.textContent ×; // 删除按钮从数组移除 撤销URL 移除DOM btn.addEventListener(click, function () { const idx fileList.findIndex(f f.url url); if (idx ! -1) { URL.revokeObjectURL(fileList[idx].url); // 释放内存 fileList.splice(idx, 1); } item.remove(); }); item.appendChild(img); item.appendChild(btn); previewBox.appendChild(item); // 把本轮新增的图片信息存入数组 fileList.push({ file, url, id: Date.now() Math.random() }); } fileInput.addEventListener(change, function () { const files Array.from(this.files); files.forEach(file { if (!isValidImage(file)) return; const url URL.createObjectURL(file); renderPreview(file, url); }); this.value ; // 重置input确保同一文件可再次触发change }); submitBtn.addEventListener(click, function () { if (fileList.length 0) { alert(请先选择图片); return; } const formData new FormData(); fileList.forEach((item, index) { formData.append(images[${index}], item.file, item.file.name); }); // 这里交给你的AJAX逻辑 console.log(待提交图片数, fileList.length); for (const pair of formData.entries()) { console.log(pair[0], pair[1].name); } // fetch(/api/upload, { method: POST, body: formData }) // .then(res res.json()) // .then(data console.log(data)); }); /script /body /html这份代码已经是可运行状态核心思路是维护一个fileList数组作为唯一数据源renderPreview负责渲染并同步记录文件与 URL删除按钮在处理事件时把三个地方一次性清理掉数组、URL.revokeObjectURL、DOM。FormData.append的时候第三个参数我们显式传了item.file.name这样服务端收到的文件名不会变成blob那串乱码。MAX_COUNT、MAX_SIZE、ACCEPT_TYPES这三个常量是留给你的调参入口按自己业务改数值即可。3. 多图上传的交互闭环预览、删除、回显与限制校验3.1 选择、追加、删除与数组同步上一章代码里的change事件监听用的是追加语义每次选择文件都会在原有预览基础上继续添加这对应了「多图片」场景的真实需求——用户往往分多次选择不同图片。但这里有一个人机交互上的细节问题input typefile每次弹出的是系统文件选择器选完一批后如果想再选一批通常会期望这次的新文件跟上次的并存。我们要做的就是把多批文件最终归拢到一个数组里。上面代码里的fileList.push就是在完成这个归拢动作。删除操作需要特别小心的是数组下标的稳定性。如果你用splice(index, 1)后面的元素会自动前移这没问题但如果你用delete fileList[index]或者fileList.length ...这类操作就会留下空洞导致后续遍历时拿到undefined。我的习惯是删除时用findIndex找到目标对象在数组中的精确位置再splice同时用URL.revokeObjectURL把对应的预览内存释放掉。另外要留意的是fileList里存的file对象是File实例它本质上是一个 Blob 引用只要你不显式释放它就会一直驻留在内存里这也是为什么「删图后内存却没降下来」的排查点之一。3.2 数量、格式与尺寸的拦截策略限制数量和格式这件事放在前端做是体验问题放在后端做是安全问题。前端必须做但不能只依赖前端。在这个源码里我设置了三个拦截层次文件类型白名单、单文件大小上限、总数量上限。这三项校验全部在isValidImage里完成等于是在change事件触发的第一时间就拦掉了不合规的文件避免后面渲染和提交阶段再出错。acceptimage/*是浏览器文件选择器层面的快速过滤它只是建议性过滤用户仍然可以切到「所有文件」去选择非图片所以代码里还要再做一次魔数级校验。file.type基于 MIME 类型判断需要注意某些情况下浏览器对.jpg文件返回的type会是空字符串尤其是从手机相册选图时偶尔会发生所以上面代码里file.type为空时我用|| 未知的方式给它一个降级提示而不是直接放行。尺寸拦截有两个含义一个是文件体积file.size另一个是图片分辨率。体积好拦分辨率必须等图片加载后才能知道这个我在第五章单独讲压缩时会展开。// 尺寸校验等待图片加载读取真实宽高 function checkImageSize(file, maxWidth 4000, maxHeight 4000) { return new Promise((resolve) { const url URL.createObjectURL(file); const img new Image(); img.onload function () { const pass img.naturalWidth maxWidth img.naturalHeight maxHeight; URL.revokeObjectURL(url); // 校验完立即释放 resolve(pass); }; img.onerror function () { URL.revokeObjectURL(url); resolve(false); }; img.src url; }); }这段代码是异步的因为Image加载需要时间在拿到naturalWidth和naturalHeight之前不能做判断。new Image()配合src url的方式不会污染文档里的img标签因此临时 URL 用完之后立刻revokeObjectURL避免泄漏。真实项目中我把这个函数和isValidImage串成一条流水线先同步验证类型、大小、数量再异步验证分辨率两条都过了才放进数组。3.3 服务端回显编辑场景下老图与新图的区分很多从零写的多图预览源码只覆盖了「新增」场景一旦接到编辑页比如修改商品图就露馅了。编辑页的特点是图片列表已经存在于服务器前端要先拉取一批老图 URL 展示用户既能删除老图也能追加新图提交时还要告诉服务端哪些老图被删了。这个源码里我给每个条目增加了一个标识字段isExisting来区分老图和新图。老图的预览 URL 直接指向服务器地址删除时不需要也不应该调用URL.revokeObjectURL新图的预览 URL 是blob:协议删除时必须释放。// 编辑页回显老图的逻辑示意 function renderExistingImages(remoteUrls) { // remoteUrls 来自后端接口形如 [/uploads/a.jpg, /uploads/b.png] remoteUrls.forEach((url, index) { const item document.createElement(div); item.className preview-item; const img document.createElement(img); img.src url; const btn document.createElement(button); btn.className remove-btn; btn.textContent ×; btn.addEventListener(click, function () { // 标记删除之后提交时把 deletedIds 传给服务端 deletedIds.push(url); item.remove(); }); item.appendChild(img); item.appendChild(btn); previewBox.appendChild(item); existingFiles.push(url); // 老图统一记录 }); }可以看到老图处理逻辑里没有revokeObjectURL因为它的 src 不是blob:协议是服务器上的正常 URL浏览器自己会管理缓存。提交时前端需要额外生成一个deletedIds数组通过FormData.append(deletedIds, JSON.stringify(deletedIds))传给服务端服务端据此决定删除哪些物理文件同时把新图文件列表落库。这种情况是最容易把两套逻辑写混的错误地对老图也调用revokeObjectURL不会报错但那个 URL 从此就失效了如果你后续还要拿老图做图片对比预览可能一片空白。4. 多图上传避坑兼容性、内存泄漏与样式翻车实录4.1 同一个文件选第二次没有反应现象用户第一次选了一张a.jpg预览成功再次点击上传按钮、还是选同一张a.jpg页面毫无反应change事件根本不会触发。原因input typefile的value字段保存的是用户选择的文件路径浏览器出于安全原因展示为C:\fakepath\a.jpg如果上一次选择后没有清空第二次选同一路径时浏览器认为值没有变化于是不触发change事件。解决在任何一次change事件处理完、拿到this.files之后手动执行this.value ;。这条代码在第二章完整实现里已经写进去了。还有个隐藏好处是清空 value 之后你再从fileList里恢复上一次选择的文件时不会出现 FileList 与 value 不同步的玄学问题。4.2 连续选图后页面越来越卡、甚至白屏现象在多图预览的页面上连续点了十几张几 MB 的大图越往后操作越卡删掉所有预览图后内存也没恢复到初始水平部分旧版 Safari 直接白屏。原因URL.createObjectURL生成的blob:URL 如果没有显式调用URL.revokeObjectURL它占用的内存不会被系统回收哪怕对应的img标签已经被移除了泄漏持续累积直至浏览器崩溃。这是多图预览场景里最常见的内存泄漏入口。解决删除图片时以及提交完成后必须遍历fileList中所有条目逐个执行URL.revokeObjectURL(item.url)。还有一个我自己的习惯在change事件处理里对每一张图生成 objectURL 之前先检查当前fileList.length如果已经接近上限先提示用户清理避免一次性创建过多 URL。// 提交完成后统一释放全部预览 URL function releaseAllObjectUrls() { fileList.forEach(item { URL.revokeObjectURL(item.url); }); fileList.length 0; previewBox.innerHTML ; }注意fileList.length 0是清数组的标准做法比fileList []更安全因为后者会直接更换数组引用如果你在闭包里有别的地方引用了旧的数组就清不干净了。4.3 动态 GIF 在预览时变成静态图现象明明选了 GIF预览出来却只有一个画面不会动。原因img标签本身没有禁止 GIF 动画但你在预览区如果设了object-fit: cover配合固定宽高这只是样式问题不影响动画。真正的常见原因是移动端很多图片压缩模块或上传库会在预览阶段调用canvas.toDataURL(image/jpeg)这一步会强制把动态 GIF 转成 JPEG动画自然就没了。另一个原因是部分旧版本 Android WebView 的img对 GIF 动画支持不完整。解决预览阶段不要对原文件做任何转换直接createObjectURL然后用img加载原始 GIF。在提交前如果需要压缩你也得在压缩逻辑里对 GIF 类型单独放行——不要对它执行 canvas 重绘直接提交原始文件。这个源码里我用的方案是ACCEPT_TYPES允许image/gif压缩阶段单独判断类型GIF 跳过压缩步骤。4.4 竖拍照片在预览时方向横过来了现象手机拍的照片传到电脑上看是正的但在网页预览里却是旋转 90 度或 180 度的。原因现代手机拍摄的照片会在 EXIF 信息里写入Orientation字段支持它的图片查看器会自动旋转。但浏览器中的img和canvas在绝大多数场景下会忽略这个字段于是照片按原始像素方向展示导致方向错乱。解决这个坑在预览阶段几乎无解——你不能通过img去强制应用 EXIF 方向。在压缩阶段可以用canvas配合createImageBitmap的imageOrientation选项来修正// 使用 createImageBitmap 读取并修正 EXIF 方向 async function loadImageWithOrientation(file) { const bitmap await createImageBitmap(file, { imageOrientation: from-image }); const canvas document.createElement(canvas); canvas.width bitmap.width; canvas.height bitmap.height; const ctx canvas.getContext(2d); ctx.drawImage(bitmap, 0, 0); bitmap.close(); // 用完立即释放位图内存 return canvas.toBlob(image/jpeg, 0.85); }imageOrientation: from-image在 Chrome 和新版 Edge 里已经支持Safari 需要单独降级处理。如果实在要覆盖老浏览器那就只能引入exif-js这类第三方库读取Orientation字段再做矩阵旋转成本较高但是唯一兼容方案。4.5 预览图样式挤压变形只显示一个角现象预览生成的图片不是等比缩放而是横向拉宽、纵向压扁或者只裁剪出一个局部区域。原因img标签不设置宽高时会按原始尺寸展示大图会撑爆布局只设了width: 100%而不设高度或object-fit时会导致宽高比失真。如果你用了height: 120px; width: 120px;但没有object-fit: cover图片就会被拉伸到非等比状态。解决统一使用固定宽高容器 object-fit: cover的样式方案。object-fit: cover等价于背景图的background-size: cover它会保持图片原始宽高比同时按容器尺寸裁剪溢出部分。如果你希望整张图完整可见而不裁剪用object-fit: contain代价是左右或上下会留白类似于文档里图片「适配页面」的意思。这两种方案适合不同的 UI 需求我用得最多的还是cover因为大多数后台列表场景展示缩略图就是要铺满格子。.preview-item img { width: 120px; height: 120px; object-fit: cover; border-radius: 4px; background: #f5f5f5; /* 图片加载失败时的底色 */ }5. 多图预览的性能兜底用 canvas 强制输出指定尺寸缩略图多图预览在 UI 上看似告一段落但真正决定这个功能在生产环境是「能用」还是「好用」的是选完图之后对图片数据的再处理。用户从手机相册选出来的图动辄 3MB 到 8MB直接提交给服务端既费带宽又费存储而且img直接渲染原图还会让页面卡顿。我的做法是在提交前用canvas做一次等比压缩生成指定最大边长、指定压缩质量的缩略图再放进FormData。// 图片压缩限制最大边长为 1200px质量 0.85输出 JPEG async function compressImage(file, maxEdge 1200, quality 0.85) { const url URL.createObjectURL(file); const image new Image(); image.src url; await new Promise((resolve, reject) { image.onload resolve; image.onerror reject; }); URL.revokeObjectURL(url); // 原始文件加载完成就释放否则又是一次泄漏 const ratio Math.min(maxEdge / image.naturalWidth, maxEdge / image.naturalHeight, 1); // 当原图小于 maxEdge 时ratio 为 1不放大 const w Math.round(image.naturalWidth * ratio); const h Math.round(image.naturalHeight * ratio); const canvas document.createElement(canvas); canvas.width w; canvas.height h; const ctx canvas.getContext(2d); ctx.drawImage(image, 0, 0, w, h); // 非 GIF 图统一转 JPEGGIF 保留原样提交 if (file.type image/gif file.size 1024 * 1024) { return file; // 大 GIF 不做压缩直接交原图避免动画丢失 } return new Promise(resolve { canvas.toBlob(blob { resolve(blob ? new File([blob], file.name.replace(/\.\w$/, .jpg), { type: image/jpeg }) : file); }, image/jpeg, quality); }); }ratio Math.min(maxEdge / naturalWidth, maxEdge / naturalHeight, 1)这个表达式是整个压缩逻辑的核心取宽高两者中更接近上限的维度来计算缩放比同时Math.min(..., 1)保证如果原图本来就小于 1200px则不做放大。注释里我也写了这一点因为它决定了压缩是否「等比」且是否「不放大」。toBlob比起老式的canvas.toDataURL更省内存它直接产出二进制 Blob不经过 Base64 字符串后续FormData也直接收 Blob。GIF 特判那两行看起来很简单实际是踩过坑之后才加的——第一次上线时系统把 GIF 压成了静态 JPEG产品经理解释了五分钟为什么商品页的动图不会动了。整个流程串起来之后大概是这样的用户选完图 → 前端逐张做类型、大小校验 → 预览展示 → 提交前对每张非 GIF 图片运行compressImage、得到压缩后的 File 对象 → 把新对象放入FormData的files字段 → 发送请求。这套链路跑通之后你会发现服务端收到的图片普遍只有原图的 30% 左右体积列表页的加载速度也明显提升了。从那以后我每次做多图上传都会强制走一遍「校验 → 预览 → 压缩 → 回显」这四步流程哪怕需求方说只用内网不关心体积我也会把压缩逻辑保留着——谁也不知道今天的内网会不会变成明天的公网。希望帮到你。本文还有配套的精品资源点击获取