Go csv.Reader 怎样处理不等长记录

Go csv.Reader 要接受不等长记录，可以在首次读取前设置 FieldsPerRecord = -1。如果业务仍要求固定列数，就设置明确的正数，并用 errors.Is(err, csv.ErrFieldCount) 单独处理不合格记录。LazyQuotes 只改变部分引号语法的接受方式，不能代替字段数设置。

官方地址：https://pkg.go.dev/encoding/csv

先决定变长记录是否合理，再决定放宽字段数还是隔离异常；引号语法错误另行处理，不能把所有读取错误都当作少了一列。

最小配方：确实允许变长时关闭字段数检查

面对不同来源的 CSV，我会先问一个业务问题：短记录代表允许省略的尾部字段，还是导出文件损坏？只有前者才适合直接允许变长。下面是已有 io.Reader 输入 source 时的配置片段：

// 明确允许变长记录；引号规则仍保持严格。
r := csv.NewReader(source)
r.FieldsPerRecord = -1
r.LazyQuotes = false

这样拿到的每个 record 长度可能不同。访问 record[2] 之前仍要检查长度；标准库不会自动把短记录补成固定长度，也不会把额外字段删除。字段类型、必填项与业务列名仍需由程序解释。

关键配置：正数、零与负数分别意味着什么

默认的 0 并不是“任何列数都接受”。首条记录读入后，后续记录就会受到它确定的字段数量约束。如果表头有三列，下一条只有两列，默认设置同样会产生字段数错误。若表头之前存在导出说明，应先按文件格式约定处理，不能期待 Reader 自动识别哪条才是真正表头。

变体：只允许缺少尾列，怎样保留异常信息

有些业务允许省略备注，却不允许缺少编号。可以关闭标准库的等长检查，再按业务规则判断最少字段数、最多字段数与必填项；也可以坚持三列，将不等长记录集中隔离后人工处理。我的选择通常是先保留原始字段和错误原因，再做明确的规范化，避免静默补空掩盖缺失。

A2,纸袋 是两个字段，而 A2,纸袋, 是三个字段，最后一个为空。二者在字段数检查中不同。若要把“缺少备注”和“备注为空”统一处理，应把这种选择写在业务层，而不是认为 CSV 解析器已经替你完成了补齐。

容易混淆的坑：LazyQuotes 不解决列数问题

LazyQuotes 打开后，未引用字段内可以出现引号，已引用字段内也可以出现未成对转义的引号。它适用于你明确了解某个来源的非规范引号约定时进行兼容，不是读取报错时应当先开启的万能开关。

字段数量由解析完成后的字段切片决定；引号规则则影响字段内容怎样被解释。把两者同时无条件放宽，会让输入偏离预期时更难知道究竟是哪一层发生了变化。对于结构稳定的导出文件，先保持严格引号规则并返回清楚的位置通常更有帮助。

完整片段：固定三列，隔离不等长记录

以下示例保留固定三列约定：正常记录继续处理，字段数错误记录被隔离，其他读取或语法错误则停止。第一条三列表头也会被读入；真实导入任务应按明确约定另行消费表头。

package main

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

func main() {
    input := "编号,名称,备注\nA1,茶杯,蓝色\nA2,纸袋\nA3,水瓶,透明,加盖\n"
    r := csv.NewReader(strings.NewReader(input))
    r.FieldsPerRecord = 3 // 本例约定三列；用 -1 则完全关闭字段数检查。
    r.LazyQuotes = false // 字段数不一致不需要放宽引号语法。

    for {
        record, err := r.Read()
        if errors.Is(err, io.EOF) {
            break
        }
        if errors.Is(err, csv.ErrFieldCount) {
            // 字段数错误仍附带该条记录；本例隔离它，不补列或截列。
            var pe *csv.ParseError
            if errors.As(err, &pe) {
                fmt.Printf("隔离记录：起始行=%d，期望=%d，实际=%d\n",
                    pe.StartLine, r.FieldsPerRecord, len(record))
            }
            continue
        }
        if err != nil {
            // 语法错误可能只返回部分字段，停止读取，避免误当完整记录。
            var pe *csv.ParseError
            if errors.As(err, &pe) {
                fmt.Printf("解析失败：起始行=%d，出错行=%d，字节列=%d，原因=%v\n",
                    pe.StartLine, pe.Line, pe.Column, pe.Err)
            } else {
                fmt.Printf("读取失败：%v\n", err)
            }
            return
        }
        fmt.Printf("可处理记录：%q\n", record)
    }
}

示例预期是表头与 A1 可处理，A2 与 A3 因列数不符进入隔离分支；这些是代码的预期行为说明，不是本机运行记录。若改成 -1，A2 和 A3 不再产生 ErrFieldCount，但调用端仍要决定两个字段和四个字段应当如何映射。

这里使用 errors.Is 而不是直接比较错误字符串，因为 ErrFieldCount 会由 ParseError 携带。errors.As 则用于取得位置和底层错误。不要在看到非 nil 错误后仍无条件把 record 写入业务表：引号语法出错时，它可能仅包含出错之前成功解析的字段。

ParseError 的行列信息应该怎样理解

StartLine 表示记录起始行，Line 表示错误所在行，Column 是从 1 开始的字节列。CSV 引用字段可以包含换行，所以一条记录不一定只占一个物理行；读取次数也不能简单当作源文件行号。中文会占多个 UTF-8 字节，错误字节列不能直接当作屏幕字符列。

字段数错误可以按示例隔离后继续读取下一条记录；语法错误可能破坏你对记录边界的理解，示例选择停止。确需恢复时，应依据来源格式制定规则，不要简单跳过一个物理行，也不要丢弃部分字段后宣称整条记录已经完整导入。

能不能直接使用 ReadAll？

如果只想一次性接受全部合法记录可以使用它；如果需要逐条隔离字段数异常并继续，Read 循环更适合把每条记录和对应错误放在一起处理。

关闭字段数检查后还会 ParseError 吗？

会。字段数策略不会消除引号语法等解析问题，也不会自动修复底层读取错误。

少一列时怎样防止索引越界？

先根据 len(record) 决定允许的字段范围，再取值。不要把“解析成功”与“符合业务结构”混为一谈，补齐、拒绝、保留变长都应是明确的应用策略。

技术依据：Go csv.Reader 字段说明、Reader.Read 返回约定、ParseError 位置与错误信息。