go 的 i/o 操作核心在于理解 io.reader 和 io.writer 的契约行为：read 返回 n 是为支持流式分块读取，它表示实际读取字节数，可能小于 len(p)，需配合 err 判断是否结束（如 io.eof）或出错，而非假设一次性读满。
Go 的 I/O 操作不是靠“背接口”学会的，而是靠理解 io.Reader 和 io.Writer 在真实调用链中如何传递、组合、中断来掌握的。
为什么 Read 返回 n
这是最常被误解的点：很多开发者看到 file.Read(buf) 返回 n=5 而 len(buf)=1024 就 panic，其实这完全正常。
- 文件末尾剩余字节不足缓冲区大小时，
Read会返回实际读到的字节数（比如只剩 3 字节，就返回n=3） -
err == nil表示这次读取成功，只是数据不够填满整个buf - 只有当
n == 0 && err != nil才代表真正出错（比如权限拒绝、磁盘断开） - 真正的 EOF 判定条件是
err == io.EOF，且此时n可能大于 0（最后一批有效数据）
os.ReadFile 适合什么场景？它和手动 open+read 有什么区别？
os.ReadFile 是 Go 1.16+ 引入的便捷函数，但它不是万能的——它把整个文件一次性加载进内存。
- 适合小配置文件、JSON 配置、模板文本等 确定体积可控（通常
- 底层仍调用
os.Open→readAll→close，但隐藏了错误传播细节 - 如果文件太大（比如 500MB 日志），直接用
os.ReadFile会导致 OOM，必须改用流式读取 - 它不支持偏移读取、不支持复用文件句柄，也不支持带 context 的超时控制
bufio.NewReader 什么时候能提速？什么时候反而拖慢？
缓冲读不是“加了就快”，它依赖访问模式。对随机小读取或单次大读取，bufio.NewReader 可能引入额外拷贝和内存分配。
- 适合场景：频繁读取小块（如按行解析 CSV、逐字符解析 JSON）
- 底层会预读一块（默认 4KB），后续
Read或ReadLine直接从内存 buffer 取，减少系统调用次数 - 反模式：只调用一次
Read且读取量远大于 buffer 大小（比如buf := make([]byte, 10MB)），这时多一次预读反而浪费 - 注意：
bufio.NewReader(file).Read(buf)和file.Read(buf)行为不等价——前者可能因 buffer 剩余数据提前返回，后者总是直接 syscall
os.OpenFile 的 flag 参数组合容易踩哪些坑？
os.OpenFile 的第二个参数是位或标志，常见误用集中在 O_CREATE、O_APPEND 和 O_TRUNC 的混用。
-
os.O_CREATE | os.O_APPEND：文件不存在则创建，存在则追加 —— 安全常用组合 -
os.O_CREATE | os.O_TRUNC：文件存在就清空重写，不存在则创建 —— 但若忘记加O_WRONLY或O_RDWR，会打开失败（flag 缺少读写权限） -
os.O_APPEND | os.O_TRUNC：**无效组合**，O_TRUNC会被忽略，Linux 内核直接丢弃该 flag -
os.O_EXCL | os.O_CREATE：确保文件“一定新建”，若已存在则返回os.IsExist(err)为 true —— 用于原子化初始化
真正难的不是记住每个 flag 含义，而是理解它们在内核层面如何影响文件指针位置、是否触发 truncate 系统调用、以及并发写入时的原子性边界。这些细节不会出现在文档第一行，但会决定你写的日志轮转或配置热加载是否可靠。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
