os.readfile适合小文件（≤10mb）场景，如读取配置文件、写入临时token；不能用于日志或配置热加载，因其一次性全量加载内存、不支持追加写和权限精细控制，易引发oom或fd耗尽。
小文件（≤10MB）用 os.ReadFile 最省心；大文件或需逐行/流式处理时，bufio.Reader 配合显式缓冲区（如 64KB）才是吞吐和内存的平衡点——选错方式不是慢一点，是直接 OOM 或 fd 耗尽。
os.ReadFile 适合什么场景？为什么不能用于日志或配置热加载？
os.ReadFile 是 Go 1.16+ 的标准推荐，但它内部会一次性 make([]byte, size)。这意味着：
- 读 100MB 文件 → 分配 100MB 内存，GC 压力陡增，可能触发 STW
- 并发读 50 个 20MB 文件 → 瞬间 1GB 内存占用，runtime 不会立刻回收
- 它只支持
os.O_RDONLY，无法指定 flag 或 perm，追加写、权限控制等需求直接不满足 - 配置热加载若用它轮询读取，每次都是全量加载 + GC，比用
os.Stat判断 mtime + 差量解析更重
bufio.Reader 为什么必须显式设缓冲区大小？默认值有多坑？
bufio.NewReader 默认缓冲区是 4096 字节（defaultBufSize），对大文件或高频小读就是性能杀手：
- 读 1GB 日志时，默认 buffer 每次只填 4KB，系统调用次数翻 250 倍以上
- 用
scanner.Text()时，超长行（>64KB）直接返回scanner.ErrTooLong，而你可能根本没意识到行长限制存在 - 正确做法是：
bufio.NewReaderSize(f, 64*1024)，或根据典型行长/吞吐目标设为 32KB～128KB - 若需保留换行符，别用
scanner.Text()，改用scanner.Bytes()或reader.ReadBytes('\n')
os.OpenFile 的 flag 和 perm 参数配错会导致什么静默失败？
os.OpenFile 是读写控制的“开关面板”，flag 和 perm 错一个，行为就不可控：
-
os.O_RDONLY下调file.WriteString→ 返回bad file descriptor错误，但不会 panic，容易被忽略 -
os.O_CREATE | os.O_WRONLY | os.O_APPEND漏掉os.O_CREATE→ 文件不存在时直接报no such file or directory，而非自动创建 -
perm（如0644）只在文件**新建时生效**，已存在文件 chmod 不变；Windows 会截断高位权限，0777实际无效 - 写完不调
file.Sync()→ 断电或 crash 时数据可能仅在 page cache，未落盘
bufio.Writer 的 Flush 和 Sync 容易混淆的点在哪？
bufio.Writer 的缓冲和操作系统级刷盘是两层事，混用会丢数据：
-
w.Flush()只把 writer 缓冲区内容刷到*os.File，不保证磁盘写入；file.Sync()才真正落盘 - 写日志时：用
os.OpenFile(..., os.O_APPEND|...)+bufio.NewWriterSize(f, 64*1024)，批量写后w.Flush()即可，不必每条都Sync - 写关键配置时：先
w.Flush()，再f.Sync()，否则 rename 原子写失败（os.WriteFile内部已做） - defer
f.Close()不会自动Flush，必须显式调用，否则缓冲区内容丢失
真正卡住性能的往往不是算法，而是缓冲区大小、fd 生命周期、sync 时机这些细节——它们不报错，只悄悄吃掉吞吐、内存和可靠性。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
