CSV字段中换行导致读取错位怎么办

Go 读取 CSV 时，字段中的换行不一定是错误。双引号包围的字段允许包含换行；如果先用 Scanner 或 strings.Split 按物理行切开，再解析每一行，就会把一条完整记录拆坏。应让 encoding/csv.Reader 直接读取完整输入流，并确保导出端正确引用字段。

官方依据：https://pkg.go.dev/encoding/csv。本文示例为原创说明代码，未在本机运行。

为什么逐行读取会把一条记录拆开

CSV文件由逻辑记录组成，记录中有编号字段、备注字段等内容。物理行只反映文本中的换行位置，不能代表记录数量。备注字段被双引号边界包围时，字段内换行仍属于备注，不会产生新记录；字段内的双引号则要用连续两个双引号表达。

Scanner 默认按行切分，不保留 CSV 引号状态。把每个片段交给一个新 Reader，已经无法知道前面有没有未结束的引用字段。增加 Scanner 的缓冲大小只能解决部分单行长度限制，不能修复记录边界。也不要直接删除换行，因为这会改变用户原始备注。

让Reader直接读取完整CSV流

真实文件可以把打开后的文件对象直接传给 csv.NewReader，由调用方负责关闭文件。以下以内存数据演示导出和读回；每次成功的 Read 返回一条完整记录，返回的备注字段不要再按换行拆成业务记录。

package main

import (
 "encoding/csv"
 "errors"
 "fmt"
 "io"
 "strings"
)

// main 以内存数据演示完整记录，不执行文件读写。
func main() {
 var buf strings.Builder
 w := csv.NewWriter(&buf)
 records := [][]string{{"编号", "备注"}, {"A17", "第一段\n第二段，含\"确认\""}, {"B23", "普通备注"}}
 for _, row := range records {
  if err := w.Write(row); err != nil { panic(err) }
 }
 // 缓冲刷新无返回值，必须另外检查 Error。
 w.Flush()
 if err := w.Error(); err != nil { panic(err) }
 // 把完整输入交给同一个解析器，禁止先按物理行截断。
 r := csv.NewReader(strings.NewReader(buf.String()))
 r.FieldsPerRecord = 2
 for {
  row, err := r.Read()
  if errors.Is(err, io.EOF) { break }
  if err != nil { panic(err) }
  // 转义展示换行，避免日志外观造成记录数量的错觉。
  fmt.Printf("编号=%q 备注=%q\n", row[0], row[1])
 }
}

按示例的数据设计，应得到一条表头和两条业务记录，A17 的备注仍然是一个字符串。%q 以转义形式展示其中的换行和引号，便于区分日志换行与数据换行。生产环境应将示例的 panic 改为返回错误或记录失败任务，避免单个文件错误终止整个服务。

有表头时应先读取并确认列名，再处理业务行。FieldsPerRecord=2 表示每条记录要求两列；默认零会采用第一条记录的列数约束后续记录，负数则关闭列数检查。这个配置不会修复损坏引号，更不会补回预处理时被丢失的内容。

导出端必须正确处理引号

自己生成 CSV 时，向 csv.Writer 传入原始字段，由它处理引用和转义。不要手工先包双引号，也不要用 strings.Join 拼接字段。原始字段、csv.Writer、CSV字节流、csv.Reader 和完整记录共同构成交换格式契约，任意一侧自行改变格式都会影响导入。

Write 成功后还要 Flush，再检查 Error，因为真正的底层写入可能发生在缓冲刷出时。若底层是文件，还需要处理 Close 的错误；示例使用 strings.Builder，不涉及文件关闭。Writer 默认使用 LF 作为记录换行，对接方要求 CRLF 时应明确设置 UseCRLF。

遇到坏文件怎样定位

解析错误可通过 errors.As 提取 *csv.ParseError：StartLine 是记录起始物理行，Line 是错误所在行，Column 是从一开始的字节列。中文字符可能占多个字节，不能将字节列直接当作屏幕文字位置。成功读取后，FieldPos 可查询该条记录指定字段的起始行与字节列，调用前必须保证字段索引有效。

Read 返回错误时可能同时带有部分记录，字段数错误也可能返回完整记录。不要忽略 err 就把数据写入数据库。示例直接停止；生产导入可记录文件与错误位置，交由格式修复处理。遇错后盲目跳过一个物理行也不可靠，因为破损引用可能跨越多行。

常见边界问题

打开LazyQuotes就能解决吗？

不能。它只放宽特定引号规则，不知道缺失边界后的文字究竟属于哪个字段。合法多行字段无需打开它，格式损坏应回到导出端修复。

CRLF是否会保持原样？

Reader 会将 CRLF 转为 LF，包括多行字段内部，因此读写往返不是原始字节的无损复制。若业务需要保留原文件字节，应另外保存原文件。

逐条Read的内存是否固定？

逐条读取避免 ReadAll 一次保留整个文件，但单条记录仍然可能很大，应设置业务输入规模和字段长度限制。若启用 ReuseRecord 并保留多条记录，需要复制返回切片，防止下一次读取复用其底层数组。

修复重点是完整流输入和正确引用规则。保留字段内的合法换行，才不会以表面整齐换来数据丢失。