csv.newreader读空通常因文件指针偏移或utf-8 bom未处理，应先file.seek(0,0)，再用bytes.trimprefix跳过bom；gbk/gb18030需先转码；大文件须流式read避免readall；表头需人工确认并预处理；字段解析需手动类型转换与容错。
csv.NewReader 读出来是空的？先检查文件指针和 BOM
最常见的情况不是代码写错了，而是 csv.NewReader 拿到的文件流已经“没内容可读”了——比如你之前调过 file.Stat() 或 io.ReadAll(file)，悄悄移动了文件指针；或者文件开头有 UTF-8 BOM（\xEF\xBB\xBF），被当成非法字符直接卡住。
- 打开文件后、创建
reader前，加一句file.Seek(0, 0)确保从头开始读 - 检测并跳过 BOM：用
bytes.TrimPrefix处理原始字节，再包进io.MultiReader，别用strings.ReplaceAll——BOM 只该在开头，且不能靠字符串操作删 - GBK/GB18030 编码的 CSV 必须先转码：用
golang.org/x/text/encoding/charmap.GB18030.NewDecoder()包一层io.Reader，再传给csv.NewReader
ReadAll 还是 Read？看文件大小和后续处理方式
ReadAll 看起来方便，但会把整个文件加载进内存，100MB 的 CSV 往往吃掉 400MB+ 内存（字符串重复分配 + slice 扩容）。它只适合小文件（
- 大文件（>10MB）一律用
for { record, err := reader.Read() }流式处理 - 每行处理完立刻入库、校验或丢弃，别 accumulate 到一个大
[][]string里 - 需要定位错误行号？用
reader.InputOffset()估算位置（注意不是绝对行号，但比没有强） - 超长行性能差？显式设置
bufio.NewReaderSize(file, 64*1024)避免默认 4KB buffer 频繁 realloc
表头怎么处理？别一上来就 reader.Read() 吃掉第一行
很多人发现“第一行数据没了”，就是因为误把表头当数据、又把数据当表头。CSV 有没有表头得看源文件，不是靠约定。
- 先用
head -n 1 data.csv或文本编辑器确认第一行是不是"name","age","email"这种字段名 - 有表头：调一次
header, _ := reader.Read()，之后每行用map[string]string或索引映射绑定字段 - 无表头：直接进循环，别多读那一次——否则所有数据下移一行
- 表头带空格？用
strings.TrimSpace预处理，否则row[colIndex["name "]]会 panic
解析成结构体时，类型转换和缺失字段必须手动兜底
encoding/csv 不做任何类型转换，也不支持 struct tag（如 csv:"name"）。你拿到的全是 []string，字段缺失、格式错、空字符串都得自己判断。
- 数字字段：用
strconv.Atoi或strconv.ParseFloat，检查返回的err，别忽略 - 时间字段：先用
time.Parse("2006-01-02", s)，格式字符串必须和 CSV 中实际字符串完全一致 - 字段数不匹配？用
len(record) 判断，补默认值 or 跳过，别硬取 <code>record[2] - 关键字段为空？记录日志并带上下文（文件名、行号、原始值），别让程序静默失败
真正麻烦的从来不是读取本身，而是字段语义模糊、上游导出不规范、日期格式五花八门——这些没法靠库自动解决，得在 reader.Read() 后那一小段业务逻辑里一个个对齐。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
