核心思路是先用字节流检测编码再初始化带缓冲的字符流：优先查bom，无bom则用chardet分析前4kb；确认编码后显式指定charset创建bufferedreader，并按编码特性设置合理缓冲区大小，全程坚持用readline()保证性能。
核心思路是把编码检测和缓冲流读取解耦，先用字节方式精准判别编码，再用该编码初始化带缓冲的字符流——这样既避免了乱码，又保留了 readLine() 的高效性。
先用字节流检测编码，不依赖字符流
BufferedReader 本身不能检测编码，强行用它读会因编码错误直接抛异常或输出乱码。正确做法是：用 二进制模式打开文件（如 Python 的 open(..., 'rb') 或 Java 的 Files.readAllBytes()），只读前几 KB 字节交给 chardet 或 BOM 检测逻辑判断。
- 优先检查 BOM：UTF-8（
EF BB BF）、UTF-16 LE（FF FE）等有唯一字节特征，一查即准 - 无 BOM 时，用 chardet 分析前 4KB 字节，取 confidence ≥ 0.7 的结果，不采信低置信度猜测
- 大文件别全读：chardet 对 1–4KB 样本已足够准确，读太多反而拖慢启动速度
按检测结果构造带编码的 BufferedReader
拿到确定编码（如 UTF-8 或 GBK）后，再创建真正用于读取的 BufferedReader，并显式传入 Charset。这一步杜绝了平台默认编码干扰。
- ✅ 推荐写法（Java）：
Files.newBufferedReader(path, StandardCharsets.UTF_8) - ✅ Python 类似：
open(file, 'r', encoding=detected_encoding)，且建议加errors='replace'防止个别坏字节中断 - ❌ 禁止用
FileReader或未指定 encoding 的open()：它们隐式依赖系统 locale，中文 Windows 下默认 GBK，Linux 下常为 UTF-8，极易不一致
缓冲区大小适配检测出的编码特性
不同编码下“一行”的字节数差异很大：UTF-8 中文每字 3 字节，GBK 每字 2 字节，而含 base64 或 JSON 的长行可能单行超 10KB。缓冲区太小会频繁 fill()，太大则浪费内存。
- 若检测到 UTF-8 且文件含长文本（如日志含堆栈、CSV 含 HTML 片段）：设缓冲区为 65536（64KB）
- 若检测为 GBK/GB18030 且为传统日志（每行 ≤ 200 字符）：保持默认 8192 即可
- 实时处理流式数据（如管道输入）：缓冲区调小到 4096，降低首行延迟
读取阶段坚持用 readLine()，不降级为逐字节解析
编码检测只是前置动作；一旦 BufferedReader 正确初始化，后续必须用 readLine() 发挥其内部 char[] 批量扫描优势。任何手动 read() 或 read(char[]) 都会让缓冲失效，性能跌回原始流水平。
- 过滤空行写成：
String line = reader.readLine(); if (line != null && !line.trim().isEmpty()) { ... } - 需要跳过 BOM 行？在第一次 readLine() 后检查内容是否以
\uFEFF开头，而不是在字节层做截断 - 禁止循环中调
reader.read()：CPU 占用飙升，吞吐可能不足 readLine() 的十分之一
