应放弃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 <h3>写大文件为什么 w.Flush() 必须显式调用？</h3> <p><code>bufio.NewWriter</code> 是带缓冲的，不 <code>Flush()</code> 就关文件，数据大概率丢在用户态缓冲里没落盘——尤其在程序异常退出或 SIGKILL 场景下。</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill8096" title="Alibabacloud Sdk Client Initialization For Golang"><img src="https://img.php.cn/upload/skill/000/000/081/179186233233253.jpg" alt="Alibabacloud Sdk Client Initialization For Golang" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill8096" title="Alibabacloud Sdk Client Initialization For Golang" class="overflowclass">Alibabacloud Sdk Client Initialization For Golang</a> <p class="overflowclass">初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。</p> </div> <a rel="nofollow" href="/xiazai/skill8096" title="Alibabacloud Sdk Client Initialization For Golang" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div>
- 默认缓冲区仅 4KB，小缓冲导致 syscall 过多；设太大（如 100MB）又失去流控意义，且错误暴露延迟
- 推荐
bufio.NewWriterSize(f, 1（1MB），配合每批处理后 <code>w.Flush()，或在关键断点（如每百万条记录）强制刷盘 - 若需原子写入，先写临时文件再
os.Rename，避免写到一半崩溃留下脏数据
并发读同一个大文件反而更慢？
不是 goroutine 本身有问题，而是你在用错地方：对单个物理文件做 offset 分段并发读（比如 4 个 goroutine 各读 1/4），在 HDD/普通 SSD 上基本等于自找寻道开销。
- 磁盘 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 持续爬升。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
