最常见原因是未传或传错编码参数，如windows记事本保存的gbk文件被默认utf-8解码导致乱码；应优先用readasarraybuffer配合textdecoder按gbk/utf-8等依次尝试解码，并校验结果。
readAsText 为什么读出来全是乱码
最常见原因是没传编码参数，或传了错误的编码。Windows 上用记事本保存的 .txt 默认是 GBK/GB2312，而 readAsText() 默认按 UTF-8 解码，结果就是 这类方块字符。
解决办法不是“猜编码”，而是分两步走：
- 先用
readAsArrayBuffer()读原始字节，再用new TextDecoder('gbk').decode(buffer)尝试解码 - 如果不确定编码，可依次试
'utf-8'、'gbk'、'big5'，捕获TextDecoder抛出的异常 - 注意：Chrome 120+ 对非 UTF-8 编码支持仍不稳定，GBK 文件若解码失败，
TextDecoder可能静默返回空字符串，需加if (!text.trim())校验
readAsText 的第二个参数到底要不要写
要写，而且必须写对。不写 ≠ 自动识别编码 —— 它只是硬性使用 UTF-8，和文件实际编码无关。
典型场景对比：
- 用户上传一个 Excel 导出的 CSV（Windows 系统），用
readAsText(file)→ 中文全乱码；改用readAsText(file, 'gbk')→ 正常 - 用户从 macOS 保存的 Markdown，用
readAsText(file, 'utf-8')→ 安全；但若省略第二个参数，也大概率正常（因默认就是 UTF-8） -
readAsText(file, 'ascii')会把所有非 ASCII 字符替换成，不是报错，这点容易被忽略
onload 不触发？检查这三件事
onload 静默不执行，90% 是因为没在正确的时机调用读取方法，或没做基础校验。
- 别在页面加载时就调
reader.readAsText()—— 此时input.files[0]是undefined，不会报错，但也不会触发任何事件 - 必须在
input[type="file"]的change事件里新建FileReader实例并调用读取方法；复用同一个实例会导致状态混乱，onload永远不触发 - 必须提前设好
reader.onerror = () => console.error(reader.error)，否则编码错误、文件为空等都会静默失败
大文本文件读取卡死或内存爆掉怎么办
FileReader 没有流式读取能力，readAsText() 会把整个文件加载进内存。10MB 以上就可能卡 UI，100MB 基本等于浏览器无响应。
真实可用的缓解手段只有两个：
- 用
file.slice(start, end)手动切片，每次读 2–4MB，拼接处理。注意：切片不能跨行（CSV/JSON 场景），需在onload后检查末尾是否为完整换行符，否则下一片可能截断一行 - 改用
ReadableStream+TextDecoderStream（Chrome 109+、Firefox 117+ 支持），它才是真正边读边解码，内存占用恒定，但需自行处理中断与错误恢复
别信“用 setTimeout 分片”的伪方案 —— FileReader 本身不支持暂停，切片后仍是同步加载整块，只是把卡顿拆成几次而已。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
