Go csvutil 怎么逐条解码 CSV 而不保留所有记录

Go csvutil 要逐条解码 CSV 而不保留所有记录，应把 encoding/csv.Reader 交给 csvutil.NewDecoder，循环对单个结构体调用 Decode，每次成功后立即处理，遇到 io.EOF 结束。不要把整个切片传给 Decode，也不要在循环中不断 append 全部记录。我更倾向于先写一个只有计数器的统计工具，用它把“读取是流式的”和“应用没有累积数据”这两件事分开。

官方地址：https://github.com/jszwec/csvutil

我希望统计库存，而不是先装下整个文件

设想业务每天交来一份库存 CSV，当前任务仅需要记录总数，以及数量大于零的记录数。如果最终结果只有两个数字，先把每条库存保存进大切片，对这个任务没有必要。这里的“小项目”从标准输入接收文件内容，只持有当前记录和两个计数器，完成后输出摘要。

这不是“无论输入多大内存都固定”的承诺。CSV 解析器仍需缓冲记录，字段长度、单条记录大小和下游持有的数据都会影响占用。我们能控制的是代码不按总记录数保存整批业务对象，不是取消解析过程的一切内存分配。

把输入格式和模块先说清楚

示例采用 csvutil v1.10.0 作为固定复现依赖，不宣称它是最新版本。CSV 必须包含 sku、quantity 两个表头；本例对这两个字段设置显式 csv 标签。输入分隔符使用标准逗号，不引入额外的分隔符转换。

# 在独立示例目录初始化模块，避免修改已有项目的模块名。
go mod init example.com/stock-csv-summary
go get github.com/jszwec/csvutil@v1.10.0
# 将后面的完整代码保存为 main.go。

NewDecoder 在没有显式传入表头时会读取第一条记录作为表头。因此不要先用 Reader.Read 手动吃掉表头，又让 NewDecoder 按默认方式读取；也不要把没有表头的文件直接套进本例。无表头数据需要另行提供表头契约。

让 Decode 的目标始终只有一条库存

我把处理函数的结果设计为 Stats 值，而不是 StockRow 切片。这样接口本身就提醒调用方：这是汇总，不是读取全部记录。错误发生时返回已经完成的统计与错误，但主程序不会把部分统计打印成完整成功结果。

package main

import (
    "encoding/csv"
    "fmt"
    "io"
    "log"
    "os"

    "github.com/jszwec/csvutil"
)

type StockRow struct {
    SKU string `csv:"sku"`
    Quantity uint64 `csv:"quantity,omitempty"`
}

type Stats struct {
    Rows uint64
    Positive uint64
}

func summarize(input io.Reader) (Stats, error) {
    var result Stats
    dec, err := csvutil.NewDecoder(csv.NewReader(input))
    if err == io.EOF {
        return result, nil // 空输入按本工具约定视为零条记录。
    }
    if err != nil {
        return result, fmt.Errorf("读取CSV表头: %w", err)
    }
    for {
        // 每轮新建对象；空数量被跳过时不会继承上一条数值。
        var row StockRow
        err := dec.Decode(&row)
        if err == io.EOF {
            return result, nil // 只有正常读完才视为完整成功。
        }
        if err != nil {
            return result, fmt.Errorf("解码第%d条数据: %w", result.Rows+1, err)
        }
        result.Rows++
        if row.Quantity > 0 {
            result.Positive++
        }
        // 当前记录只参与计数，不追加进切片或交给无界队列。
    }
}

func main() {
    // 标准输入由调用方提供，避免先用 ReadFile 读入全部字节。
    summary, err := summarize(os.Stdin)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Printf("记录数=%d，有库存记录数=%d\n", summary.Rows, summary.Positive)
}

Quantity 使用 omitempty，是因为本例约定空数量按零参与统计；循环内每次新建 row，避免被跳过的字段沿用之前的值。若业务不允许数量为空，应去掉这个宽松约定，明确拒绝或检查输入，不要为了“文件能读完”掩盖业务错误。

官方 Decode 文档区分单结构体与切片目标：对切片调用会读入并保存整批数据。因而流式意图应体现在目标类型上，而不只是变量名叫 stream。即便逐条 Decode，之后把 row append 到切片里，应用仍会持有所有记录。

用三条记录观察工具行为

把下列 CSV 内容保存为 sample.csv。CSV 数据块不支持这里使用的代码注释语法，所以说明放在块外：表头是字段映射名称，第二条 quantity 为零，第三条为空，按本例约定同样视为零。

sku,quantity
ITEM-A,7
ITEM-B,0
ITEM-C,

# 用文件重定向提供标准输入；程序不覆盖输入文件。
go run . 

预期摘要为三条记录，其中一条数量大于零。这是供读者运行时比对的预期，不是本文已经执行的测试结果。示例只输出最终摘要，因此不能凭输出行数判断内部是否逐条处理，要看 Decode 的目标与下游持有方式。

接入业务时，别在下游重新堆积

我觉得这个小工具最值得保留的习惯，是同步处理当前记录。如果后续要把记录写入存储，可把计数处替换成同步消费函数，并明确其失败策略。如果确实需要批量写入，就设定有上限的批次、写完释放，还应处理最后不足一批的数据。不要用无上限通道或不受控的 goroutine 来制造另一个隐藏的整批缓存。

代码中的“第几条数据”是成功解码数量加一，不是物理文件行号。CSV 引号字段可能含换行，因此不要把业务记录序号当作行号。排错时保留原始解析错误，并按输入格式的实际信息定位，不能靠换行数猜记录边界。

对于数百万条数据，逐条解码能避免整批切片，但单条超长文本、输入上游缓冲和自定义消费器仍有代价。此处没有给出内存曲线或性能数字，因为没有执行压测。若需要服务端资源上限，应单独制定输入大小与记录约束，不能仅凭使用 Decoder 就宣称内存风险消失。

怎样判断没有保留所有记录

本项目的验收重点有三项：Decode 传入的是单结构体地址；成功处理后没有把对象加入长期集合；结果只保留必要摘要。再分别准备正常数据、空输入、只有表头、非法数量等样本，观察程序是否遵循约定。非法输入不应该被主程序打印成完整成功。

空输入按这里的工具约定返回零计数，不是对所有业务都合理。如果导入合同要求必须含表头，则把初始化阶段的 EOF 改为业务错误。标准输入也不由 summarize 关闭，函数只消费 io.Reader，资源所有权应由真正打开输入的一方负责。

为什么用 Decoder 后内存仍随着记录数增加？

先看目标是否为切片，再看是否 append、缓存、排队或异步持有全部对象。逐条读取不等于逐条释放业务引用。

Decode 返回 EOF 时还需要处理 row 吗？

本例的单结构体循环只在无错误时处理当前记录；EOF 直接结束，避免将未成功解码的零值当成一条数据。

可否把 row 放在循环外复用？

可以另行设计，但须明确重置策略。本文的空字段带 omitempty，所以每轮新建零值对象更容易解释，也不会残留上一条数量。

对只需要统计或立即消费的任务，我会选这种小而明确的接口；对确实需要全量随机访问的业务，则不应该假装只靠改成 Decoder 就能取消全量持有。

参考：csvutil v1.10.0 API、项目官方仓库与Go CSV 解析器文档。