应避免 csv.newreader(f).readall()，改用 bufio.scanner 读行+bytes.indexbyte 手动分割为 []byte 切片，结合偏移索引结构体实现零字符串头开销；读写均需配 64kb 缓冲的 bufio.reader/writer。
别用 csv.NewReader(f).ReadAll()，它会把全部字段转成 []string，500 万行 × 10 列直接吃掉 800MB 字符串头内存——这不是 bug，是 Go 字符串结构决定的硬开销。
为什么 csv.Reader 默认吃内存
标准库 csv.Reader 每调一次 Read()，内部就为每个字段分配一个 string：16 字节 header（指针 + 长度）+ 底层字节拷贝。5000 万个字段 ≈ 800MB 仅 header 开销，再加原始数据和 slice 头，1.5GB+ 是合理下限。
-
ReadAll()会一次性把所有记录塞进[][]string，GC 压力陡增，缓存局部性差 - 即使你只取第 2 列，
csv.Reader仍会为整行 10 个字段都生成string - 底层
bufio.Reader缓冲区默认 4KB，小缓冲 + 引号跨 buffer 就导致解析失败，不是数据问题而是读取姿势不对
用 [][]byte 替代 []string，零字符串头开销
不创建新 string，复用原始字节切片，只存 [][]byte 或偏移索引。关键在生命周期控制：整行数据必须保留在内存中，直到所有字段引用结束。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 用
bufio.Scanner读行：scanner.Bytes()返回当前行的[]byte引用，避免拷贝 - 手动分割：用
bytes.IndexByte(line, ',')找分隔符，记录[start, end]而非调line[i:j] - 定义结构体如
type Row { Key [22]byte Offsets [10][2]int }，500 万行元数据仅 ~270MB - 真正需要字符串时再调
string(data[r.Offsets[i][0]:r.Offsets[i][1]])—— Go 1.22+ 对这种切片已优化为零分配
流式处理必须配 bufio.Reader/Writer
直接传 *os.File 给 csv.NewReader 或 csv.NewWriter，等于裸 syscall，GB 文件可能慢几倍；不配缓冲，BOM、换行符、引号嵌套全会出错。
- 读取时：用
bufio.NewReaderSize(f, 64*1024)，64KB 缓冲能覆盖大多数长行和跨 buffer 引号 - 写入时：用
bufio.NewWriterSize(f, 1（1MB），每写 1000 行调一次 <code>w.Flush()，别等 defer - 遇到 BOM：
bytes.HasPrefix(data, []byte{0xEF, 0xBB, 0xBF})手动跳过前 3 字节，csv.Reader不自动处理 - 字段数不固定：设
reader.FieldsPerRecord = -1，否则某行多逗号就 panic 报record on line X: wrong number of fields
最易被忽略的是：你改了缓冲区大小、关了字段校验、用了 [][]byte，但如果底层还用 strings.Split 或 csv.Reader.Read()，就白忙——所有这些优化的前提，是彻底绕过标准库字段转 string 的逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
