csv.reader 读取时丢第一行或卡住，主因是未处理 utf-8 bom、空行及注释行，且未主动跳过表头；正确做法是用 bufio.scanner 预处理过滤并 trim bom。
csv.Reader 读取时为什么总丢第一行或卡住？
因为 csv.Reader 默认不自动跳过 BOM，也不处理带空行/注释的 CSV；更关键的是，很多人忘了调用 reader.Read() 前先检查是否有 header 行要跳过——它不会自己猜你是不是想跳过表头。
- 如果文件以 UTF-8 BOM（
\xEF\xBB\xBF）开头，直接传os.File给csv.NewReader()会导致首字段读成"\ufeffname"，后续字段全偏移 - 真实清洗场景中，CSV 常混着空行、Excel 导出的杂项行（如“汇总：123 条”），
csv.Reader遇到空行会返回nil, io.EOF或直接 panic，不是跳过 - 正确做法是包装一层
bufio.Scanner预处理：过滤空行、trim BOM、跳过非数据行
示例处理逻辑：
scanner := bufio.NewScanner(file)
scanner.Scan() // 跳过 BOM（若存在）
for scanner.Scan() {
line := bytes.TrimSpace(scanner.Bytes())
if len(line) == 0 || bytes.HasPrefix(line, []byte("#")) {
continue
}
// 再交给 csv.Reader 处理这一行
}
流式清洗必须用 csv.Writer.Write() 还是 WriteAll()？
用 Write()。 WriteAll() 是把整个切片一次性写入缓冲区，违背“流式”本意——它会在内存里攒满所有记录才 flush，遇到百万行 CSV 直接 OOM。
-
WriteAll()适合已加载进内存的小数据集，比如配置导出；清洗工具面对的是未知大小的输入，必须逐行Write()+Flush() - 注意
csv.Writer的缓冲区默认 4KB，大字段（如 base64 图片字段）可能触发隐式 flush，导致部分行写半截就落盘——建议显式w.Flush()在每行后 - 如果清洗过程有字段校验失败，别用
panic或直接 return，应记录错误行号到单独 error log 文件，保持主流程不断
如何安全处理含逗号、换行、引号的 CSV 字段？
csv.Writer 默认能处理，但前提是你的原始字符串没被二次转义。常见翻车点是：从 JSON 解析后直接塞进 CSV，而 JSON 字符串里的 " 已被转义为 \"，再经 csv.Writer 处理就会变成 "" 嵌套，Excel 打开直接错列。
立即学习“go语言免费学习笔记（深入）”；
- 确认输入数据是“干净”的 Go 字符串，不是 JSON raw string；必要时用
strings.Unquote()清洗 - 字段含换行符（
\n）本身合法，csv.Writer会自动加双引号包裹，但你要确保底层 writer（如os.File）没被设成 text mode（Go 没这概念，但 Windows 下用os.O_TEXT会乱码） - 避免手动拼接 CSV 行字符串——哪怕只是一次
fmt.Sprintf(`"%s",%d`, s, n)，遇上字段含"或\n就崩
清洗时字段类型转换失败怎么定位和恢复？
别依赖 strconv.Atoi 这类函数裸奔。CSV 字段值是字符串，类型转换失败时错误信息极简（如 "strconv.Atoi: parsing \"N/A\": invalid syntax"），没有上下文——你根本不知道是第几行、哪个字段、原始值是什么。
- 封装转换函数，统一接收
row []string、colIndex int、rowNum int，失败时返回带位置信息的 error - 对关键数值字段（如金额、ID），清洗阶段不强行 abort，而是设为零值或
sql.NullInt64类型，并记日志：WARN: row 127, col 3 ("price") invalid: "—" - 避免在循环里用
defer关闭文件或 log，容易因 panic 导致日志丢失；错误日志用log.SetOutput()单独指向 error.log
流式清洗真正的难点不在读写，而在错误可追溯性——你永远不知道下一行是不是藏着一个 Unicode 零宽空格，或者 Excel 自作聪明插入的不可见分隔符。留好原始行号、原始字节快照、错误分类标记，比写对一百行业务逻辑都重要。
