readasdataurl处理大图（>5mb）会卡顿或失败，因其将整个文件转为base64字符串，内存占用陡增约33%，易触发gc导致onload不触发；应优先校验file.size，超3mb改用readasarraybuffer+canvas压缩。
FileReader 能实现多图上传前的本地预览，但不能跳过服务器上传——它只读取文件内容，不发送数据。
为什么 FileReader 的 readAsDataURL 会卡顿或失败
大图（比如 >5MB）用 readAsDataURL 会把整个文件转成 base64 字符串，内存占用陡增，Chrome 可能直接卡死或触发 GC 清理导致 onload 不触发。
- 优先检查
file.size，超过 3MB 就改用readAsArrayBuffer+ Canvas 压缩后再预览 -
FileReader实例不能复用：每次读取新文件必须新建一个 - 多个文件并发读取时，别共用同一个
reader.onload回调——闭包或绑定this容易让event.target.result指向错的文件
input[type="file"] 的 multiple 和 accept 怎么配合才可靠
accept="image/*" 只是提示作用，iOS Safari 会忽略它，用户仍可选 PDF；multiple 在部分安卓 WebView 中可能只返回第一个文件。
- 必须在
change事件里遍历e.target.files，不能只取[0] - 每个
File对象都要单独校验：file.type.startsWith('image/')+file.name.match(/\.(jpg|jpeg|png|webp)$/i) - Android UC 浏览器可能把 HEIC 格式报成
type=""，得靠后缀兜底
预览 DOM 怎么避免重复渲染和内存泄漏
每选一次多图，如果直接 innerHTML = '' 再拼接 <img>，旧的 img 元素引用还在，FileReader 的 onload 可能往已移除的 DOM 写 src，造成静默失败。
- 给每个预览
<img>加唯一data-file-id，读取完成时比对再赋值 - 用
URL.createObjectURL(file)替代readAsDataURL可大幅降低内存压力，但记得在移除预览时调用URL.revokeObjectURL() - 监听
input的click之前先清空value，否则重复点击不会触发第二次change
真正难的不是读取图片，而是处理那些没报错却没显示的“幽灵预览”——它们往往卡在 FileReader 状态未完成、DOM 已销毁、或跨域 blob URL 被浏览器拦截的缝隙里。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
