readLine只读换行符前内容因其设计目标是按行切分，内部扫描至\n、\r\n或\r即返回字符串且不包含这些换行符。
readLine 为什么只能读到换行符前的内容
readLine 的设计目标就是按行切分，它内部会扫描输入流直到遇到 \n、\r\n 或 \r（取决于平台和底层实现），然后返回这一行的字符串，但不包含这些换行符本身。这意味着如果你的数据里混用了 \r 和 \n（比如 Windows 生成的文件在 Linux 下处理），某些行可能被意外截断或合并。
常见错误现象：readLine 突然返回 null，但文件明明还有内容——其实是流已关闭或到达末尾；或者某行末尾多出空格/制表符，其实是原始数据里有不可见字符没被清理。
- 使用前确保输入流未被其他代码提前
close() - 若源数据来自网络或用户上传，优先用
InputStreamReader显式指定编码（如new InputStreamReader(in, "UTF-8")），否则默认平台编码可能导致乱码，readLine仍能返回字符串，但内容已损坏 -
readLine返回null是唯一可靠的“结束”信号，不要用available() == 0判断——该方法对网络流或压缩流常返回 0 却仍有数据
如何安全处理空行和空白行
真实文本数据（如日志、CSV、配置文件）经常包含纯空行或只有空格的行。readLine 会照常返回 "" 或含空格的字符串，不会跳过它们。是否忽略、保留还是报错，得由你决定。
示例场景：解析一个以空行分隔的多段配置块，如果直接 if (line != null && !line.trim().isEmpty()) 就跳过所有空行，会导致段落边界丢失。
- 区分“空行”（
line.length() == 0）和“空白行”（line.trim().length() == 0），前者可能是结构分隔符，后者更可能是误输入 - 避免在循环里反复调用
line.trim()——如果后续还要用原字符串做校验（如检查缩进），先存变量再判断 - 如果业务要求严格忽略首尾空白，建议统一在读取后立即处理：
String clean = line == null ? null : line.strip()（Java 11+）或line.trim()（旧版）
readLine 在大文件或慢流中的阻塞与超时问题
readLine 是阻塞式调用，它会一直等下一个换行符出现。如果上游是网络流且对方迟迟不发 \n（比如 HTTP chunked 编码出错、telnet 交互卡住），你的线程就卡死了。
没有内置超时机制。常见错误是把 BufferedReader 套在 Socket.getInputStream() 上却没设 socket timeout，结果整条链路挂起。
- 对网络流，必须在底层
Socket或URLConnection设置读超时（如socket.setSoTimeout(5000)），BufferedReader自身无法控制 - 对大文件，
readLine性能足够好（内部缓冲区默认 8KB），但频繁创建新String对象可能触发 GC；如需极致性能，考虑用Files.lines(Paths.get(...))（Java 8+）配合流式处理 - 别用
readLine解析固定长度记录（如每行 128 字节的二进制协议），它依赖换行符，不是字节计数器
替代方案：什么时候不该用 readLine
当你的“行”定义不等于“换行符分隔”时，readLine 就会成为障碍。比如解析 JSON Lines（每行一个 JSON 对象）时，若某个 JSON 字符串字段里含 \n，readLine 会把它切成两半，后续 JSON.parse 必然失败。
又比如读取 CSV 文件：逗号可能出现在引号内，换行也可能在引号中出现——这时 readLine 拆出来的根本不是逻辑上的“一行”。
- 含嵌套换行的数据（JSON、XML 片段、带换行的 SQL 注释）→ 改用
InputStream.read(byte[])手动缓冲 + 状态机解析 - 需要按字段而非整行处理（如 CSV、TSV）→ 用专用库（OpenCSV、Apache Commons CSV）或
Scanner配合自定义分隔符 - 要支持回退（读了一行发现不符合预期，想重读）→
BufferedReader不支持 rewind，改用PushbackInputStream或缓存上一行字符串
实际用的时候，最常被忽略的是编码和流生命周期管理——这两点出错，readLine 表现正常，但数据已经错了。
