必须启用LazyQuotes并设FieldsPerRecord为-1，因Go标准库默认将换行视为记录分隔符，即使出现在双引号字段内；LazyQuotes允许跨行quoted字段，FieldsPerRecord=-1避免字段数校验中断解析。
CSV解析时双引号内换行符被截断怎么办
Go标准库encoding/csv默认把换行当作记录分隔符，哪怕它出现在双引号包裹的字段里——这直接导致多行文本字段被错误切分成多条记录。根本原因在于csv.Reader的FieldsPerRecord和TrailingComma等设置不控制换行识别逻辑，真正起作用的是底层是否启用“宽松模式”。
解决方法是显式启用LazyQuotes并禁用TrimLeadingSpace（后者可能干扰空白符判断），同时必须设置FieldsPerRecord为-1（允许变长）：
reader := csv.NewReader(strings.NewReader(data)) reader.LazyQuotes = true reader.TrimLeadingSpace = false reader.FieldsPerRecord = -1 // 关键：不强制每行字段数一致
- 没设
LazyQuotes时，含换行的quoted字段会触发csv.ParseError: bare " in non-quoted-field -
TrimLeadingSpace = true（默认）会吃掉字段开头的空格和制表符，破坏原始空白结构 - 若提前知道字段数，设成正整数反而更安全；但处理自由格式CSV时必须用-1
如何保留字段内所有空白符（包括\r\n\t）
Go的csv.Reader本身不修改字段内容，但常见陷阱是读取后用strings.TrimSpace()或fmt.Sprintf二次处理——这会抹掉制表符、回车、连续空格。真正的空白保全发生在解析完成后的字符串变量里，只要不主动trim、replace、正则清理就原样存在。
验证方式：对读出的字段做fmt.Printf("%q", field)，能看到"line1\r\nline2\tvalue"这类原始转义。
立即学习“go语言免费学习笔记（深入）”；
- Windows换行
\r\n在quoted字段中会被完整保留，无需额外解码 - 字段开头/结尾的空格和制表符不会被自动去除，除非你调用了
strings.Trim*系列函数 - 如果源数据用
\r单独作换行（老Mac格式），Go也能原样保留，但注意某些终端显示异常
写入CSV时让多行字段正确包裹双引号
csv.Writer不会自动给含逗号、换行或双引号的字段加引号——它只在Write时检查字段内容，满足任一条件才包裹。但如果你手动拼接字符串再喂给Write，就绕过了这个机制，导致解析失败。
必须让每个字段作为独立[]string元素传入：
w := csv.NewWriter(os.Stdout)
w.UseCRLF = true // Windows换行兼容性可选
w.Write([]string{"normal", "line1\nline2", "has\"quote"}) // ✅ 自动加引号
// w.Write([]string{"\"line1\nline2\""}) // ❌ 手动加引号反而会导致嵌套引号错误
-
UseCRLF影响的是记录间换行符，不影响字段内\n的编码 - 字段含双引号时，
csv.Writer自动转义为""（两个双引号），不是\" - 不要用
fmt.Sprintf拼CSV行——那等于放弃RFC 4180合规性
特殊空白符导致解析卡死或panic的边界情况
当CSV含U+0000（null byte）、U+000B（vertical tab）、U+000C（form feed）时，encoding/csv会直接panic：csv.ParseError: bad record: unexpected null byte。这不是bug，而是RFC明确禁止null字节出现在CSV中。
- U+0000必须在读取前过滤，例如用
bytes.ReplaceAll(data, []byte{0}, []byte{}) - U+000B/U+000C虽不panic，但某些Excel版本会显示异常，建议预处理替换为空格
- 零宽空格（U+200B）等Unicode空白符会被当作普通字符保留，不影响解析，但可能干扰后续字符串比较
最易被忽略的是BOM头：UTF-8 BOM（\xEF\xBB\xBF）若存在，会成为第一字段的前缀，导致strings.HasPrefix(field, "\uFEFF")为true——必须在创建csv.Reader前剥离。
