必须用os.openfile配合os.o_append、os.o_wronly、os.o_create三者缺一不可，否则会覆盖、失败或不跨平台；os.writefile和ioutil.writefile因内部调用os.create并带o_trunc，无法安全追加。
必须用 os.OpenFile 配合 os.O_APPEND、os.O_WRONLY、os.O_CREATE 三个 flag，缺一不可；其他写法要么覆盖、要么失败、要么不跨平台。
为什么 os.WriteFile 和 ioutil.WriteFile 不能用于追加
这两个函数内部调用 os.Create，强制带 O_TRUNC，等价于“先清空再写入”。哪怕你先读全文件、拼接字符串、再调用它，中间也存在竞态窗口：另一 goroutine 可能在你读完后、写入前完成一次追加，结果被你全量覆写掉。日志、备份、临时拼接类场景中，这是数据丢失的常见根源。
-
os.WriteFile("log.txt", []byte("new"), 0644)→ 每次都重写整个文件 - 并发下尤其危险：A 读取 100 行 → B 写入第 101 行 → A 拼接并全量写回 → B 的第 101 行消失
- 没有缓冲、不复用句柄、无法控制换行符，也不支持
Sync()落盘保障
os.OpenFile 的 flag 组合为什么必须三者齐全
漏掉任意一个，行为就不可控：
-
os.O_APPEND缺失 → 即使文件存在，WriteString也会从头开始写，静默覆盖前几 KB（大文件里不易察觉） -
os.O_WRONLY缺失（比如只传O_APPEND | O_CREATE）→ 打开失败，报invalid argument，因为O_APPEND必须配合写模式使用 -
os.O_CREATE缺失 → 文件不存在时直接返回no such file or directory，而不是帮你建一个 - 权限参数
0644只在首次创建时生效；已有文件权限不变，但若目标目录无写权限（如 Windows Service 账户），创建会静默失败
流式写入时 bufio.Writer 怎么用才不丢数据
直接对 *os.File 频繁调用 WriteString 会触发大量系统调用，吞吐低。加 bufio.Writer 能聚合写入，但必须显式 Flush，否则最后一块缓存永远卡在内存里。
- 缓冲区大小建议设为
65536（64 KiB）：bufio.NewWriterSize(f, 65536)；太小没效果，太大延迟落盘 -
defer writer.Flush()不够 ——Close()不保证 flush，程序 panic 或 kill -9 时缓存内容直接丢失 - 不要混用：
writer.Write和f.WriteString共享底层 fd，字节序会错乱，导致日志半行粘连或截断 - Windows 下记事本只认
"\r\n"，用"\n"追加后显示为一行；跨平台日志建议统一用"\r\n"
并发追加时 O_APPEND 并不等于线程安全
O_APPEND 是内核级原子定位+写入，但 Go 的 WriteString 不是原子操作：它先拷贝字符串到 runtime buffer，再 syscall write。多个 goroutine 同时调用，buffer 写入可能交错。
- 现象：两行日志变成
"2026-06-13T11:22:00ERR+INFO msg\n"这种粘连乱码 - 安全做法只有两种：
sync.Mutex包住WriteString调用，或用 channel 把写请求串行化到单个 goroutine - 别信“O_APPEND 就不用加锁”——那是对系统调用的误解，Go 层面仍需同步
- tar 归档等二进制格式不能用
O_APPEND追加，会破坏结构；标准库archive/tar不支持追加，只能重建或分片
真正麻烦的不是语法，而是 flag 组合的语义刚性、缓冲区 flush 的时机、以及并发下 WriteString 的非原子性——这些点一旦忽略，问题往往在压测或上线后才暴露，且难以复现。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
