os.Open只读且要求文件存在，os.Create则创建或清空写入，默认权限0666；二者均为os.OpenFile特例，复杂需求必须用os.OpenFile控制标志位与权限。
os 包不是“封装好的黑盒”，它暴露的是操作系统原语的直接映射——用错标志位、漏关句柄、权限写反，几乎必然导致运行时错误或静默失败。
os.Open 和 os.Create 的行为差异必须手写判断
很多人以为 os.Open 和 os.Create 只是读/写之分，其实它们底层调用的 os.OpenFile 参数组合完全不同：
-
os.Open("x.txt")等价于os.OpenFile("x.txt", os.O_RDONLY, 0)：文件必须存在，否则报no such file or directory -
os.Create("x.txt")等价于os.OpenFile("x.txt", os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0666)：文件不存在就新建，存在就清空内容 - 若想“只写但不截断”，得手动用
os.OpenFile(name, os.O_WRONLY|os.O_CREATE, 0644)，否则一不留神就把旧数据删了
os.WriteFile 和 os.ReadFile 的适用边界很窄
这两个函数看着方便，但只适合「小文件 + 一次性操作」场景。它们内部会调用 os.OpenFile → 读/写全部内容 → Close，全程内存驻留：
-
os.ReadFile("config.json")没问题；但os.ReadFile("access.log")（几百 MB）会直接 OOM - 权限参数（如
0644）只在创建新文件时生效；对已存在文件无效，也不会修改其权限 - 没有提供追加、偏移写入等能力，要实现日志追加必须用
os.OpenFile配合os.O_APPEND
defer file.Close() 不是万能保险
多数教程强调 defer file.Close()，但实际中容易踩三个坑：
- 如果
file是 nil（比如os.Open失败后没检查 err 就 defer），运行时 panic：panic: close of nil channel（虽然这里是 file，但类似逻辑常见） - 在循环中打开多个文件时，
defer会堆积到函数返回才执行，可能触发系统级“too many open files”错误 -
Close()自身可能返回 error（例如磁盘满时写入成功但 flush 失败），这个 error 被defer吞掉后无法感知
os.ReadDir 比 filepath.Walk 更轻量且可控
遍历目录时，别条件反射用 filepath.Walk。它递归+回调+隐藏错误处理，调试困难，还无法中断：
立即学习“go语言免费学习笔记（深入）”；
-
os.ReadDir("logs")返回[]fs.DirEntry，只读当前层，不递归，速度快，内存稳定 - 每个
DirEntry可快速判断是文件还是目录（.IsDir()），也能直接.Info()获取元数据，无需额外os.Stat - 如需递归，自己控制栈或 channel，比
Walk更易加限速、过滤、超时逻辑
os.ReadFile”、“为什么 Close() 错误不能丢”、“os.O_CREATE|os.O_APPEND 组合是否真符合你的原子性预期”。这些点不写进日志、不测边界输入、不看系统调用 trace，很容易在线上安静出事。 
