支持 FileReader API 的判断方式是 typeof FileReader !== 'undefined'；读取文本用 readAsText()，二进制操作用 readAsArrayBuffer()，预览图片用 readAsDataURL()；onload 中推荐通过 e.target.result 获取结果；大文件应分块读取避免内存问题。

怎么判断浏览器是否支持 FileReader API

不支持 FileReader 的老浏览器（如 IE9 及以下）会直接报 ReferenceError: FileReader is not defined。最稳妥的判断方式是检查全局对象是否存在该构造函数：

if (typeof FileReader !== 'undefined') {
  // 可以安全使用 FileReader
} else {
  // 降级方案：用 input[type=file] 的 form 提交 + 后端解析
}

注意不要只检测 window.FileReader —— 某些严格模式环境可能未挂载到 window，而 typeof 是最安全的运行时检测手段。

readAsText() 和 readAsArrayBuffer() 该怎么选

取决于你后续要处理的数据类型：

• 读取纯文本（JSON、CSV、日志、配置文件）→ 用 readAsText()，自动按指定编码（默认 UTF-8）解码为字符串
• 需要二进制操作（图片校验、音频解析、加密、WebAssembly 加载）→ 用 readAsArrayBuffer()，返回原始字节块，避免文本编码干扰
• 读取 Base64（比如上传前预览图片）→ 用 readAsDataURL()，但注意它会在结果前拼接 data:[mime];base64, 头部，解析时需先截断

常见错误：对非文本文件（如 .zip、.pdf）调用 readAsText()，会导致乱码或解析失败；反之，对大文本文件用 readAsArrayBuffer() 再转字符串，多一层 TextDecoder 开销，没必要。

为什么 onload 里拿不到 this.result？

这是典型的 this 绑定丢失问题。在事件回调中，this 默认指向 FileReader 实例，但如果你用了箭头函数或显式绑定了其他上下文，就容易出错：

const reader = new FileReader();
reader.onload = function() {
  console.log(this.result); // ✅ 正确：this 指向 reader
};
// ❌ 错误写法：
reader.onload = () => {
  console.log(this.result); // this 指向外层作用域，不是 reader
};

更稳妥的方式是直接用事件参数或显式引用：

reader.onload = function(e) {
  const result = e.target.result; // 推荐：不依赖 this
};

另外注意：result 只在 load 事件触发后才可用，loadstart 或 progress 里访问是 undefined。

大文件读取卡顿甚至崩溃怎么办

FileReader 是同步加载整个文件到内存的，100MB 的文件就会生成同等大小的字符串或 ArrayBuffer，极易触发内存警告或页面无响应。

• 前端限制单次读取大小：用 file.slice() 分块读取，配合 readAsArrayBuffer()
• 避免 readAsText() 处理超大文件，UTF-8 解码本身有性能开销
• 监听 onprogress 时注意：它只对 readAsArrayBuffer() 和 readAsDataURL() 有效，readAsText() 不触发进度事件
• 必要时改用 Stream + Response.body.getReader()（需 File 转 Blob.stream()，但兼容性略差）

真正难处理的不是“能不能读”，而是“要不要一次性全读”——多数场景下，流式解析或服务端分片才是更健壮的选择。