bufio.Scanner内存不爆但易panic，因其默认64KB单行缓冲上限，超长行触发bufio.ErrTooLong而非错误返回，需显式调用scanner.Buffer()设限并检查scanner.Err()。
bufio.Scanner 分行读取时为什么内存不爆，但容易 panic？
因为 bufio.Scanner 默认只维护一个内部缓冲区（64KB），按需扩容、逐行切分，不会把整个文件加载进内存。但它对单行长度敏感：一旦某行超过默认最大 token 大小（65536 字节），scanner.Scan() 就直接返回 false，且 scanner.Err() 会是 bufio.ErrTooLong —— 这个错误常被忽略，导致后续逻辑用空字符串或未初始化数据处理，最终 panic 或结果错乱。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 务必调用
scanner.Buffer()显式设上限，比如scanner.Buffer(make([]byte, 64*1024), 10*1024*1024)（首参初始缓冲，次参最大允许单行） - 每次
scanner.Scan()后，立刻检查scanner.Err()，不只判断err != nil，还要区分io.EOF和真实错误 -
scanner.Text()返回的是当前缓冲区内的拷贝，安全；但别用scanner.Bytes()后长期持有指针，它可能被下一次扫描覆盖
手动 Read() 分块时，buf 大小设多少才合理？
块大小不是越大越好，也不是越小越稳。太小（如 4KB）会导致系统调用频繁、CPU 花在 syscall 上过多；太大（如 128MB）则浪费内存、增加 GC 压力，且最后一块可能远小于该值，造成吞吐不均。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 文本类文件（日志、CSV）推荐 1–4MB；二进制或协议解析类（如自定义帧头）可放宽到 4–8MB
- 用
make([]byte, 4*1024*1024)预分配，复用同一底层数组，避免每次 new 分配 -
file.Read(buf)返回的n才是真实读取字节数，必须用buf[:n]处理，不能直接传buf - 遇到
io.EOF是正常结束信号，不是错误；其他err != nil（如syscall.EINTR）需重试或记录
并发读多个大文件时，goroutine 数量怎么控？
无限制起 goroutine 不等于高效。每个 goroutine 占用约 2KB 栈空间，上万 goroutine 光栈就吃掉 20MB+；更关键的是，大量并发读会挤占内核文件描述符、触发磁盘 I/O 竞争，吞吐反而下降。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用带缓冲 channel 当信号量，例如
sem := make(chan struct{}, 16)，每启动一个读 goroutine 前先sem ，结束后 <code> - 若目标是 S3 或网络存储，严格按服务商限流设并发数（AWS S3 建议 ≤20）
- 本地磁盘场景，优先测出瓶颈：用
iostat -x 1观察 %util 和 await，若 %util 接近 100%，说明磁盘已饱和，再增并发无意义 - 每个 goroutine 必须持有独立的
*os.File和缓冲区，禁止共享bufio.Scanner或bufio.Reader
读写分离 pipeline 中，channel 缓冲区设多大？
channel 缓冲区本质是内存暂存区。设太小（如 chan []byte 不带缓冲），读 goroutine 容易阻塞在发送端；设太大（如 make(chan []byte, 1000)），未消费的数据堆积在内存里，失去流式处理意义，甚至 OOM。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 缓冲大小 = 预估单次处理耗时 × 期望吞吐率 ÷ 平均块大小。简单起见，文本处理常用
make(chan []byte, 8)~make(chan []byte, 32) - 发送前必须复制数据：
ch ，否则所有 worker 共享同一底层数组，内容互相覆盖 - 写入端用
bufio.NewWriterSize(file, 1024*1024)包装，批量刷盘，减少 write() 系统调用次数 - 务必用
sync.WaitGroup控制读 goroutine 全部退出后再close(ch)，否则 worker 可能漏数据或 panic
实际最易被忽略的一点：错误路径里的资源释放。比如 b.GetReader() 失败时没检查 err 就直接传给 buf.ReadFrom()，或者 os.Open() 出错后忘了 return，导致后续 defer 的 file.Close() 对 nil 操作 panic。所有 I/O 调用后，第一件事不是处理数据，而是检查错误。
