os.readfile读大文件必然卡住或oom，因其一次性加载全部内容到内存；应改用os.open配合bufio.newreadersize等流式读取方式，按需分块处理。
os.ReadFile 读大文件卡住？别让它干这事
直接调用 os.ReadFile 读取几十 MB 以上文件，基本等于主动申请 OOM。它会一次性分配完整内存、拷贝全部内容，不仅慢，还可能让 GC 频繁停顿甚至崩溃。这不是“优化不够”，而是用错了函数。
真实需求从来不是“把整个文件装进内存”，而是“边读边处理”。比如解析日志行、计算 checksum、分块上传、流式转码——这些场景下，必须换掉 os.ReadFile。
- 小文件（≤10MB）且需全文操作：仍可用
os.ReadFile，简单可靠 - 大文件（>10MB）或流式处理：必须用
os.Open+ 缓冲读取器 - 配置类静态文件（如 YAML/JSON）：可配合内存缓存，但首次加载也得用流式读，避免启动卡死
bufio.NewReaderSize 缓冲大小怎么设才不白调
默认 4KB 缓冲在大文件顺序读时效率极低：系统调用太频繁，磁盘吞吐上不去。但盲目堆到 100MB 也没用——内核页缓存和 SSD 控制器早做了优化，再大只是浪费内存，还延迟错误暴露。
实操建议按存储介质和访问模式选：
- 本地 SSD：64KB–128KB（
bufio.NewReaderSize(f, 65536)）足够，兼顾吞吐与响应 - 机械盘或 NFS：256KB 起步，但不超过 1MB；太大反而加剧寻道抖动
- 内存映射（mmap）只适合只读+随机访问场景，且要手动处理截断、跨平台兼容性等坑，日常顺序读没必要上
scanner.Bytes() 为什么偷偷吃掉你所有内存
bufio.Scanner 看似方便，但 scanner.Bytes() 返回的是底层缓冲区的切片引用。如果你把它直接塞进 map、append 到全局 slice 或传给 goroutine 异步处理，整个缓冲区（默认 4MB）都会被 GC 持有，内存根本回收不掉。
常见错误写法：
scanner := bufio.NewScanner(file)
for scanner.Scan() {
line := scanner.Bytes() // ❌ 危险！
lines = append(lines, line) // 整个缓冲区被锁死
}
安全做法：
- 需要保存内容时，显式拷贝：
data := append([]byte(nil), line...) - 优先用
scanner.Text()（内部已做拷贝） - 处理完一批后手动清空局部切片：
buf = buf[:0]，帮助编译器识别可复用空间 - 超长行不可控？改用
bufio.Reader.ReadString('\n')，并检查返回 err 是否为bufio.ErrTooLong
缓存策略不是“全缓存”或“不缓存”，而是分层决策
对大文件谈“缓存”容易误导——真正该缓存的不是文件本体，而是它的**元信息**或**热点片段**。
例如：
- 文件 size / modtime / hash：用
sync.Map缓存，避免每次 stat 系统调用 - 头部几 KB（如 CSV 表头、JSON schema）：可短 TTL 缓存，后续请求跳过读取
- 固定偏移的二进制结构（如数据库索引头）：用 mmap 映射，但仅限只读且文件稳定
- 整文件缓存？只适用于极小概率访问、又极其高频读的小配置文件；大文件缓存=自建内存泄漏器
最易被忽略的一点：缓存失效逻辑必须覆盖文件删除、chmod、硬链接变更等边缘情况，否则缓存永远 stale。别依赖 mtime 做唯一判断——NFS 和某些容器挂载下 mtime 可能不更新。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
