FileReader读取中文乱码需显式指定编码,如readAsText(file, 'GBK');若编码未知,先用readAsArrayBuffer()配合TextDecoder尝试解码。
不能直接读取本地文件路径,必须由用户主动触发选择(如 <input type="file"> 或拖放),这是浏览器安全策略强制要求的底线。
常见错误现象:用 readAsText() 读取中文文本显示为 或其他乱码字符。
readAsText(file, encoding) 第二个参数可显式指定编码,例如 readAsText(file, 'GBK')
readAsArrayBuffer() 读取原始字节,再用 TextDecoder 尝试多种解码(如 new TextDecoder('gbk'))两者都能实现预览,但内存占用和生命周期完全不同。
readAsDataURL() 生成 base64 字符串,体积比原图大 ~33%,且会常驻内存直到 DOM 节点被 GC —— 大图反复预览容易 OOMURL.createObjectURL(file) 创建的是轻量级 Blob URL,不复制数据,只建立引用;但必须手动调用 URL.revokeObjectURL() 释放,否则内存永不回收createObjectURL 并在 img.onload 后立即 revoke不是 FileReader 本身限制,而是浏览器对单次内存分配和事件循环阻塞的容忍度问题。
立即学习“前端免费学习笔记(深入)”;
onprogress 事件能拿到 e.loaded 和 e.total,但仅对 readAsArrayBuffer 有效,readAsText 和 readAsDataURL 不触发Blob.slice() 分块读取,例如每次读 4MB,拼接处理slice() 的起始偏移必须对齐文件格式边界(如 PNG 的 IHDR 块不能被切开),否则解析失败Streams API + ReadableStream,但兼容性需查 Can I UseFileReader 是异步的,但它的回调(onload)仍跑在主线程;如果后续解析逻辑很重(比如解析 50MB JSON),UI 依然会卡住 —— 这点容易被忽略。