应放弃bufio.Scanner处理超长行、需精确控制缓冲或非换行分隔场景，改用bufio.NewReader+手动Read；写大文件必须显式Flush()以防数据丢失，推荐1MB缓冲并按批刷盘。
别用 os.ReadFile 和 os.WriteFile 处理大文件——它们会把整块内容塞进内存，OOM 风险高、延迟不可控、无法流式处理。
什么时候该放弃 bufio.Scanner？
当你遇到超长行（比如单行几百 MB 的日志或导出数据）、scanner.Buffer 默认大小不够、或需要精确控制缓冲区生命周期时，bufio.Scanner 就会 panic 或 silently fail。
- 默认缓冲上限是 64KB，超长行直接报
scanner: token too long -
scanner.Bytes()返回的是底层缓冲切片，若存入 map/slice，整块缓冲区被隐式引用，GC 不回收 - 真正需要逐段读取（非换行分隔）时，比如解析二进制帧、固定长度记录，
bufio.Scanner反而多了一层无用逻辑
换成 bufio.NewReader + 手动 Read 或 ReadFull 更可控：
reader := bufio.NewReaderSize(file, 1<<20) // 1MB 缓冲
buf := make([]byte, 4096)
for {
n, err := reader.Read(buf)
if err == io.EOF {
break
}
process(buf[:n])
}
写大文件为什么 w.Flush() 必须显式调用？
bufio.NewWriter 是带缓冲的，不 Flush() 就关文件，数据大概率丢在用户态缓冲里没落盘——尤其在程序异常退出或 SIGKILL 场景下。
- 默认缓冲区仅 4KB，小缓冲导致 syscall 过多；设太大（如 100MB）又失去流控意义，且错误暴露延迟
- 推荐
bufio.NewWriterSize(f, 1<<20)（1MB），配合每批处理后w.Flush()，或在关键断点（如每百万条记录）强制刷盘 - 若需原子写入，先写临时文件再
os.Rename，避免写到一半崩溃留下脏数据
并发读同一个大文件反而更慢？
不是 goroutine 本身有问题，而是你在用错地方：对单个物理文件做 offset 分段并发读（比如 4 个 goroutine 各读 1/4），在 HDD/普通 SSD 上基本等于自找寻道开销。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 磁盘 I/O 是瓶颈，不是 CPU；goroutine 不能让硬盘转得更快
- 真正该并发的是「读完之后的处理」：一个 goroutine 负责
Read，多个 goroutine 从 channel 拿数据块做解析、校验、编码 - 若真要多路读，改用
file.ReadAt(buf, offset)避免共享file.offset锁，但前提是文件支持随机访问且你已预知偏移边界
内存一直不下降？检查 []byte 引用是否泄漏
Go 的 GC 不主动归还内存给 OS，尤其当大 []byte 被长期变量间接持有时，整块底层数组会被钉住。
- 常见陷阱：
scanner.Bytes()直接 append 到 slice、string(b)后再切分、闭包捕获了整个 reader - 安全做法：需要持久化某段内容时，用
append([]byte(nil), b[start:end]...)显式拷贝 - 高频复用缓冲区时，用
sync.Pool管理[]byte，避免反复分配
最易忽略的一点：哪怕你用了 bufio 和 sync.Pool，只要某处把 scanner.Bytes() 存进了全局 map，那一整块缓冲区就永远活不过 GC——这种泄漏不会报错，只会让 RSS 持续爬升。
