Go csv.Reader InputOffset 怎么记录断点位置

平时用 Go 处理大体积 CSV 数据的时候，怕程序意外中断后要重头解析全量文件浪费资源，直接用 csv.Reader 的 InputOffset 字段就能拿到当前已经读取到的字节位置，把这个值存下来作为断点，下次重启的时候从这个偏移位置打开文件续读就可以接着处理后面的内容了。

处理大 CSV 时，真正要保存的不是“第几行”，而是最近一条完整记录结束后的字节位置。csv.Reader.InputOffset() 返回的就是这个输入流偏移：成功读完一条记录后调用它，再把偏移写入 checkpoint，重启时对同一个文件执行 Seek，就能从安全边界继续。

先理解 InputOffset 记录的是哪一个位置

Go 官方 encoding/csv 文档把这个方法定义为当前 reader 的输入流字节偏移，返回最近一次成功读取的行结束处，也是下一行开始处。这里的“行”更接近 CSV record：如果一个字段被双引号包住并包含换行，Reader 会把它们作为一条记录处理，偏移也会跨过完整的多行字段。

因此它适合做文件级断点，却不能直接回答“已经处理了多少行”。文件使用多字节 UTF-8、引号字段或空行时，字节数与物理行数都可能不一致。恢复逻辑只需要关心下一个 Reader 从哪个字节开始，不要用 offset 去推算业务主键或记录序号。

用 Read 与 InputOffset 保存可恢复断点

保存顺序很重要：先拿到记录，完成数据库写入或下游发送，确认业务动作成功，最后才写 checkpoint。这样进程在业务动作失败时重启，会重新处理这一条；如果先保存 offset，就可能出现“断点已前进、数据却没落地”的丢失。

package main

import (
    "encoding/csv"
    "fmt"
    "io"
    "os"
    "strconv"
)

func process(path, checkpoint string) error {
    // 以追加方式读取 checkpoint；不存在时从文件开头开始。
    start := int64(0)
    if data, err := os.ReadFile(checkpoint); err == nil {
        n, parseErr := strconv.ParseInt(string(data), 10, 64)
        if parseErr != nil || n 

示例中的 Seek(start, io.SeekStart) 必须建立在“文件内容仍然是同一个版本”的前提下。生产代码通常把文件大小、修改时间或内容哈希与 offset 一起保存；如果文件被截断后又写入新内容，即使新文件更大，旧偏移也不能盲目复用。

断点恢复时先校验文件和表头

如果任务总是从文件开头读取表头，恢复到非零 offset 后就不应再次跳过一行。更稳妥的做法是首次处理时单独读取并记录表头的摘要，后续从 checkpoint 直接创建 Reader；或者把表头放进独立元数据，不让恢复逻辑依赖“第一条记录就是表头”这个假设。

可以把断点看成一个小型事务记录，至少包含 path、offset、size 和文件指纹。启动时先比较当前文件与记录值：文件未变化才允许 seek；如果文件是持续追加且旧内容不可变，可以允许当前大小变大，但仍要保证旧前缀没有被改写。文件轮换、重新导出或排序后，应创建新 checkpoint，而不是修正旧 offset。

常见问题：为什么偏移量不能直接当行号

InputOffset 能否定位到任意字段？不能。它只提供 reader 的记录级输入边界；字段位置要用 FieldPos 取得行列信息，但那也不是恢复整个文件的 checkpoint。

能否每读一条就把 offset 写到同一个文件？可以，但要考虑崩溃时的半写入。实际项目可写临时文件后原子替换，并让业务处理具备幂等性，避免重试造成重复副作用。

读到 io.EOF 时还要保存 offset 吗？不必把 EOF 当成一条记录。成功读取的最后一条记录已经把位置写入 checkpoint；如果文件为空，则初始的零偏移即可表示尚未处理任何记录。