os.openfile配合o_append是唯一可靠追加方式，须同时指定o_append、o_wronly、o_create；bufio.writer可提升吞吐但需显式flush；gob追加需帧封装；并发追加必须串行化。
os.OpenFile 配合 O_APPEND 是唯一可靠的基础方式
Go 没有“追加专用函数”，os.OpenFile 是唯一能安全实现末尾写入的入口。必须同时传入 os.O_APPEND、os.O_WRONLY 和 os.O_CREATE 三个 flag，缺一不可：
-
os.O_APPEND确保每次Write或WriteString都从当前文件末尾开始，内核级原子保障，不依赖当前文件偏移量 -
os.O_WRONLY排除读操作开销；若需边写边读（如日志轮转检查），改用os.O_RDWR -
os.O_CREATE防止文件不存在时报no such file or directory；但注意它只在首次创建时生效，不影响已有文件权限
漏掉 os.O_APPEND 会从头覆盖；漏掉 os.O_CREATE 会导致新建文件失败；仅用 os.O_WRONLY 而无 O_APPEND 会静默截断写入——这些错误在大文件场景下尤其隐蔽，因为前几 MB 可能看起来“正常”。
bufio.Writer 能提升吞吐，但要注意 Flush 时机
直接对 *os.File 调用 WriteString 每次都触发系统调用，大文件追加时 I/O 开销陡增。bufio.Writer 可缓冲写入，显著减少 syscall 次数：
- 建议缓冲区设为 64KiB（
bufio.NewWriterSize(f, 65536)）：太小起不到聚合效果，太大可能延迟落盘，尤其断电风险场景 - 必须显式调用
Flush()——defer writer.Flush()不够，因为Close()不保证 flush；若程序异常退出，缓冲区内容会丢失 - 不要混用
bufio.Writer.Write和*os.File.Write：底层 fd 共享，缓冲区与直接 write 的字节序会错乱
示例中常见错误是只 defer Close，却忘了 Flush，导致最后一块数据卡在内存里，日志或备份文件看似“写完”实则缺尾。
gob 追加不是简单 OpenFile + Encode，必须帧封装
encoding/gob 本身不支持追加：gob.Encoder 每次都会重写类型描述头，多次 Encode 到同一文件会产生多个无法连贯解析的流，解码时必然 panic extra data in buffer。
- 正确做法是用长度前缀帧（length-prefixed framing）：每次写入前，先
gob.Encode到bytes.Buffer，再把长度（uint32小端）和字节切片拼起来写入文件 - 读取时循环：先读 4 字节得长度
n，再读n字节进新bytes.Reader，再用新gob.NewDecoder解码——每次都是干净上下文 - 避免用
gob.Register动态注册类型：跨进程重启后类型 ID 映射不一致，帧内类型头可能失效；应提前注册所有可能类型，或统一用interface{}+gob.Register
这个逻辑没法绕过，哪怕你手动 seek 到末尾再写，gob 解码器也无法跳过前面的旧流头去识别新流——它的协议就是单次完整流，不是分段容器。
并发追加必须串行化，O_APPEND 不解决 goroutine 竞态
虽然 os.O_APPEND 保证每次 write(2) 系统调用写到末尾，但 Go 的 WriteString 不是原子的：它先拷贝进内部 buffer，再批量 syscall。多个 goroutine 同时调用，buffer 写入顺序和 syscall 提交顺序可能不一致，导致内容交叉或截断。
- 最简方案：用
sync.Mutex包一层写操作，适合低频写入（如配置变更日志） - 高吞吐场景（如实时指标采集）推荐 channel 聚合：所有写请求发到
chan []byte，单个 goroutine 从 channel 拉取、拼接、批量写入，天然顺序+减少锁争用 - 绝对避免共用一个
*os.File+ 多个 goroutine 直接WriteString—— 测试中 10+ goroutine 并发就大概率出现乱序，且难以复现
这个问题在大文件持续写入时会被放大：一次乱序可能污染后续所有偏移计算，尤其当你还依赖文件长度做分片或校验时，修复成本远高于预防。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
