FileReader 的 onload 不触发最常见原因是未在 input[type="file"] 的 change 事件中调用 readAsText()，或未校验 file 是否为有效 File 对象；复用 FileReader 实例、未设置 onerror 也会导致失败。
FileReader 读取文件时为什么 onload 不触发？
最常见原因是没在 input[type="file"] 的 change 事件里调用 readAsText() 或其他读取方法，而是误写在页面加载时——此时 files 还是空数组。
另一个高频坑：直接对 event.target.files[0] 调用 readAsText()，但没检查是否为 File 对象（比如用户取消选择后 files[0] 是 undefined）。
实操建议：
- 始终用
if (file && file instanceof File)做存在性和类型校验 -
FileReader实例必须在每次读取前新建，不能复用（否则状态混乱） - 监听
onload之前，先设好onerror，否则报错静默失败 - 示例片段：
const input = document.querySelector('input[type="file"]');<br>input.addEventListener('change', e => {<br> const file = e.target.files[0];<br> if (!file) return;<br> const reader = new FileReader();<br> reader.onload = () => console.log(reader.result);<br> reader.onerror = () => console.error(reader.error);<br> reader.readAsText(file, 'UTF-8');<br>});
readAsDataURL 和 readAsArrayBuffer 该选哪个？
取决于后续用途：readAsDataURL 输出 base64 字符串，适合直接赋给 <img src> 或上传前预览；readAsArrayBuffer 输出二进制缓冲区，适合解析 Excel、音频元数据、加密或转成 Uint8Array 处理。
立即学习“前端免费学习笔记（深入）”；
性能上，readAsDataURL 会多一次编码开销（约膨胀 33%），大文件（>10MB）容易卡顿甚至 OOM；readAsArrayBuffer 更轻量，但需要额外用 TextDecoder 或 JSON.parse()（如果内容是 JSON）才能拿到文本。
注意点：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
readAsDataURL不支持指定编码，输出的 data URL 默认含charset=us-ascii，但实际内容仍是 UTF-8 编码的 base64，显示中文没问题 -
readAsArrayBuffer后若要转字符串，推荐用new TextDecoder('UTF-8').decode(buffer)，别用String.fromCharCode(...new Uint8Array(buffer))——后者会乱码 - 图片类文件优先用
readAsDataURL；PDF、CSV、JSON 等结构化文本建议用readAsText（更简洁）
读取大文件时卡死或内存爆掉怎么办？
FileReader 本身不支持分块读取，整文件加载到内存是硬伤。100MB 的文件调 readAsText 很可能让浏览器无响应。
真实可行的解法只有两个方向：
- 用
File.slice()手动切片 + 链式读取（适合校验、提取头部信息等场景）function readInChunks(file, chunkSize = 1024*1024) {<br> let offset = 0;<br> function loadNext() {<br> if (offset >= file.size) return;<br> const blob = file.slice(offset, offset + chunkSize);<br> const reader = new FileReader();<br> reader.onload = e => {<br> // 处理 e.target.result（ArrayBuffer 或 string）<br> offset += chunkSize;<br> loadNext();<br> };<br> reader.readAsArrayBuffer(blob);<br> }<br> loadNext();<br>} - 改用
Stream+Response.body.getReader()（需配合URL.createObjectURL(file)构造本地 URL），但兼容性差（Safari 不支持File直接构造Response） - 更务实的选择：前端只做小文件（
为什么 FileReader.result 在 onload 外是 null？
因为 FileReader 是异步 API，result 只在读取完成（即 onload 触发后）才被赋值。在 onload 外访问它，必然得到 null 或旧值。
典型错误写法：
reader.readAsText(file);<br>console.log(reader.result); // 总是 null
正确做法只有一种：所有依赖读取结果的逻辑，必须放在 onload 回调里，或封装成 Promise：
- Promise 封装示例：
function readFileAsText(file) {<br> return new Promise((resolve, reject) => {<br> const reader = new FileReader();<br> reader.onload = () => resolve(reader.result);<br> reader.onerror = () => reject(reader.error);<br> reader.readAsText(file);<br> });<br>}<br>// 使用：<br>readFileAsText(file).then(text => console.log(text)); - 不要试图用
while(reader.readyState !== 2)轮询——阻塞主线程，且readyState不是实时可读的 - 也别用
setTimeout等待——时机不可控，且违背异步设计本意
FileReader 的核心限制在于「单次加载、不可中断、无进度回调」，这些不是 bug，是规范使然。真要可控读取、断点续传、实时进度，得绕开它，用 Blob.arrayBuffer()（现代浏览器）、Streams API 或服务端协作。
