直接用os.file写文件≠持久化，因未sync()断电即丢、无原子写入崩溃致损坏、无边界管理并发错位；真正落地需从失败场景推演，如写data失败丢一条、写offset失败致重复消费等。
直接用 os.File 写文件 ≠ 持久化。写完不 Sync()，断电就丢；没做原子写入，崩溃后文件可能半截损坏；没设计读写边界，多 goroutine 一并发就错位。真正落地的磁盘持久化，得从「哪一步失败会怎样」开始想。
为什么 os.WriteFile 或 ioutil.WriteFile 不够用
它们只是把字节写进内核页缓存，不触发 fsync(2)。进程退出、系统重启、甚至 kill -9 都可能导致数据永远不落盘。更隐蔽的问题是：并发调用 os.WriteFile 会覆盖整个文件，根本没法做 FIFO 或追加写。如果业务需要「写一条消息」「读一条消息」「消费即移除」，这种粗粒度写法会直接破坏语义。
- 单次写入小数据（如 JSON 配置）可用，但必须手动跟
f.Sync() - 多 goroutine 同时写同一文件 → 数据错乱，无锁保护
- 写入中途崩溃 → 文件内容不完整，且无法判断哪部分有效
- 没有 offset 管理 → 无法实现断点续读，每次重启都得重扫全文件
用分段文件 + 固定头格式实现安全 FIFO
真正的磁盘 FIFO 不靠“删文件”，而靠「偏移量推进」+「消息独立封帧」。每条消息前写 4 字节 uint32（小端序）表示 payload 长度，再写实际数据。这样即使某条消息写到一半崩溃，下一条仍可从下一个合法头开始解析。
- 写入：先
binary.Write(f, binary.LittleEndian, uint32(len(data)))，再f.Write(data)，最后f.Sync() - 读取：用
io.ReadFull(f, header[:])读头，若失败或长度超限（比如 >1MB），视为该条损坏，跳过并重试下一条 - 消费位置存在单独的
queue.offset文件里，每次成功处理完一条，才把新 offsetSync()写进去 - 重启时先读
queue.offset，再从queue.data对应位置开始读 —— 这是唯一能保证「不多读、不少读」的做法
为什么 BoltDB 比手写日志更适合多数场景
自己管理文件偏移、崩溃恢复、并发锁、坏块跳过……这些逻辑加起来远超业务本身。BoltDB 是纯 Go 实现、ACID、单文件、mmap 友好，且自带事务提交和 page 级原子写。它不解决「怎么设计 schema」，但帮你绕开 90% 的底层陷阱。
- 入队用
tx.Bucket("queue").NextSequence()自增 key，避免手写序列号冲突 - 出队别用
Delete()，改用 status 字段：0=待处理，1=处理中，2=完成；崩溃后扫描所有 1 状态项重放 - 批量写比单条快 5–10 倍：一次
tx.Update里连续b.Put()多条，而不是 N 次事务 - 别在循环里调
tx.Commit()—— 它带隐式Sync()，机械盘上会卡死
sync.RWMutex 和 file.Sync() 的真实作用边界
sync.RWMutex 只管进程内并发，防止两个 goroutine 同时读同一条消息；file.Sync() 只管内核到块设备这层，不保证 SSD 控制器或 RAID 缓存已刷盘。两者缺一不可，但都不能替代对方。
- Push 和 Pop 都要锁：Push 锁防 head 错位，Pop 锁防 offset 读-改-写竞争
-
file.Sync()必须检查错误：返回input/output error说明磁盘异常，不能忽略 - 不要对同一个
*os.File并发调Write()—— 即使加了 mutex，Go 的Write也不是原子系统调用 - 临时文件 +
os.Rename()才是原子更新的底线：先写data.tmp，Sync()成功后再Rename()，避免中间态暴露
最难的部分不是写多少行代码，而是画出每一步失败的后果图：写 data 失败 → 丢一条；写 offset 失败 → 重复消费；rename 失败 → 留下 .tmp 文件要清理；Sync 返回 no space left → 即使 Write 成功也得当写失败处理。这些路径都得有明确 fallback，否则所谓“持久化”只是幻觉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
