os.openfile安全追加必须同时指定os.o_append | os.o_wronly | os.o_create：缺o_append会覆盖，缺o_create且文件不存在则报错，仅o_wronly会静默截断；o_append提供内核级原子定位，o_wronly避免读开销，o_create不改变已有文件权限但要求父目录存在。
os.OpenFile 必须同时传 os.O_APPEND | os.O_WRONLY | os.O_CREATE
不满足这三个 flag 组合，就不是安全追加。漏掉 os.O_APPEND 会从头覆盖；漏掉 os.O_CREATE 且文件不存在时直接报 no such file or directory；只用 os.O_WRONLY 不带 O_APPEND，写入会静默截断——尤其在大文件里，前几 KB 看似正常，实际已损坏。
-
os.O_APPEND是内核级原子保障：每次Write前自动定位到当前末尾，不依赖Seek或文件长度缓存 -
os.O_WRONLY排除读操作开销；若需边写边读（如检查日志大小），改用os.O_RDWR -
os.O_CREATE只在首次创建时生效，不影响已有文件权限；但父目录必须存在，否则仍失败
WriteString 不自动换行，手动拼接要小心
Go 的 WriteString 就是纯字节写入，不会补 \n 或 \r\n。连续追加两段内容，比如 "hello" 和 "world"，结果是 helloworld 而不是两行。
- 文本日志建议统一加
"\n"；跨平台人工查看（尤其 Windows 记事本），用"\r\n" - 不要依赖
fmt.Fprintln自动换行——它底层仍是WriteString+\n，但多一层格式化开销，无实质优势 - 若内容本身含换行符（如用户输入的多行文本），直接写即可；额外加换行会导致空行
并发写同一文件必须串行化，O_APPEND 不等于线程安全
os.O_APPEND 保证每次系统调用写入位置正确，但 Go 层的 WriteString 不是原子操作：它先拷贝到内部 buffer 再 syscall，多个 goroutine 同时调用可能交错输出，比如两行文字挤在同一行。
- 简单场景用
sync.Mutex包住写逻辑，锁粒度控制在单次WriteString或Write调用外 - 高频日志推荐标准库
log包：log.New(f, "", log.LstdFlags)，内部已加锁，还自带时间戳和换行 - 避免用 channel 聚合再写——看似解耦，但 channel 缓冲区满或 goroutine 阻塞会导致日志延迟甚至丢失
bufio.Writer 能提速，但 Flush 必须显式调用
直接对 *os.File 频繁 WriteString 会触发大量系统调用，吞吐低。加 bufio.Writer 可缓冲聚合，但缓冲区内容不会随 Close() 自动落盘。
- 缓冲区大小建议设为
65536（64KiB）：bufio.NewWriterSize(f, 65536)；太小没效果，太大增加断电丢数据风险 - 必须显式
w.Flush()——defer w.Close()不够，因为Close()不保证 flush；程序 panic 时缓冲区内容直接消失 - 严禁混用：
w.WriteString("a")+f.WriteString("b")，底层 fd 共享但 offset 不同步，输出顺序错乱
os.O_APPEND 解决了定位问题，剩下的得靠你结合场景补全。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
