csv.Reader 默认字段数不匹配时返回 ErrFieldCount 而非 panic，需设 FieldsPerRecord = -1 启用宽松模式，并配合 TrimLeadingSpace、正确处理换行符与 BOM 等细节保障健壮性。
csv.Reader 读取时字段数量不匹配就 panic？
默认情况下，csv.Reader 遇到某行字段数与首行（或预期）不一致，会直接返回 ErrFieldCount 错误——但很多人没意识到：它**不会自动跳过或补空**，而是让程序卡在那行。尤其处理用户上传的 CSV 时，常见“最后一行空、Excel 多导出一空行、手动删列漏删标题”等情况。
解决办法是启用宽松模式：reader.FieldsPerRecord = -1，此时每行独立解析，不会拿首行字段数去校验；再配合 reader.TrimLeadingSpace = true 去掉字段前导空格，避免因空格导致的看似“字段多一个”的假象。
- 别依赖
ReadAll()一次性读完——内存暴涨且错误定位难，改用循环Read() - 如果必须用
ReadAll()，务必用defer包裹csv.NewReader().ReadAll()并检查 error，否则 panic 会直接崩掉 goroutine - Windows 换行符
\r\n在 Linux 下可能被识别为额外字段，确保文件以 LF 结尾，或用strings.ReplaceAll(line, "\r\n", "\n")预处理
写 CSV 时中文乱码、Excel 打不开？
根本原因不是 Go 的问题，而是 Excel 默认只认 UTF-8 with BOM 编码。纯 UTF-8 写出的文件，Excel 会当 ANSI 解析，中文全变问号。
正确做法是在写入前手动加 BOM：file.Write([]byte("\xef\xbb\xbf"))，然后再调用 csv.Writer.WriteAll()。注意：BOM 必须写在最开头，且不能写在 header 之前又忘了换行——否则第一行表头会被 BOM “顶”偏。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不要用
os.Create()直接写，改用os.OpenFile(..., os.O_CREATE|os.O_WRONLY, 0644)，避免 Windows 下只读文件报错 - 写完必须调用
w.Flush()和w.Error()检查，否则缓冲区内容可能没真正落盘，文件看似生成了却为空 - 字段含逗号、换行符、双引号时，
csv.Writer会自动加引号和转义——但前提是字段字符串本身没提前被错误拼接过（比如手动加引号反而导致双重引号）
encoding/csv 不支持自定义分隔符？
支持，但得在创建 csv.Reader 或 csv.Writer 后立刻设置：reader.Comma = ';' 或 writer.Comma = '\t'（制表符）。注意：这个字段是 rune 类型，不能传字符串 ","，否则编译不过。
常见误区是以为设置后能自动识别文件里的分隔符——其实不能。CSV 格式本身没有元信息声明分隔符，你设成 ';'，就必须保证所有输入行都用分号分隔，否则解析结果错位。
- 若需兼容多种分隔符（如先猜再读），得自己按行扫描统计分隔符出现频次，再重建
csv.Reader - MySQL 导出的 CSV 常用
\t+ENCLOSED BY '"'，Go 里只需设Comma = '\t'，无需手动处理引号逻辑 - 设
Comma = 0是非法的，运行时报 panic: "invalid comma"，别试
大文件读写内存爆满、速度慢？
csv.Reader.ReadAll() 和 csv.Writer.WriteAll() 会把整份数据加载进内存。10 万行 × 10 列的 CSV，轻松吃掉 200MB+，GC 压力大，还容易 OOM。
真实场景该用流式处理：读用 for record, err := reader.Read(); err == nil; record, err = reader.Read()，写用 w.Write(record) 循环单行操作。这样内存占用基本恒定在几 KB。
- 别在循环里反复 new
csv.Reader——每次初始化都有小开销，复用同一个实例即可 - 读大文件时，
reader.BufferSize默认 4KB，遇到超长字段（如 base64 文本）会报ErrBareQuote，可提前设大点：reader.BufferSize = 1 （1MB） - 并发写多个 CSV？别共用一个
csv.Writer，它不是线程安全的——每个 goroutine 自己 new 一个，写完 close 对应 file
最麻烦的其实是编码探测和 BOM 处理混在一起时的边界情况：比如文件开头是 BOM + 空行 + 表头，这时候 Read() 第一次调用可能读到空切片，得手动跳过空记录。这种细节不踩一遍很难信。
