FileReader本身不支持动态识别编码，必须通过readAsText(file, encoding)显式指定真实编码（如GBK或UTF-8），或改用readAsArrayBuffer配合TextDecoder手动解码，避免乱码。
FileReader本身不支持动态识别编码，所谓“变量乱码识别”不是靠猜或自动判断，而是通过明确的解码策略+字节层控制来规避乱码。核心思路是：别依赖FileReader默认行为，改用底层字节读取 + TextDecoder手动解码。
明确指定编码比“自动识别”更可靠
FileReader.readAsText(file, encoding) 的第二个参数必须写，且必须与文件真实编码一致。常见对应关系：
- Windows 记事本保存的 .txt → 大概率是 GBK（不是 GB2312，也不是 UTF-8）
- VS Code / macOS / Linux 下保存的文本 → 大概率是 UTF-8
- Excel 导出的 CSV（尤其含中文列）→ Windows 环境下多为 GBK，macOS 下可能是 UTF-16 或带 BOM 的 UTF-8
- 带 UTF-8 BOM（
\uFEFF）的文件 → 仍属 UTF-8，但部分浏览器在未指定编码时可能误判，显式传'utf-8'可避免
不确定编码时，用 ArrayBuffer + TextDecoder 尝试解码
readAsText 无法处理编码未知或混合编码场景，应切换为 readAsArrayBuffer：
- 先调
reader.readAsArrayBuffer(file) - 在 onload 中用
new TextDecoder('gbk').decode(buffer)尝试 - 若结果为空或含大量 ，再试
'utf-8'、'big5'等 - 每次解码后加
if (!text.trim())校验，防止 Chrome 对 GBK 解码失败时静默返回空串
Java 端 FileReader 乱码的等效解法
Java 中的 FileReader 同样默认绑定系统编码（Windows 是 GBK），不能直接用于跨平台中文读取：
- 弃用
new FileReader(path)，改用Files.newBufferedReader(Paths.get(path), StandardCharsets.UTF_8) - 若需兼容 GBK 文件，用
new InputStreamReader(new FileInputStream(file), "GBK") - 不要用
"utf8"或"UTF8"—— 正确写法是"UTF-8"，否则抛UnsupportedEncodingException - 读取前可用
file -i filename（Linux/macOS）或 VS Code 右下角编码提示确认真实编码
大文件或流式读取避免内存崩溃
readAsText 会一次性加载整个文件进内存，10MB 以上就易卡顿。真实项目中建议：
- 小文件（≤2MB）：直接用
readAsText(file, 'utf-8')或 ArrayBuffer + TextDecoder - 中大文件（2–50MB）：用
file.slice(start, end)分片，每次读 2MB，注意检查末尾是否为完整换行符，避免截断一行 - 超大文件（≥50MB）：改用
ReadableStream+TextDecoderStream（Chrome 109+/Firefox 117+ 支持），真正边读边解码，内存恒定
