Go csv.Reader LazyQuotes 遇到未闭合引号怎么办

如果 Go 的 csv.Reader.Read 因为引号不成对而返回 parse error，可以先判断数据是否只是旧系统产生的非严格 CSV。对确实需要兼容的输入，将 Reader.LazyQuotes 设置为 true，它会放宽部分引号规则；但它不是“修复 CSV”的开关，也不能证明读出的字段就是原本想表达的内容。

实用做法是：默认严格模式发现问题，兼容入口单独启用 LazyQuotes，然后用字段数、必填字段和原始数据留存做二次判断。正式导入不要无条件打开它。

先分清是哪一种引号错误

encoding/csv 默认按 RFC 4180 风格解析。字段如果以双引号开始，就需要正确结束；字段内部的双引号通常要写成两个连续的双引号。下面这类输入会让严格模式拒绝：

id,name,note
1,Alice,"设备在 9 点上线
2,Bob,ok

第一条记录的 note 没有闭合引号，换行也可能被当成多行字段的一部分。错误不一定出现在肉眼看到的那一行，尤其是 CSV 支持字段跨行时，应该先保留 *csv.ParseError 中的起始行、出错行和列号。

LazyQuotes 到底放宽了什么

官方定义中，LazyQuotes=true 允许两类情况：未加引号字段里出现引号，以及带引号字段里出现没有成对转义的引号。它的目标是读取现实世界中不够规范的文件，而不是替调用方判断引号本应属于哪个字段。

因此，以下代码适合放在“兼容导入”入口，而不是所有 CSV 读取的公共默认配置：

package main

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

func main() {
    input := "id,name,note\n1,Alice,设备说\"已上线\"\n2,Bob,ok\n"
    reader := csv.NewReader(strings.NewReader(input))
    // 只对已确认来自旧系统的宽松格式启用兼容读取。
    reader.LazyQuotes = true
    reader.FieldsPerRecord = -1

    for {
        record, err := reader.Read()
        if err == io.EOF {
            break
        }
        if err != nil {
            // 兼容模式仍可能失败，不能把错误静默成空记录。
            fmt.Printf("读取失败: %v\n", err)
            continue
        }
        fmt.Printf("%q\n", record)
    }
}

这里把 FieldsPerRecord 设为 -1，只是为了让示例专注于引号问题。真实导入若要求固定列数，应保留默认的首行推断或显式设置期望列数，否则字段错位可能被兼容模式掩盖。

兼容读取时要保留错误上下文

更稳妥的导入器会先用严格模式处理，并把解析错误包装成可定位的记录信息。ParseError.Column 是从 1 开始的字节列号，不是中文字符数；多行字段还要同时关注 StartLine 与 Line。

package main

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

func readStrict(input string) {
    reader := csv.NewReader(strings.NewReader(input))
    // 严格模式先暴露原始问题，便于决定是否进入兼容通道。
    for {
        record, err := reader.Read()
        if err == io.EOF {
            return
        }
        if err != nil {
            var parseErr *csv.ParseError
            if errors.As(err, &parseErr) {
                // 起始行和出错行一起保留，避免误判跨行字段。
                fmt.Printf("记录起始行=%d，出错行=%d，字节列=%d，原因=%v\n",
                    parseErr.StartLine, parseErr.Line, parseErr.Column, parseErr.Err)
                return
            }
            fmt.Printf("其他读取错误: %v\n", err)
            return
        }
        fmt.Printf("严格读取: %q\n", record)
    }
}

如果业务允许降级，可以把原始文件或原始记录片段交给一个明确标记为“兼容”的第二次读取，而不是在同一个循环里悄悄切换模式。这样后续才能统计哪些来源经常产生坏引号。

不要把 LazyQuotes 当成数据清洗

兼容模式读成功，只能说明解析器找到了一个可返回的字段切分方式。它不能回答下面三个问题：

• 引号是字段内容的一部分，还是导出程序误加的符号；
• 原本被引号保护的逗号是否仍然属于同一个字段；
• 跨行文本中的换行是否应该保留，还是文件已经发生了截断。

导入服务至少应在解析后检查列数和关键字段，并把“使用了兼容模式”写入处理记录。对金额、订单号、身份证明或其他不可逆业务数据，宁愿把记录转入修复队列，也不要把一个看似成功的字段错位写进主库。

什么时候应该打开，什么时候应该拒绝

常见问题

LazyQuotes 能修复未闭合的双引号吗？

不能把它理解成修复器。它放宽部分语法检查，让 Reader 尝试返回记录；如果输入已经造成字段边界不确定，仍需要业务规则或人工修复。

开启 LazyQuotes 后还会返回错误吗？

会。它只覆盖文档定义的两类宽松情况，字段数错误、非法分隔符、输入读取错误或更复杂的结构损坏仍可能失败。

为什么兼容读取后字段数量还要检查？

因为宽松模式解决的是“能否按某种方式解析”，不等于“解析结果符合业务模式”。固定列数和关键字段校验仍然是导入责任。

总结一下：把严格模式当作默认，把 LazyQuotes 当作来源明确、可追踪的兼容开关；先记录 ParseError，再决定是否降级，并始终把解析成功与数据正确分开判断。