os.Open仅支持只读且文件必须存在，os.OpenFile通过flag组合实现读写、追加、创建等全功能；权限参数在Windows下被忽略；defer f.Close()不防panic，需出错时手动关闭；大文件禁用os.ReadFile，应流式处理；路径拼接须用filepath.Join。
os.Open 和 os.OpenFile 的核心区别在哪
os.Open 只能只读打开，且要求文件必须存在；os.OpenFile 才是真正的“万能打开函数”，通过组合 flag 控制行为。别用 os.Open 去写文件——它会直接 panic。
-
os.Open("config.json")：等价于os.OpenFile("config.json", os.O_RDONLY, 0)，文件不存在就报no such file or directory - 追加日志？必须用
os.OpenFile("log.txt", os.O_WRONLY|os.O_APPEND|os.O_CREATE, 0644) - 覆盖写新文件？
os.O_WRONLY|os.O_CREATE|os.O_TRUNC缺一不可；漏掉os.O_TRUNC会导致只写开头、残留旧内容 - 权限参数（如
0644）在 Windows 下被忽略，Linux/macOS 上若设成0600却期望组用户可读，就是静默权限错误
为什么 defer f.Close() 不够稳妥
它只在函数 return 时执行，一旦中间 panic 或有多个 return 分支，Close() 可能根本没机会调用，导致 too many open files 错误——长期运行的服务尤其危险。
- 更安全的写法是：打开后立刻检查 err，出错就手动
f.Close()再 return - 例如：
file, err := os.OpenFile("data.txt", os.O_RDWR, 0644) if err != nil { return err } defer file.Close() // 这里才 safe - 注意：
defer不等于“自动资源管理”，Go 没有 RAII；*os.File是裸系统句柄，不 Close 就真不释放
读大文件时，os.ReadFile 为什么是雷区
os.ReadFile 看似方便，但它会把整个文件一次性加载进内存。一个 2GB 的日志文件，直接触发 OOM，进程被系统 kill。
- 真实场景该用流式处理：
bufio.Scanner（适合按行）、bufio.NewReader（适合自定义分隔符）、或原始f.Read(buf)（适合二进制/固定块） -
bufio.Scanner默认单行上限 64KB，超长日志行会报scanner: token too long；需改用reader.ReadString('\n')或调大缓冲区 - 性能敏感时，显式指定缓冲区大小：
bufio.NewReaderSize(file, 32*1024)，比默认 4KB 更省系统调用
写文件时，os.WriteFile 和 os.OpenFile+WriteString 怎么选
os.WriteFile 是原子覆盖封装，但不支持追加、不调用 fsync、也不保证 rename 在 NFS 上的原子性；而 os.OpenFile 虽啰嗦，却是可控性和可靠性的基础。
立即学习“go语言免费学习笔记（深入）”；
- 写配置？用
os.WriteFile快速够用；但关键数据（如数据库快照）务必手写“写临时文件 →f.Sync()→os.Rename()”流程 - 追加日志？
os.WriteFile完全不能用，只能os.OpenFile(..., os.O_APPEND|os.O_WRONLY, ...)配合io.WriteString或bufio.NewWriter - 高频小写？用
bufio.NewWriter包一层，记得最后w.Flush()，否则内容可能卡在缓冲区不落盘
最常被忽略的一点：无论读还是写，路径拼接必须用 filepath.Join("dir", "sub", "file.txt")，硬拼字符串 "dir/sub/file.txt" 在 Windows 下会失效，而 "dir\\sub\\file.txt" 在 Linux 下打不开——这不是 bug，是路径语义没对齐。
