csv.reader卡住或丢数据因底层io.reader不支持多次读取；中文乱码需处理bom和非utf-8编码；大文件应避免csv.readall而用循环read；默认支持换行/逗号/双引号字段但仅限逗号分隔符。
csv.Reader 读取时卡住或丢数据？检查底层 io.Reader 是否支持多次读取
Go 的 csv.Reader 本身不缓存输入，它直接从传入的 io.Reader 按需拉取字节。如果上游是网络响应、管道或某些自定义 reader，一旦被其他地方提前读过（比如调用过 resp.Body.Read()），后续 csv.NewReader() 就可能读到空内容或 EOF。
- 常见错误现象：
csv.Reader.Read()立即返回io.EOF，或只读到第一行就停止 - 正确做法：确保传给
csv.NewReader()的是「干净」的 reader —— 如果是http.Response.Body，别在创建csv.Reader前调用任何Read()；如果是文件，用os.Open()新开一个句柄 - 调试技巧：用
bytes.NewReader(bytes.TrimSpace(data))包一层测试数据，排除 I/O 干扰
中文字段乱码或解析失败？优先确认 BOM 和编码格式
Go 标准库的 encoding/csv **完全不处理字符编码转换**，它只按字节流解析 CSV，假设输入是 UTF-8。Windows 记事本保存的 CSV 常带 U+FEFF BOM，而某些 Excel 导出可能用 GBK/GB2312 —— 这些都会让 csv.Reader 把 BOM 当成字段开头，或把非 UTF-8 字节序列当非法 UTF-8 报 invalid UTF-8。
- 使用场景：读取用户上传的 Excel 另存为 CSV 文件、第三方系统导出报表
- 实操建议：读取前先检测并剥离 BOM：
bytes.TrimPrefix(data, []byte("\xef\xbb\xbf"))；若确认是 GBK，必须用golang.org/x/text/encoding/unicode或github.com/axgle/mahonia转换后再喂给csv.NewReader() - 性能影响：BOM 剥离几乎无开销；GBK 转 UTF-8 会增加一次内存拷贝和解码耗时，大数据量时建议流式转换
大文件内存暴涨？别用 csv.ReadAll，改用循环 Read
csv.ReadAll() 会把整个 CSV 加载进内存，构建一个 [][]string。10 万行 × 20 列的报表轻松吃掉 200MB+，还可能触发 GC 频繁停顿。生产环境报表动辄百万行，必须流式处理。
- 正确姿势：用
for record, err := reader.Read(); err == nil; record, err = reader.Read()循环逐行处理 - 容易踩的坑：忘记检查
err != nil && err != io.EOF，导致文件末尾异常被忽略；或在循环里反复 append 到同一个 slice，引发底层数组多次扩容 - 参数差异：
reader.FieldsPerRecord设为 -1 允许每行列数不同（适合报表有合并单元格导出的脏数据）；设为正数则自动校验列数，错行直接报错
字段含换行符、双引号或逗号？csv.Reader 默认能处理，但分隔符不能改
标准 CSV 规范允许字段用双引号包裹，内部换行、逗号、双引号都合法 —— encoding/csv 默认支持，无需额外配置。但它**硬编码使用逗号作为分隔符，不支持 TAB 或分号等其他分隔符**。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误现象：用 Excel 导出的「制表符分隔」文件，直接喂给
csv.Reader会把整行当一个字段 - 解决方法：如果是 TSV，改用
encoding/csv的兄弟包encoding/json不合适，得手动用strings.Split()或换github.com/gocarina/gocsv等第三方库 - 注意点：双引号字段中若含双引号，必须写成两个双引号（
"a""b"），csv.Reader会自动转成a"b；但若原始数据没按规范转义，解析就会错位
CSV 解析真正的复杂点不在语法，而在上游数据质量 —— 字段缺失、列数突变、混合编码、BOM 隐形存在，这些往往比代码逻辑更消耗排查时间。
