os.readfile适合小文件场景，如读取配置文件、写入临时token或小段日志；因其一次性全量加载内存，大文件易触发oom，故仅限体积可控（通常≤1mb）且无需流式处理时使用。
os.ReadFile 适合什么场景？为什么小文件才用它
os.ReadFile 是 Go 1.16+ 推荐的“一键读取”方式，但它本质是把整个文件内容一次性加载进内存。这意味着：
- 它内部调用
os.Open→io.ReadAll，没有缓冲、不支持中断或流式处理 - 读取 100MB 文件时，会分配约 100MB 的
[]byte，GC 压力陡增；GB 级文件极易触发 OOM - 路径校验缺失：传入
"../../etc/passwd"会直接尝试打开，存在路径遍历风险
只应在明确知道文件体积可控（如配置文件 ≤1MB）、且无需校验路径时使用。否则，换成带缓冲的 bufio.Reader 或分块读取。
追加写入要用 os.OpenFile，不是 os.Create
os.Create 每次都会截断已有内容，而日志、缓存等场景需要保留旧数据并追加。正确做法是用 os.OpenFile 配合标志位：
-
os.O_APPEND | os.O_CREATE | os.O_WRONLY：仅追加，文件不存在时创建 -
os.O_RDWR | os.O_APPEND：可读可追加（如需先检查末尾内容） - 权限参数别硬写
0644—— 如果父目录不可写，即使文件权限设对了也创建失败
示例：os.OpenFile("log.txt", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)。漏掉 os.O_CREATE 时，文件不存在会直接报 no such file or directory 错误。
bufio.Writer 不是“可选优化”，而是写入高频文本的必需项
直接对 *os.File 调用 Write 或 WriteString，每次都会触发一次系统调用（syscall）。写入 100 行日志 = 100 次 syscall，性能断崖式下降。
- 用
bufio.NewWriterSize(file, 4096)包一层，写入自动缓冲，满 4KB 才刷盘 - 务必在写完后调用
w.Flush()——defer w.Flush()不可靠，因为w是包装对象，file.Close()不会自动 flush 缓冲区 - 若写入中间出错，缓冲区内容可能丢失，需结合
w.Buffered()和重试逻辑判断
尤其注意：不要对同一个 *os.File 同时用 bufio.Writer 和原生 Write，缓冲区与底层文件指针不同步，内容会错乱。
defer file.Close() 不等于资源绝对安全
defer file.Close() 只保证函数退出时调用，但不保证关闭成功。常见陷阱：
- 写入后未 flush 就 close：缓冲区数据丢弃（
bufio.Writer场景下尤为致命） - close 失败被忽略：比如磁盘满、NFS 挂载失效时，
file.Close()返回非 nil error，但没人检查 - 多个 defer 顺序问题：如果先
defer w.Flush()再defer file.Close()，flush 可能因 file 已关闭而失败
真正安全的写入流程是：打开 → 写入 → w.Flush() → 检查 flush error → file.Close() → 检查 close error。任何一环失败都应视为写入失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
