Go encoding/csv 读文件遇到字段数不一致怎么办：FieldsPerRecord、LazyQuotes 与错误行定位

Go 用 encoding/csv 导入供应商文件时，最常见的失败不是文件找不到、路径不对，而是某一行比表头多了个逗号、或者少写了闭合引号，读取结果直接变成 record on line 27: wrong number of fields。遇到这类错误优先保留报错信号先定位坏行，如果业务确实允许每行列数不一致，再明确配置对应的读取策略，不要把脏数据悄悄当成正常记录直接落库。

字段数为什么会被第一行“锁定”

csv.Reader 的默认行为是让第一条成功读取的记录决定后续所有行的字段数。后续记录如果字段数量和这个值不一样，就返回 ErrFieldCount。这对固定格式订单表很有用：错误尽早暴露，后面的列不会悄悄错位，等入库之后才发现数据全歪。

r := csv.NewReader(strings.NewReader("id,name,amount\n1,Alice,12\n2,Bob,9,extra\n"))
for {
    record, err := r.Read()
    if err == io.EOF {
        break
    }
    if err != nil {
        log.Printf("line=%d err=%v", r.InputOffset(), err)
        break
    }
    fmt.Println(record)
}

这里不是“第二条数据少读了一列”，而是整条记录不符合固定列数约定。先保留这个失败信号，再决定是回到供应商修文件，还是进入兼容导入路径。

固定格式和可变格式要用不同的 Reader 配置

如果表头、明细行和尾部备注天然不是同一种结构，可以显式设置 FieldsPerRecord = -1，然后由业务代码根据记录长度分流：

r := csv.NewReader(file)
r.FieldsPerRecord = -1
r.TrimLeadingSpace = true

line := 0
for {
    record, err := r.Read()
    if err == io.EOF { break }
    line++
    if err != nil {
        return fmt.Errorf("csv line %d: %w", line, err)
    }
    switch len(record) {
    case 3:
        if err := saveOrder(record); err != nil { return err }
    case 4:
        saveWarning(line, record, "extra field")
    default:
        saveWarning(line, record, "unexpected field count")
    }
}

允许可变列不等于接受任意数据。每种长度仍然要有明确含义，未知长度应该进入失败报告，不能直接取第 record[0] 列到第 record[2] 列就当导入成功。

把 ParseError 变成可回查的失败报告

CSV 的解析错误往往发生在引号、换行或字段列位置。用 errors.As 把 *csv.ParseError 拿出来，日志就能从一句笼统的失败提示变成可操作的定位信息：

record, err := r.Read()
if err != nil {
    var pe *csv.ParseError
    if errors.As(err, &pe) {
        fmt.Fprintf(report, "line=%d column=%d start=%d: %v\n",
            pe.Line, pe.Column, pe.StartLine, pe.Err)
    }
    return err
}
_ = record

Line 是报错位置，StartLine 对跨行引号尤其有价值：一条逻辑记录可能从上一行开始，真正报错却出现在后面。失败报告最好同时保存原始文件名、批次号和原始行内容的脱敏摘要。

LazyQuotes 只解决兼容，不解决数据质量

有些供应商会在未加引号的字段里放置引号，默认解析会报 ErrBareQuote。开启 LazyQuotes 后，解析器会更宽松，但这意味着引号可能成为普通字符，金额、地址和备注字段都要再做业务核对。

r := csv.NewReader(file)
r.FieldsPerRecord = 3
r.LazyQuotes = true

for {
    record, err := r.Read()
    if err == io.EOF { break }
    if err != nil { return err }
    if strings.TrimSpace(record[2]) == "" {
        return fmt.Errorf("empty amount at line %d", r.InputOffset())
    }
}

如果只是为了让批次“跑完”而打开这个开关，最后得到的可能是一份格式看似成功、字段语义已经变形的订单数据。更好的做法是记录兼容模式，并抽样核对受影响字段。

常见问题：CSV 导入失败该先改哪一项

FieldsPerRecord 设为 -1 就不会报错了吗？

它只关闭固定字段数检查，引号不闭合、裸引号等语法错误仍可能失败，业务字段校验也不会自动消失。

能不能跳过所有解析错误继续导入？

可以设计“逐行隔离”的导入流程，但必须保存失败行、行号和原因。静默跳过会让成功数量看起来正常，却无法复盘缺失数据。

InputOffset 能直接当 CSV 行号吗？

不能。它表示输入中的字节偏移，不是逻辑行号；需要行号时应自己计数，跨行记录则优先使用 ParseError.Line。

收尾：先定义数据契约，再决定解析宽松度

固定列的 CSV 用默认严格模式，能尽早暴露供应商问题；结构确实可变时才使用 FieldsPerRecord = -1，并在业务层按长度分流。LazyQuotes 是兼容手段，不是质量证明。把解析错误转成带行列信息的报告，导入任务才真正具备可恢复性。