csv.Reader默认只识别逗号，用Tab等分隔符需显式设置r.Comma='\t'（rune类型），并注意BOM、换行符及字段前后空白处理，ReadAll()不报行号错误，建议手动循环读取调试。
csv.Reader 默认只认逗号，想用 Tab 或其他分隔符必须自己改 Comma
Go 标准库的 csv.Reader 不是“自动识别分隔符”的工具，它默认把 , 当成分隔符，不会猜你文件里其实是 \t 或 |。不显式设置，读 Tab 分隔的 CSV 会直接把整行当一个字段，Read() 返回的切片长度永远是 1。
实操建议：
- 创建
csv.Reader后，**立刻**给它的Comma字段赋值，比如r.Comma = '\t' - 注意：这个字段是
rune类型，不是string，别写成r.Comma = "\t"（编译不过） - 如果分隔符是 Unicode 字符（如中文顿号、全角逗号），同样用
rune表示，例如r.Comma = '、'
用 tab 分隔时，TrimLeadingSpace 很容易误关导致解析失败
Tab 分隔的文件常被 Excel 或 shell 工具导出，字段前后可能有空格或制表符。标准库默认开启 TrimLeadingSpace = true，但它只处理 ASCII 空格（' '），对 '\t' **完全无效**——所以即使你设了 r.Comma = '\t'，字段开头的 Tab 还是会被当成数据的一部分，导致字段错位。
实操建议：
- 如果源文件字段前后有 Tab，别依赖
TrimLeadingSpace，手动用strings.TrimSpace或strings.Trim处理每列 - 若确定字段绝对干净，可以关掉它：
r.TrimLeadingSpace = false，避免误解为“已处理空白” - 注意：关闭后，开头空格也会保留，不是“更安全”，只是行为更明确
自定义分隔符下，ReadAll() 和逐行 Read() 行为一致，但错误位置难定位
ReadAll() 本质就是循环调 Read()，分隔符设置对两者都生效。但问题在于：一旦某行格式异常（比如少了一个 Tab），ReadAll() 直接返回 error，且错误信息里**不带行号**，只报 unexpected end of CSV input 或 parse error on line 0（行号永远是 0）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
- 调试阶段优先用
for record, err := r.Read(); err == nil; record, err = r.Read()手动循环，出错时能用计数器知道卡在哪一行 - 生产环境若坚持用
ReadAll()，记得在os.Open后包装一层带行号追踪的io.Reader（比如用bufio.Scanner按行读再喂给csv.Reader） - 别指望
csv.Reader.FieldsPerRecord能帮你校验——它只在首行有效，后续行不匹配也不会提前报错
Windows 下 BOM 和换行符会让 Tab 分隔 CSV 解析偏移
用 Excel 保存的 Tab 分隔文件，常带 UTF-8 BOM（\xef\xbb\xbf）和 \r\n 换行。BOM 会被当作文本开头内容，导致第一列字段多出三个字节；而 csv.Reader 对 \r\n 的处理没问题，但如果你用 bytes.Split 或正则预处理，就可能把 \r 当成脏字符切进字段里。
实操建议：
- 打开文件后，先用
bytes.TrimPrefix(data, []byte("\xef\xbb\xbf"))去 BOM，或者用golang.org/x/text/encoding/unicode包解码 - 别自己写逻辑跳过
\r，标准库的csv.Reader内部已兼容\r\n，只要确保传进去的是原始字节流（不是被strings.ReplaceAll过的） - 如果文件由用户上传，且不确定编码，优先用
chardet类库检测，别硬设UTF-8
实际用下来，最麻烦的从来不是设 Comma 这一行代码，而是分隔符变更后，所有隐式依赖“逗号语义”的地方——比如字段校验正则、前端展示的列宽计算、甚至日志里的字段索引——都会悄悄错位。得盯着每一处 raw record 的长度和内容。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
