csv.NewReader 读取时可能因末行无换行符而丢数据；写 CSV 时需手动添加 UTF-8 BOM（\xEF\xBB\xBF）以兼容 Excel；字段含特殊字符时保持默认 QuoteMode 即可；处理大文件应流式逐行读写，避免全量加载。
csv.NewReader 读取时卡住或丢数据？检查底层 io.Reader 是否完整
Go 的 csv.NewReader 不会自己判断流是否结束，它只按行解析，遇到换行符就切分。如果最后一行没换行符，Read() 可能返回 io.EOF 但不吐出那行数据——这是最常被忽略的“丢数据”原因。
常见错误现象：csv.Reader.Read() 返回 io.EOF，但最后一行内容没拿到；文件明明有 100 行，只读到 99 行。
- 确保输入源（比如
*os.File或bytes.Reader）可完整读取，且末尾有换行符（Unix 风格） - 不要依赖
err == io.EOF作为“处理完成”的唯一信号；每次Read()成功后，先处理当前行，再检查 err - 若来源是网络响应或管道，需确认对方已关闭写端，否则可能永久阻塞
写 CSV 时中文乱码或 Excel 打不开？必须手动加 BOM 头
Windows 上 Excel 默认用 ANSI（其实是 GBK/GB2312）打开无 BOM 的 UTF-8 文件，结果就是中文全变方块。Go 的 csv.Writer 输出纯 UTF-8，不带 BOM，这是标准行为，但和 Excel 不兼容。
使用场景：导出报表给运营、财务等非技术同事，他们双击用 Excel 打开。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在调用
w.Write()前，先向底层io.Writer写入 UTF-8 BOM：\xEF\xBB\xBF - 不要用
strings.NewReader包裹带 BOM 的字符串再传给csv.NewReader——BOM 会被当成第一列内容 - 如果目标是跨平台兼容（macOS Numbers、LibreOffice），BOM 不是必须，但加了也没坏处
字段含逗号、换行或引号时 panic？默认 QuoteMode 就够用，别乱改
csv.Writer 默认用 csv.QuotationForce 模式，只要字段含逗号、双引号或换行符，就会自动加双引号并转义。很多人看到文档里有 QuoteNone 或 QuoteAll 就想试试，结果导出的 CSV 被 Excel 解析错位。
性能影响：强制引号会略微增加输出长度和内存拷贝，但对普通业务量（万行以内）几乎无感。
- 保持默认即可，不用显式设置
w.Comma或w.UseFieldsPerRecord - 如果字段本身含双引号，Writer 会自动变成
"abc""def"格式，这是 RFC 4180 标准，Excel 完全支持 - 避免手动拼接 CSV 字符串——引号转义逻辑比看起来复杂得多，容易漏掉换行符处理
大文件读写内存暴涨？用 streaming + 按批处理代替全量加载
csv.NewReader 本身不缓存整文件，但如果你把每行 []string 全塞进一个 [][]string 切片，那就是典型的 O(n²) 内存占用。10 万行 × 20 列，轻松吃掉几百 MB。
真实场景：ETL 导入、日志清洗、定时批量同步。
- 用 for 循环 + 单次
r.Read()，处理完一行就丢弃引用（尤其注意别闭包捕获整行） - 需要聚合统计？用 map 或 struct 累加，别存原始行
- 写大文件时，避免反复调用
w.Flush()；但也不要完全不 flush——超大文件下，缓冲区满会导致 goroutine 阻塞
真正难的不是语法，是记住：CSV 是流协议，不是数据结构。你手里拿的永远是一行、一行、又一行，而不是“整个表格”。
