Go csv.ParseError 怎样用 errors.As 取出行号和列号

用 encoding/csv 读取导入文件时，直接打印 err 往往只能看到“第几行、第几列解析失败”的一串文本。更稳妥的做法是用 errors.As 把错误还原成 *csv.ParseError，再分别读取 StartLine、Line、Column 和底层 Err。这样，跨行字段、错误类型和日志定位就不会混在一起。

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

先把一串文本错误还原成 ParseError

csv.Reader.Read 返回的错误可能被业务函数再次用 fmt.Errorf("读取订单: %w", err) 包装。此时不能依赖类型断言直接判断外层错误，而应把一个空的 *csv.ParseError 变量传给 errors.As。它会沿着错误链查找可赋值的错误，并在成功时填充这个变量。

package main

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

func report(err error) {
    // 目标变量是 *csv.ParseError，传入 &parseErr 才能让 errors.As 填充它。
    var parseErr *csv.ParseError
    if errors.As(err, &parseErr) {
        // 行列都是从 1 起算；Column 表示字节列号。
        fmt.Printf("记录起始行=%d，错误行=%d，字节列=%d\n",
            parseErr.StartLine, parseErr.Line, parseErr.Column)
        fmt.Printf("底层错误=%v\n", parseErr.Err)
        return
    }

    // 非 CSV 解析错误不能假设存在行列字段。
    fmt.Printf("其他读取错误：%v\n", err)
}

func main() {
    // 业务层可以在保留 %w 的前提下补充文件或任务上下文。
    r := csv.NewReader(strings.NewReader("id,remark\n1,\"broken\"x\n"))
    _, err := r.Read()
    if err != nil {
        report(fmt.Errorf("导入任务 csv-17：%w", err))
    }
}

这里的关键不是把错误字符串重新解析一遍，而是保留 Go 的错误链。ParseError.Unwrap 返回它的 Err 字段，因此既可以用 errors.As 取得位置，也可以用 errors.Is 判断是不是 csv.ErrQuote 或 csv.ErrBareQuote。

多行字段会把 StartLine 和 Line 分开

CSV 的一条逻辑记录可以跨越多行。假设第二行开始的字段用引号包裹，第三行出现了未按 CSV 规则转义的引号，那么 StartLine 会是 2，Line 会是 3。只看错误文本里的“第 3 行”容易让维护者去编辑器里找错记录。

如果输入中有中文，列号尤其不能直接当作 Go 字符串的 rune 下标。日志可以同时打印原始行内容，但定位高亮时要明确自己使用的是字节偏移；不要为了“看起来对齐”擅自把 Column 减一或按字符重新计算。

把 Column 当作 1 起算的字节列号

官方实现对 ParseError 的字段定义已经说明了这层语义：StartLine 是记录开始行，Line 是错误发生行，Column 是 1 起算的字节列号。它和正常读取成功后的字段位置不是同一条 API 路径；本文只讨论失败时的 ParseError。

实务中建议把位置字段和原始错误一起写入结构化日志。位置用于让用户修文件，Err 用于让程序决定提示“引号未闭合”还是“未加引号字段含有引号”。两者缺一不可：只有行列，没有原因，用户仍然不知道该改什么。

区分 ErrQuote、ErrBareQuote 与 ErrFieldCount

ParseError 不只表示引号问题。字段数与预期不一致时，Read 也可能返回带有 csv.ErrFieldCount 的错误，并同时返回已经读到的部分记录。不要看到 record 非空就直接交给业务映射；先判断错误类型，再决定隔离、跳过还是终止整个导入。

func readCSV(input string) error {
    r := csv.NewReader(strings.NewReader(input))
    for recordNo := 1; ; recordNo++ {
        record, err := r.Read()
        if err == io.EOF {
            return nil
        }
        if err == nil {
            // 只有没有解析错误时，才把记录交给后续字段映射。
            fmt.Printf("记录 %d：%q\n", recordNo, record)
            continue
        }

        var parseErr *csv.ParseError
        if errors.As(err, &parseErr) {
            // 保留结构化位置，便于日志、接口响应和人工修复共用。
            switch {
            case errors.Is(err, csv.ErrFieldCount):
                return fmt.Errorf("第 %d 条记录字段数不符合约定：%w", recordNo, err)
            case errors.Is(err, csv.ErrQuote), errors.Is(err, csv.ErrBareQuote):
                return fmt.Errorf("CSV 引号错误，起始行=%d，错误行=%d，列=%d：%w",
                    parseErr.StartLine, parseErr.Line, parseErr.Column, err)
            default:
                return fmt.Errorf("CSV 解析失败，行=%d，列=%d：%w",
                    parseErr.Line, parseErr.Column, err)
            }
        }

        // 读入层的非 ParseError 也要带上下文返回，不能静默吞掉。
        return fmt.Errorf("读取第 %d 条记录失败：%w", recordNo, err)
    }
}

这段循环把“解析器发现了什么”和“业务是否接纳”分成两层。ErrQuote、ErrBareQuote 通常需要回到原始 CSV 修正引号；ErrFieldCount 则要检查模板列数或 FieldsPerRecord 的配置。即使两者都能通过 errors.As 取到位置，修复动作也不能混用。

封装解析循环时保留错误链

封装函数最容易犯的错是只返回 errors.New(err.Error())，这样文字还在，结构化信息却丢了。应使用 %w 包装原错误；如果要增加文件名、批次号或记录序号，也放在外层上下文里，调用方仍然可以用 errors.As 和 errors.Is 继续检查。

最后可以按下面的清单复查：errors.As 的目标是不是 **csv.ParseError 形态；是否保留了 %w；是否把 Column 当成字节列；是否把跨行记录的 StartLine 与 Line 分开记录；是否对 ErrFieldCount 的部分记录做了明确处置。

相关问题

为什么直接写 err.(*csv.ParseError) 不可靠？

因为外层可能已经用 fmt.Errorf 包装，直接断言只检查当前一层；errors.As 会沿 Unwrap 错误链查找。

Column 是字符位置还是字节位置？

是从 1 起算的字节列号。包含多字节 UTF-8 字符时，不要把它当作 rune 序号。

Read 返回了 record，还要丢弃它吗？

解析出错时可能有部分记录，但是否接纳由业务契约决定。先按错误类型分类，再决定隔离或终止，不能仅凭 record 非空放行。

官方实现地址：https://go.dev/src/encoding/csv/reader.go；错误检查文档：https://pkg.go.dev/errors#As。