简介：一款基于HTML5 File API与拖放API实现的多图片上传预览源码，面向Web前端开发者和需要快速集成上传功能的项目，适用于图片选择、本地预览、多文件批量处理等场景。压缩包共18个文件、约145KB，由html示例页、css样式表、js核心脚本与png图标示例图构成；其中index.html定义了多选文件输入和预览容器，demo.js与zyUpload.js配合实现change事件监听、FileReader读取、Base64数据URL转码与闭包保存文件对象，jquery-1.7.2.js负责简化DOM操作，css与png图片则完善页面样式和交互反馈。资源无需服务器端交互即可在浏览器中完成图片读取与预览，从多选文件输入控件到拖拽上传均提供可运行示例，压缩包内还附带脚本之家与服务器软件快捷方式，便于查阅延伸资料。目前已有1470人学习下载；代码已测试并保留清晰文件结构，适合作为课堂练习、项目起步模板或功能扩展基础。
1. 多图片上传预览：一个看似简单却容易翻车的html5功能
做后台管理系统或者移动端H5时，你大概率遇到过这种需求：用户要一次性选好几张图片，选完立刻看到缩略图，不满意能删掉重选，最后跟着表单一起提交。这个功能用html5做，核心代码可能就二三十行，但真正上线后你会发现一堆边角问题——图片太大把内存撑爆、选了图片不显示、删掉一张结果全部重排、手机端拍照方向不对。这份已测试的html5多图片上传预览源码，把核心逻辑和边界处理都打包好了，适合正在做表单类页面、后台管理系统、或者需要快速实现图片选择预览功能的前端开发者。与其自己从零写一遍然后踩坑，不如直接拿这套源码做底子改造，它解决的是「图片选择→预览→删除→提交」这一整条链路的稳定问题。
2. 原理先立住：FileReader 与 URL.createObjectURL 的选型差异
2.1 为什么不用 input 的 accept 属性直接搞定
很多人第一反应是写一个<input type="file" accept="image/*" multiple>就完事了。accept 确实能在文件选择弹窗里过滤掉非图片文件，但它只是「建议性过滤」，在部分系统或浏览器里，用户依然能切换到「所有文件」然后选一个 PDF 上来。所以前端必须做二次校验，不能把 accept 当安全边界。
另一个容易忽略的点是：accept 里写image/*只能处理「选择」这一步，图片选完之后的预览、尺寸校验、压缩、删除索引维护，它一概不管。也就是说，html5 只给了你拿文件对象的入口，后续链路全部要自己写。这套源码的核心价值就在后半段——它把文件对象转换成可预览的图片、维护一个待上传列表、并且和表单提交做了对接。
2.2 FileReader 的 readAsDataURL 适合小图，不适合大图
预览图片最经典的方式是用FileReader.readAsDataURL(file)，把图片读成 base64 字符串塞进<img src>里。好处是直观、代码短，而且 base64 可以直接塞进表单字段。但问题也很明显：
- base64 比原图大约膨胀 33%，三张 5MB 的照片，前端内存里就要多扛 20MB 左右的字符串。
FileReader是异步的，如果用户一次性选了 9 张图，会同时发起多个读取任务，低端手机上容易出现卡顿甚至浏览器标签页崩溃。- 如果后续走 AJAX 提交，base64 放进 JSON 里会让请求体变大，后端解析也慢。
2.3 URL.createObjectURL 的优势与释放时机
这套源码用的是URL.createObjectURL(file)生成一个临时对象 URL（类似blob:http://...）来给 img 的 src 用。它不拷贝文件数据，只是给浏览器内部的文件对象做了一个引用，开销比 base64 小得多，即使选 9 张十几 MB 的图也没压力。
但它的坑在释放。URL.createObjectURL创建的 URL 会一直占用内存，直到页面关闭或者手动URL.revokeObjectURL()释放。所以源码里在删除图片、替换图片、表单提交成功这三个时机都调用了 revoke。这一点很多人会漏掉，项目跑一两天看不出问题，等到用户连续操作几十次，能明显感到页面变卡，内存占用一路飙升，就是对象 URL 没有被回收。
| 方案 | 内存占用 | 异步复杂度 | 提交方式 | 适用场景 |
|---|---|---|---|---|
| FileReader base64 | 高（膨胀33%） | 每个文件独立异步 | 可走 JSON/form-data | 小图（<500KB） |
| URL.createObjectURL | 低（引用计数） | 同步返回 URL | 只能走 FormData | 大图、批量选择 |
结论很简单：本地预览用createObjectURL，确实需要把图片内容传给后端时（比如压缩后上传），再用FileReader针对性读取。这套仓库两个方案都封装了，默认走 createObjectURL。
3. 核心代码拆解：从选择文件到预览渲染的完整链路
3.1 HTML 结构：容器、隐藏 input 与触发按钮
源码的页面结构很常规，但有几处设计是值得直接抄作业的。先看最简版：
<div id="upload-panel"> <div id="preview-list" class="preview-list"></div> <button type="button" id="select-btn">选择图片</button> <input type="file" id="file-input" accept="image/*" multiple style="display:none" /> </div> <script src="upload.js"></script>逻辑说明：按钮和 input 分离是常见的「触发式」设计——input 隐藏起来，点击按钮时用 JS 触发fileInput.click()，这样样式可以完全由开发者控制，不用被浏览器原生的文件选择框样式绑架。accept="image/*" 用来做第一层过滤，但不作为唯一校验依据。
参数说明：multiple属性决定了能不能一次选多张。如果只允许单选，去掉这个属性，但源码里的预览列表逻辑仍然兼容——每次选择会覆盖上一张。项目要求最多 9 张时，这个按钮在达到上限后要置灰。
3.2 JavaScript 核心：文件收集、类型校验与预览渲染
const fileInput = document.getElementById('file-input'); const previewList = document.getElementById('preview-list'); const MAX_COUNT = 9; const MAX_SIZE = 5 * 1024 * 1024; // 单张 5MB let fileList = []; // 待上传文件数组 function handleFileSelect(event) { const files = Array.from(event.target.files); if (fileList.length + files.length > MAX_COUNT) { alert(`最多同时上传 ${MAX_COUNT} 张图片`); event.target.value = ''; return; } for (const file of files) { // 类型二次校验 if (!file.type.startsWith('image/')) { console.warn(`[跳过] 非图片文件: ${file.name}`); continue; } // 大小校验 if (file.size > MAX_SIZE) { console.warn(`[跳过] 超过 5MB: ${file.name}`); continue; } fileList.push({ file, url: URL.createObjectURL(file) }); } renderPreview(); event.target.value = ''; // 清空 input，保证同文件可重复选择 } function renderPreview() { previewList.innerHTML = fileList.map((item, index) => ` <div class="preview-item">previewList.addEventListener('click', (event) => { const removeBtn = event.target.closest('.remove-btn'); if (!removeBtn) return; const index = parseInt(removeBtn.dataset.index, 10); const removed = fileList.splice(index, 1)[0]; if (removed && removed.url) { URL.revokeObjectURL(removed.url); // 释放内存 } renderPreview(); });逻辑说明：这里用了事件委托——监听预览容器而不是每个删除按钮单独绑定，这样即使后来动态添加节点也不用重新绑定事件。dataset.index是字符串，必须用parseInt转成数字，否则splice的时候会出诡异问题。
参数说明：closest('.remove-btn')的作用是从点击目标逐级向上找匹配的删除按钮，防止点到图片或边距空白处误触发。如果删除后不调用URL.revokeObjectURL，预览图所在的 blob 地址会一直留在内存里，这是源码已处理好、但你二次开发时很容易弄丢的一步。
4. 表单提交与后端对接：FormData 与两个易错点
4.1 为什么不能 base64 一把梭提交
本地预览跑通了，接下来就是提交。函数库之外，提交方案是一个玄学问题——不少开发者习惯把 base64 直接放进 JSON 提交，理由是后端接口好写。但这个方案在这个多图场景下有两个问题：请求体过大（每个文件膨胀 33%）、后端需要额外处理 base64 解码，很多业务后端并不想为这个买单。更通用的是FormData+XMLHttpRequest或fetch，文件以二进制原样传输，后端拿$_FILES或者对应的 multipart 解析就能直接落盘。
4.2 FormData 组装与提交代码
function submitImages() { if (fileList.length === 0) { alert('请先选择图片'); return; } const formData = new FormData(); fileList.forEach((item, index) => { // 字段名带索引，方便后端按顺序接 formData.append(`image_${index}`, item.file, item.file.name); }); // 附带业务参数 formData.append('description', document.getElementById('desc').value); formData.append('upload_time', Date.now()); fetch('/api/upload', { method: 'POST', body: formData, }) .then((res) => res.json()) .then((data) => { if (data.code === 0) { // 上传成功才释放预览 URL fileList.forEach((item) => URL.revokeObjectURL(item.url)); fileList = []; renderPreview(); } }) .catch((err) => { console.error('上传请求失败:', err); }); }逻辑说明：formData.append的第三个参数是文件名，后端一般能从这里拿到原始文件名，用于落盘和扩展名判断。字段名image_${index}是我常用的做法——后端拿到image_0、image_1就能按顺序还原，如果用同一个字段名images多次 append，后端取到的是一个数组，顺序在部分框架里会出现颠倒。
参数说明：fetch的body直接传 formData 实例，浏览器自动设置multipart/form-data的 Content-Type。这个提交封装没有做超时处理和重试，生产环境建议加一个AbortController实现超时中断，这是源码有意留白的一个扩展点。还有一个小坑：Date.now()作为时间戳字段没问题，但很多后端会默认忽略未知字段，所以业务字段一定要和后端确认命名。
4.3 提交后释放内存：必须等接口返回成功
我见过不少项目，图片选完预览了，结果提交到一半接口报错，前端已经提前把 fileList 清空了，用户看着页面一脸懵。所以源码里特意把URL.revokeObjectURL和fileList清空放在.then回调里，接口成功才释放资源和清空列表。
如果接口返回失败或网络异常，fileList 保持原样，用户可以直接重试提交，不用重新选图。这个细节在本地测试时永远看不出来，但生产环境网络抖动一次你就知道它值多少钱了。
5. 避坑与常见问题排查：已测试源码仍然会踩的四个坑
5.1 选完图片不显示预览：检查文件类型和 URL 是否被释放
现象：点击选择图片后，input 里能看到文件名，但预览区空着，控制台也没有报错。
原因：最常见的是文件类型校验把图片拦下了，某些截图工具生成的图片file.type是image/png，正常的；但部分手机从相册导出时格式是image/heic或者image/webp，startsWith('image/')能通过，如果是application/octet-stream就会被拦。另一个原因是代码里在其他位置（比如上传成功的回调）提前调用了revokeObjectURL，而预览区域还在引用这个 URL。
解决：先在handleFileSelect里加一行console.log(file.type, file.size, file.name)打印原始信息，确认文件是否进入了 fileList。如果进了但图片不显示，打开 Network 面板看 img 标签的 src 值，如果是blob:null/...，说明文件源出了问题；如果是blob:http://...且图片区域显示空白图标，多半是revokeObjectURL被调早了。
5.2 同一个文件选择第二次没反应：input value 未清空
现象：第一次选图片正常，删除后再点按钮，选了同一张图，什么动静都没有。
原因：这是非常经典的 html5 文件输入框问题。input 的 value 保存的是用户上次选择的文件路径。当文件路径没有变化时，change 事件不会被触发。也就是说，同一个文件选第二次，浏览器认为你「没有选择新文件」。
解决：源码里在handleFileSelect的最后面有一行event.target.value = ''，这个清空动作必须在整个事件处理流程里保持到最后执行。如果你在二次开发时提前 return 了，注意别跳过了这行。另外，选了不符合校验条件的文件也会走一个 return，这时候同样要清空 value，否则下一次选择会继续不触发。
5.3 上传大图时机子卡顿：把压缩放进预览前
现象：用户用手机拍了 12MB 的照片，选完图片页面直接卡了几秒，部分低端机甚至闪退。
原因：URL.createObjectURL本身不拷贝数据，但浏览器渲染 img 时要对原图做解码，12MB 的 jpg 解码后的位图数据可能达到几十 MB。预览列表渲染一张就要解码一次，9 张大图同时解码，内存压力直接拉满。
解决：在预览前做一次 canvas 压缩，把超过设定尺寸的图片等比缩放后再显示。源码的压缩函数用的是常规的canvas.toBlob方案，压缩阈值默认是 1280px 宽。缩略图不需要原图尺寸，这个压缩只影响预览，不影响最终提交的原始文件。这是性能和体验的平衡点，建议任何面向真实用户的项目都加上。
5.4 多图上传顺序错乱：图片文件名的中文编码问题
现象：用户选了 6 张图，上传到后端后文件名全部变成乱码，或者顺序和选择顺序不一致。
原因：formData.append的第三个参数文件名如果包含中文，后端如果按 UTF-8 解码没问题，但有些老项目后端用的是 GBK，解码必然乱码。顺序错乱则通常是后端对 multipart 解析时的字段顺序处理方式不同，前端如果不用索引做字段名，很容易丢顺序。
解决：前端先统一做一次文件名编码处理，把中文名替换为image_${Date.now()}_${index}.jpg，扩展名用file.type推导。后端落盘时用自己的规则重新生成文件名，完全依赖前端文件名反而是最脆弱的做法。另外能扛住顺序的方案就是image_${index}字段名，这一点在 4.2 节已经写过。
6. 进阶优化：缩略图懒渲染与移动端拍照旋转校正
预览列表用innerHTML整体重绘，图片多的时候会有明显闪烁。我习惯的改进是：初始化时只渲染卡片容器，图片的src用一个“加载后才赋值”的思路处理——用 IntersectionObserver 监听滚动区域，只有进入可视区的图片才绑定src。
const observer = new IntersectionObserver((entries) => { entries.forEach((entry) => { if (entry.isIntersecting) { const img = entry.target; img.src = img.dataset.src; // 真正加载 observer.unobserve(img); } }); }, { rootMargin: '200px' }); // 渲染时先设置 style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" />
