csv.Reader需显式调用Read()或ReadAll()，不自动跳BOM或推断分隔符；写入时Write()/WriteAll()后必须Flush()，否则内容不落盘。
用 csv.Reader 读取 CSV 文件时，必须手动调用 Read() 或 ReadAll()
Go 的 encoding/csv 不提供“自动跳过 BOM”或“自动推断分隔符”的功能，所有行为都需显式控制。常见错误是直接对文件句柄创建 csv.Reader 后没调用读取方法，导致程序看似“卡住”或返回空结果。
-
Read()每次读一行，返回[]string；适合大文件流式处理，避免内存暴涨 -
ReadAll()一次性读完全部行，返回[][]string；适合小文件，但若 CSV 超过几十 MB 容易 OOM - 如果 CSV 第一行是表头，建议先用
Read()读一次获取headers，后续每行再用map[string]string映射字段 - 注意：默认分隔符是逗号
,，若用制表符或分号，必须显式设置Reader.Comma = '\t'或Reader.Comma = ';'
写入 CSV 时，csv.Writer 的 Write() 和 WriteAll() 行为差异明显
Write() 写单行（即一个 []string），WriteAll() 写多行（即 [][]string）。关键陷阱在于：两者都不自动换行或刷新缓冲区——你得自己调用 Flush()，否则内容可能滞留在内存里不落盘。
- 漏掉
Flush()是生产环境最常导致“文件为空”或“最后一行丢失”的原因 - 写入含换行符、逗号、双引号的字段时，
csv.Writer会自动加引号和转义，无需手动处理 - 若需 UTF-8 BOM（如 Excel 友好），得在写入前手动向
*os.File写入\uFEFF，csv.Writer本身不支持 - 性能敏感场景下，避免频繁调用
Write()+Flush()；应批量写入后统一Flush()
csv.Read() 报错 record on line X: wrong number of fields 怎么定位和修复
这个错误不是格式校验失败，而是某行字段数与首行（或上一次 Read() 成功时的字段数）不一致。根本原因通常是：字段内含未转义的换行符、逗号，或数据本身存在不规范的引号闭合。
- 用文本编辑器打开报错行附近，搜索
"看是否成对；不成对说明某字段引号缺失或多余 - 检查该行是否含真实换行（比如用户输入的地址字段），这类数据必须被双引号包裹，且内部换行符保留
- 临时绕过：设置
Reader.FieldsPerRecord = -1可禁用字段数校验，但后续逻辑需自行处理不齐整的数据 - 更健壮做法：用
Reader.TrailingComma = true允许末尾逗号，或预处理原始字节流（如用正则替换孤立换行）
处理中文、emoji 等 UTF-8 数据时，别忽略文件打开方式和终端显示
Go 原生字符串就是 UTF-8，encoding/csv 也完全兼容，真正出问题的地方往往在外部环节：
立即学习“go语言免费学习笔记（深入）”；
- 用
os.Open()打开文件没问题，但若从 HTTP body 或 bytes.Buffer 读取，确保源数据确实是 UTF-8 编码（而非 GBK） - Windows 上用记事本打开 CSV 显示乱码？大概率是没加 BOM，Excel 默认按 ANSI 解码；加 BOM 方法：
file, _ := os.Create("out.csv") file.Write([]byte("\uFEFF")) writer := csv.NewWriter(file) - 终端用
cat查看中文乱码？不是 Go 的问题，是终端 locale 设置（如LANG=C）导致，改用LANG=en_US.UTF-8或直接用less -r - emoji 在 CSV 中会被正常编码为 UTF-8 字节序列，只要读写两端都按 UTF-8 处理，不会损坏
Flush()。其它多数问题其实不在 encoding/csv 本身，而在数据源头是否干净、终端是否按 UTF-8 解释字节流。 
