readAsDataURL 会将整个文件读入内存并转为带 MIME 头的 Base64 Data URL，适合小图预览但不适用于大文件；其返回值需截取逗号后部分才能作为纯 Base64 使用，否则后端解码失败；相比 readAsArrayBuffer，它内存占用高、体积膨胀约33%，且存在兼容性与异常处理风险。
readAsDataURL 会把整个文件读进内存、转成带 MIME 头的 Base64 字符串，适合小图预览，但别拿来处理大文件——20MB 以上就容易卡死或崩溃。
为什么 readAsDataURL 返回的字符串不能直接当纯 Base64 用
它返回的是完整的 Data URL，格式是 data:image/png;base64,iVBORw0KGgo...，开头有 data:xxx;base64, 这一段。如果你需要提取原始 Base64 内容（比如发给后端做 base64 解码），必须手动截掉逗号之前的部分。
常见错误现象：后端解码失败、报“非法字符”或“不是有效的 base64 字符串”。
- 正确提取方式：
const base64Str = result.split(',')[1] - 更稳妥的写法（防意外无逗号）：
const base64Str = result.includes(',') ? result.split(',')[1] : result - MIME 类型可从
file.type拿，比从 Data URL 解析更可靠
readAsDataURL 和 readAsArrayBuffer 在大文件上的表现差异
前者对内存不友好：浏览器要一次性把整个文件转成字符串，Base64 还会让体积膨胀约 33%。一个 50MB 的 PNG 实际占用内存可能超 150MB。
后者返回 ArrayBuffer，是二进制原生表示，不膨胀、不转码，更适合分块读取或后续加密/压缩等操作。
立即学习“前端免费学习笔记（深入）”；
- 小文件（readAsDataURL 最快，一行赋值
img.src = result就能预览 - 中等文件（5–20MB）：仍可用
readAsDataURL，但建议加 loading 状态和超时控制 - 大文件（>20MB）：必须换
readAsArrayBuffer+ 分片逻辑，否则用户点一下就白屏
实际使用时容易漏掉的兼容性与异常处理
不是所有浏览器都默认支持 FileReader，尤其老版 IE（IE9 及以下完全不支持），而且某些 WebView（如早期 Android 4.x）也有 bug。
- 检查支持性：
if (!window.FileReader)必须有，不能只靠 try/catch -
onerror事件必须监听，常见错误码：FileReader.error.code === 5（编码错误）、=== 1（读取被中止） - 用户取消选择、选了空文件、文件被其他进程占用，都会触发
onload不执行、onerror也不触发的情况——所以建议加onabort和兜底超时逻辑 - 移动端 Safari 对大文件读取有时会静默失败，需配合
file.size做前置拦截
readAsDataURL 的核心价值在于“开箱即用”，但它掩盖了内存和格式细节。真正上线前，一定要测你业务里最大的那个文件在低端机上是否真能读完——很多问题不是代码写错，而是假设错了文件大小边界。 
