Go encoding/csv处理字段数量变化的行的错误策略

Go 读取 CSV 时，字段数量变化不一定是解析失败。真正要先决定的是：输入是否有固定数据契约。固定列的文件应让 FieldsPerRecord 做硬校验；列数由首行决定的文件可以保留默认值 0；确实允许每行不同字段数时才设为负数。更重要的是，Read 遇到 ErrFieldCount 仍会返回当前行，因此不要因为有 error 就直接丢弃 record。

先把 CSV 的字段契约说清楚

同一个 Reader 的三种设置，对应三种完全不同的输入假设。固定模板适合财务、订单等列定义稳定的文件；首行推断适合导出方会调整列数、但单个文件内部应保持一致的场景；负数模式适合日志型或半结构化 CSV，不过应用层必须自己判断关键列是否存在。

Read 返回两部分：记录内容和错误类型

字段数不符时，最容易写错的是下面这种判断：只要 err != nil 就跳过当前行。这样会把异常记录连同定位线索一起丢掉。应先保存 record，再用 errors.Is 判断是否为 csv.ErrFieldCount；如果是，就记录行号、实际字段数和原始业务标识，随后进入隔离队列或按规则补齐。

package main

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

func readRows() {
	// 第一条数据有三列，后续行必须保持三列。
	r := csv.NewReader(strings.NewReader("id,name,amount\n1,张三,18\n2,李四\n"))
	r.FieldsPerRecord = 0

	for {
		record, err := r.Read()
		if errors.Is(err, csv.ErrFieldCount) {
			// 当前 record 仍可用于记录异常，不要直接丢弃。
			fmt.Printf("字段数异常：实际=%d，内容=%v\n", len(record), record)
			continue
		}
		if err != nil {
			// 引号、分隔符等 ParseError 不能按普通缺列处理。
			fmt.Printf("CSV 语法错误：%v\n", err)
			break
		}
		if record == nil {
			// nil record 表示没有更多数据，正常结束循环。
			break
		}
		fmt.Printf("有效记录：%v\n", record)
	}
}

注意循环中的 continue 只是示例策略。生产导入通常还要限制异常行数量，并把 record 交给带文件名、行号和批次号的错误记录器。若发生的是 ErrBareQuote 或 ErrQuote，应按 CSV 语法错误隔离，不能误贴成“缺少一列”。

允许变宽时，补齐规则必须写在应用层

将 FieldsPerRecord 设为负数只能关闭库层的数量检查，并不会自动把短行补成固定结构，也不会替你判断多出来的字段。建议先把表头映射成业务字段，再针对关键列做边界处理：缺少主键直接拒绝；可选列缺失补空值；超出列保留到扩展字段或转人工复核。不要按数组下标盲取，否则一行少了一个逗号，后面的金额和日期都可能错位。

一个实用的检查顺序是：先确认关键列数量，再做字符串到金额、日期等业务类型的转换；转换失败时仍保留字段数组和错误原因。对于必须全量成功的导入，任何异常都应让批次失败并生成报告；对于可部分成功的导入，则要保证成功行和异常行使用同一个批次标识。

常见问题与处理结论

为什么第一行正常，第二行突然出现 ErrFieldCount？

默认的 FieldsPerRecord=0 会把第一条记录的字段数设为后续标准，第二行列数变化就会返回该错误。检查首行是否真的是数据表头，以及导出文件是否混入了不同模板。

把 FieldsPerRecord 设成负数是不是最简单？

只有在应用层有明确的变宽规则时才适合。否则它只是关闭保护，不能解决列错位和关键字段缺失。

ErrFieldCount 返回的 record 能不能继续使用？

可以用于诊断、隔离和按业务规则修复，因为 Read 会把当前记录与该错误一起返回；但是否入库必须由字段契约和关键列校验决定。

处理字段数量变化的核心不是压掉错误，而是把数据契约落成参数和分流规则：固定模板用正数，单文件同构用 0，变宽数据用负数并补上应用层校验。这样既能保留异常行的证据，也能阻止错位字段悄悄进入后续业务。