csv.reader 默认字段数不一致返回errfieldcount而非panic，但忽略错误会导致后续panic；容忍波动需设fieldsperrecord=-1；csv.encoder不处理编码，中文需手动转码或加utf-8 bom；readall易oom，应改用循环read；自定义分隔符等配置须在首次读写前设置。
csv.Reader 读取时字段数量不一致直接 panic？
默认情况下 csv.Reader 遇到某行字段数和首行（或预期）不一致，会返回 ErrFieldCount 错误，但如果你没检查错误就继续调用 Read()，下一次读可能 panic —— 因为内部状态已损坏。这不是 bug，是设计使然：它假设你重视结构一致性。
常见错误现象：panic: reflect: call of reflect.Value.Interface on zero Value，往往出现在用 csv.NewReader().Read() 后直接赋值给结构体字段，却忽略了前一次读取已出错。
- 务必每次调用
Read()后检查返回的error，别只在循环结束时 check - 若需容忍字段数波动（如日志 CSV），提前调用
reader.FieldsPerRecord = -1，此时每行返回原始切片，自行处理长度 - 注意：设为
-1后，reader.Read()不再校验字段数，但reader.ReadAll()仍会校验并失败——别混用
用 csv.Encoder 写结构体时中文乱码或报错
csv.Encoder 本身不处理编码，它只写 []byte。如果你传入含中文的 string，而输出目标（如文件、HTTP 响应）底层是 UTF-8，则没问题；但若写入 Windows 记事本默认打开的 ANSI 文件（如 GBK），就会显示乱码——这不是 Go 的问题，是终端/编辑器编码匹配问题。
使用场景：导出报表供运营下载，用户双击用记事本打开。
立即学习“go语言免费学习笔记（深入）”；
- 最简单解法：写入前用
golang.org/x/text/encoding/simplifiedchinese.GBK.NewEncoder().Bytes()转码（需引入 x/text） - 更推荐做法：坚持 UTF-8 + BOM 头，用
io.WriteString(w, "\xEF\xBB\xBF")开头，多数新版 Excel 和记事本能自动识别 - 别用
fmt.Fprint替代encoder.Write()，后者会自动转义逗号、换行、引号；前者不会，极易破坏 CSV 格式
ReadAll() 内存暴涨甚至 OOM？
csv.NewReader(r).ReadAll() 会把整个 CSV 加载进内存，字段全转成 string。10MB 的 CSV，实际内存占用常达 30–50MB（Go 字符串 header + 底层字节拷贝）。对日志分析、ETL 等场景，很容易触发 GC 压力或直接 OOM。
性能影响：ReadAll 没法流式处理，无法 early-return；也无法复用底层 buffer。
- 替代方案：用
for record, err := reader.Read(); err == nil; record, err = reader.Read()循环处理 - 想复用 record 切片？可以，但必须在循环内
append([]string(nil), record...)拷贝，否则所有迭代共用同一底层数组 - 如果真要 ReadAll，先用
bufio.NewReaderSize(f, 64*1024)包一层，减少系统调用次数，但不解决内存峰值问题
自定义分隔符、注释符、引用符时容易漏掉什么？
csv.Reader 和 csv.Writer 都允许通过字段设置分隔符（Comma）、注释前缀（Comment）、是否需要引号（UseCRLF）等，但有三个隐性约束常被忽略：
-
Comma必须是 ASCII 可见字符，不能是\t或\0；想用 tab 分隔，请用tsv逻辑或手动 split -
Comment默认禁用（0），设为'#'后，整行以#开头即跳过；但它**不支持行内注释**，a,b,#comment仍会被解析为 3 字段 -
Quote默认是"，若设为0（禁用引号），则遇到字段含Comma或换行时，Write()会 panic：字段内容必须自己保证不含分隔符——这在真实数据里几乎不可能
复杂点在于：这些配置必须在第一次调用 Read() 或 Write() 前设置，之后修改无效。没人告诉你，但改了真没用。
