Go csv.Reader Comment 如何跳过输入中的注释行

读取配置导出的 CSV 时，文件里常常夹着以 # 开头的说明行。Go 不需要先把整份文本拆开再过滤：给 csv.Reader.Comment 设置一个合法字符，Reader 就会忽略“行首就是该字符”的整行内容。关键边界是，注释字符前不能有空白；带缩进的 # note 仍会进入字段解析。

先把 Comment 当成输入格式的一部分

适合使用 Comment 的文件通常有明确约定：说明行以某个字符顶格开始，真正的数据行遵循 CSV 规则。下面的示例使用 #，并故意保留一行带前导空格的内容，方便看出两者差异。

package main

import (
    "encoding/csv"
    "fmt"
    "io"
    "log"
    "strings"
)

func main() {
    input := "# generated by billing\nname,amount\nAlice,12\n # indented note\nBob,9\n"
    reader := csv.NewReader(strings.NewReader(input))
    reader.Comment = '#'

    for {
        record, err := reader.Read()
        if err == io.EOF { // 读完所有记录后正常结束循环。
            break
        }
        if err != nil { // 格式错误不能当成普通数据继续处理。
            log.Fatal(err)
        }
        fmt.Printf("%q\n", record) // 观察注释行是否被跳过，以及空白行如何保留。
    }
}

这里真正被跳过的是第一行。第四行的 # 前有空格，因此它不是注释；它会按普通 CSV 行继续解析。若该行没有逗号，默认的字段数约束可能让读取直接返回 ErrFieldCount，这正是输入格式不统一时应该暴露的信号。

为什么 TrimLeadingSpace 不能解决缩进注释

Comment 的判断发生在“行首字符”层面，而 TrimLeadingSpace 作用于字段开头。即使把它设为 true，也不会把 # note 重新解释成注释。这样设计可以避免解析器擅自丢掉用户本来想保留的字段内容。

因此，文件协议最好二选一：要么规定注释字符必须顶格；要么在交给 csv.Reader 前做一层明确的输入预处理，并记录预处理规则。不要仅凭“看起来像注释”就过滤空白行，否则可能误伤合法的第一列文本。

配置 Comment 时还要一起确认三个边界

如果注释字符来自配置文件，启动时就校验它与分隔符是否相同；如果数据量较大，优先逐条 Read，把异常行连同业务上下文记录下来。只有确定文件规模可控、且需要一次性校验全部记录时，才使用 ReadAll。

不规则 CSV 应该拒绝、预处理还是保留

可以用三个问题做判断：注释协议是否由文件生产方保证？带空白的 # 行是否可能是合法字段？异常行是否必须被追踪？如果协议明确且异常应失败，直接设置 Comment 并保留字段数检查；如果历史文件混杂缩进注释，先做可审计的预处理；如果第一列允许出现 #，不要扩大注释匹配范围。

还有一个容易被忽略的细节：如果设置了 ReuseRecord，连续调用 Read 可能复用上一条记录的底层切片。需要长期保存记录时要复制它。这个设置与 Comment 无关，却经常在“过滤后再异步处理”场景中一起暴露问题。

常见问题

空行会不会被 Comment 当成注释？

不会。Go 的 CSV 规则会忽略空行；Comment 针对的是以指定字符开头的非空行。

注释字符可以设置成逗号吗？

不可以。Comment 必须是合法字符，而且不能与 Comma 相同。

想忽略任意空白后的 # 该怎么办？

不要依赖 TrimLeadingSpace。应先约束输入格式，或写清楚可记录、可复查的预处理层，再交给 CSV 解析器。

把 Comment 看成文件协议的一部分，答案就很明确：顶格注释交给 csv.Reader，缩进注释先处理或拒绝，字段数量和错误仍按正常 CSV 语义检查。