直接用os.open读大文件再切片会oom，因需全载入内存；应流式偏移+定长截取，并用bufio确保行边界完整，再配合sync.pool复用缓冲区避免频繁分配。
为什么不能直接用 os.Open 读整个大文件再切片
因为内存会爆。一个 10GB 的日志文件，如果用 os.ReadFile 或 io.ReadAll 加载进内存，Go 程序大概率触发 OOM kill，尤其在容器或低配机器上。真正的切片必须是「流式偏移 + 定长截取」，不加载全文本。
关键不是“怎么分”，而是“怎么保证每片边界不撕裂行（或记录）”。比如按字节切 100MB 一片，但第 100MB 正好卡在某行中间，下游解析就失败。
- 用
os.Stat先拿到文件总大小，算出理论分片数（如每片 64MB） - 每个分片起始位置用
file.Seek(offset, io.SeekStart)定位 - 但真正读取时，从
offset开始，先跳过第一个不完整行（用bufio.NewReader+ReadBytes('\n')向前探测），再开始读有效内容 - 结束位置同理：读到接近目标长度时，停在下一个换行符后，避免截断
如何用 sync.Pool 复用缓冲区避免频繁分配
每个 goroutine 分别读一个分片，如果都用 make([]byte, 1 分配 1MB 缓冲区，100 个分片就是 100MB 额外堆压力，GC 压力陡增。而 <code>sync.Pool 能让缓冲区在 goroutine 退出后暂存复用。
注意：Pool 中对象不能含指针（或需确保生命周期可控），否则可能引发 GC 误回收。对纯字节缓冲区安全。
- 定义全局池：
var bufPool = sync.Pool{New: func() interface{} { return make([]byte, 0, 1 - 获取：
buf := bufPool.Get().([]byte)；使用前重置长度：buf = buf[:0] - 归还：
defer bufPool.Put(buf)（必须在 goroutine 结束前） - 别用
buf = append(buf, ...)后直接归还——可能超出初始 cap，导致下次 Get 到的 slice 实际长度非零
io.CopyN 和手动 Read 哪个更适合分片读取
io.CopyN 看起来省事，但它只保证拷贝指定字节数，不管语义边界。对日志、JSON 行、CSV 这类按行组织的数据，它会强行截断，下游无法解析。
必须自己控制读取节奏：用 bufio.Reader 的 ReadString('\n') 或 ReadBytes('\n') 逐行读，累计字节数，到达分片上限时停止，并把最后一行留给下一分片处理。
- 起始偏移处调用
r.Discard(1)跳过首个不完整行（如果 offset 不在行首） - 每次
ReadBytes后检查len(line)，加到当前分片计数器；超限时 break，不写入该行 - 把未写入的
line缓存为下一分片的开头数据（需跨 goroutine 传递，建议用 channel 或预分配 slice 段） - 别依赖
io.CopyN做业务切片，它只适合二进制块（如视频帧、加密块）等无结构数据
分发到 worker 时，chan []byte 和 chan *bytes.Buffer 性能差异在哪
传 []byte 更轻量，但要注意底层数组是否被多个 goroutine 同时访问。如果 worker 对数据做修改（比如解码、清洗），又没 copy 一份，就可能和下一个分片的读取产生 data race。
传 *bytes.Buffer 自带扩容逻辑，但每次 new 一次 buffer 就多一次堆分配；而且 Buffer.Bytes() 返回的是内部 slice，仍存在共享风险。
- 推荐方案：用
chan struct{ data []byte; offset int64 }，data 是 copy 后的独立副本（append([]byte{}, src...)） - 如果确定 worker 只读不写，且分片间无重叠，可用
chan []byte，但启动 worker 前必须用copy(dst, src)分离底层数组 - 绝对不要把从
bufPool拿来的[]byte直接塞进 channel —— 归还池后，worker 还在读，就是 use-after-free - channel buffer 大小设为 worker 数量，避免调度阻塞；别设成
1000这种大数，会吃光内存
utf8.RuneCountInString 或 bytes.IndexByte 而非 strings.Index，否则可能错判行尾。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
