csv.Reader 读取时第一行被跳过，是因为误在循环前调用一次 Read() 想跳表头，却吃掉了首行数据；正确做法是先确认 CSV 是否真有表头，再决定是否丢弃。
csv.Reader 读取时为啥第一行数据总被跳过？
因为 csv.NewReader 本身不跳行，但很多人在调用 reader.Read() 前手动调了一次 reader.Read() 想“跳过表头”，结果误把第一行有效数据吃掉了。
正确做法是：只在明确需要忽略表头时才读一次，且要确认是否真有表头。没有表头的 CSV 被跳掉首行，数据就全偏移了。
- 检查源文件：用
head -n 1 data.csv看第一行是不是字段名 - 有表头 → 读一次丢弃：
_, _ = reader.Read() - 无表头 → 别动，直接进循环处理
- 更安全的方式：用
csv.Read()的返回值判断是否 EOF，而不是靠“读几次”来控制逻辑
中文字段名或含逗号的单元格解析失败
根本原因是 CSV 格式规范要求：含逗号、换行、双引号的字段必须用双引号包裹，且内部双引号要转义为两个双引号。Go 的 csv.Reader 严格遵循 RFC 4180，不自动修复脏数据。
常见错误现象：record []string has 2 fields, expected 5 或解析出空字段。
立即学习“go语言免费学习笔记（深入）”；
- 先用文本编辑器打开 CSV，确认中文字段是否被双引号包围（例如
"姓名","城市","备注"） - 如果字段含逗号但没引号（如
张三,北京,爱喝茶），csv.Reader会拆成 3 列，而非 1 列 —— 这不是 bug，是标准行为 - 预处理建议：用
strings.ReplaceAll补引号风险极高，优先让上游导出时选“带引号”选项；若必须处理，用正则 + 状态机识别字段边界，别硬切
大文件（>100MB）读取卡死或内存暴涨
csv.Reader 是流式读取，本身不缓存整文件，但如果你把每行 []string 都 append 到一个大 slice 里，内存就爆了。
性能瓶颈往往不在解析，而在后续处理方式。
- 避免一次性
readAll := make([][]string, 0); for { record, _ := r.Read(); readAll = append(readAll, record) } - 改成边读边处理：入库就调
db.Exec，校验就立刻validate(record)，失败则记录错误行号（用reader.InputOffset()可估算位置） - 注意
bufio.NewReader的 buffer 大小默认 4KB，对超长行可能触发多次 alloc；大文件建议显式设置：bufio.NewReaderSize(file, 64*1024)
time.Time 字段解析报错：parsing time “2024-03-15” as “2006-01-02 15:04:05”
CSV 里的日期只是字符串，csv.Reader 不做类型转换。你得自己用 time.Parse 转，而错误通常是因为格式字符串和实际字符串不匹配。
最容易被忽略的是：不同地区导出的日期格式差异极大（2024/03/15、15/03/2024、2024-03-15T08:30:00Z）。
- 不要写死一个
time.Parse("2006-01-02", s)就完事 - 先尝试最可能的格式，失败再试下一个，用
errors.Is(err, time.ErrParse)判断 - 更稳妥：统一要求上游用 ISO 8601（
2006-01-02T15:04:05Z），或导入前用脚本标准化日期列 - 注意时区：
time.Parse默认解析为本地时区，time.ParseInLocation才能指定
CSV 解析真正的复杂点从来不在读取动作本身，而在你如何定义“这一行算解析成功”——字段缺失怎么填、空字符串算不算有效值、数字列混入字母要不要报错、错误行是跳过还是中断整个流程。这些决策比选哪个库重要得多。
