在 Java 中处理 CSV 文件时，开发者常使用 BufferedReader，但有一个常见陷阱——引号内包含换行符。例如字段值为 "address\nline2",123，直接调用 readLine() 会导致错误断开，因为 BufferedReader 本身并不理解 CSV 语法，它只识别 \n 或 \r\n 这类行尾标记。
那么如何解决？核心思路是：读取后主动判断是否需要跨行合并。CSV 规范明确：双引号包裹的字段允许内部换行，且引号必须成对出现。只要抓住这一特点，就能正确处理。
判断是否需要合并下一行：看引号是否闭合
CSV 字段如果以 " 开头，就必须以 " 结尾；中间的 "" 是转义，表示一个实际的引号，不影响配对。因此核心逻辑是统计未被转义的引号个数是否为偶数：
- 每次读到一行，逐个字符扫描，遇到
""（两个连续引号）就跳过第二个，不翻转状态 - 维护一个布尔变量
inQuotes，初始为false - 遇到单独的
"且下一个字符不是"→ 翻转inQuotes - 读完该行后，如果
inQuotes == true，说明这行未结束，需要追加下一行
String line;
StringBuilder current = new StringBuilder();
while ((line = br.readLine()) != null) {
current.append(line);
if (!isQuoteClosed(current.toString())) {
current.append("\n"); // 保留原始换行，后续解析时统一处理
continue;
}
// 此时 current 是一个完整逻辑行
parseCsvRow(current.toString());
current.setLength(0); // 清空
}
这里的 isQuoteClosed() 就是上述状态机逻辑：遍历字符串，计数有效引号，最后判断是否偶数（即已闭合）。
不要依赖 line.endsWith("\"") 做简单判断
仅凭行尾是否为引号来判断，很容易出错：
"abc","def\nghi"：第二字段含换行但以"结尾 → 合理，可以正常工作"abc,"def"：第一字段未闭合，但行末不是"→ 仍需继续读取"text with ""escaped"" quote"：结尾是"，但前面有转义，实际已经闭合
仅靠结尾字符无法反映引号的嵌套状态，必须逐字符解析。
实际解析时，字段拆分也得用状态机，不能 split(",")
即使拼接好完整逻辑行，也不能使用 line.split(",") —— 因为像 ,"Beijing, China", 这种数据，逗号在引号内部，不是分隔符。
正确做法是：
- 再次遍历字符串
- 维护
inQuotes状态 - 只有在
!inQuotes && char == ','时才进行切分 - 遇到
"则翻转状态，遇到""则跳过下一个"
这样既能处理引号内的换行，也能正确提取每个字段的内容（包括保留内部的换行和逗号）。
补充建议：缓冲与性能优化
BufferedReader默认缓冲区为 8KB，处理大 CSV 文件时可以显式增大，例如new BufferedReader(reader, 64 * 1024)，能减少系统调用次数- 如果遇到超长字段（比如上 GB 的描述），使用
readLine()+ 字符串拼接容易导致内存暴涨，可改用char[]缓冲 + 状态机流式解析，避免一次性加载全部数据 - 如果项目允许，优先使用成熟库（如 OpenCSV、Apache Commons CSV），它们已内置这些逻辑，并经过大量边界测试
看似不复杂，但极易被忽略。
