不能直接用os.file追加再截断实现fifo，因truncate()非原子操作，多goroutine并发易破坏文件结构，且会误删未读消息；崩溃时截断中断将导致半截数据，解析卡死。
为什么不能直接用 os.File 追加再截断实现 FIFO
因为 os.File.Truncate() 不是原子操作，多 goroutine 并发调用时极易破坏文件结构；更关键的是，截断会把「还没读到」的消息一起删掉——你根本没法安全定位“当前消费到哪”。真实场景下，进程崩溃或 kill -9 会导致截断中途失败，留下半截数据，后续所有解析都卡死。
- 写入必须带长度头（如
binary.Write(file, binary.LittleEndian, uint32(len(data)))），否则无法跳过损坏项 - 每次
Write()后必须跟file.Sync()，否则断电时可能只写入了长度没写入 payload - 不要试图用
Seek(0)清空头部——ext4 对小范围随机写性能极差，且Sync()开销翻倍
BoltDB 做队列时怎么避免出队重复消费
错误做法是「查一条 → 处理 → Delete()」，一旦处理中 panic 或 crash，消息就永久丢失。BoltDB 没有原生状态字段，得靠 value 结构体显式标记生命周期：
- value 存
struct{ Data []byte; Status uint8 }，Status == 0表示待处理 - 出队时用
cursor.First()扫到第一个Status == 0的 key，Put()把它改成Status == 1，再返回Data - 消费者成功后调用
Ack(key)把Status改成2；失败则重置为0或进死信 - 启动时扫描所有
Status == 1的项，视为悬挂任务，按策略重放或告警
高并发写入 BoltDB 队列为啥慢？怎么提速
BoltDB 是单 writer，每条消息开一个 Update() 事务，本质是串行排队。实测 1000 条消息单独事务耗时约 1.2s，批量塞进一次事务只要 150ms。
- 批量入队：在单个
Update()里连续调用b.Put()，别拆成多个事务 - 避免在循环里反复
tx.Bucket("queue")—— 提前取一次引用，减少 map 查找 - 别用
json.Marshal()做高频序列化，gob或自定义二进制格式快 3–5 倍 -
NextSequence()虽方便，但高并发下易成为热点；可改用时间戳+随机数拼 key，规避 bucket 内部锁
用文件分段管理队列时，offset 文件为什么必须 O_TRUNC + Sync()
offset 文件只存一个 int64，但若用 os.WriteFile() 或追加写，可能因部分写导致内容错位（比如只写入了低 4 字节）。Linux 下 write(2) 不保证原子性，尤其跨页边界。
- 必须用
os.OpenFile(path, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0644)，确保每次覆盖完整 - 写完立刻
file.Sync()，否则 offset 滞后于 data 文件，重启后会重复消费 - 读
offset时用binary.Read(file, binary.LittleEndian, &offset)，别用文本解析——避免空格、换行等干扰 - offset 更新必须在业务逻辑完成之后，不是在
Read()之后——否则处理失败也会推进 offset
Write()，而是想清楚「哪一步失败会导致什么后果」：写入 length 头成功但 payload 失败 → 下次读到超长长度，直接 panic；offset 写成功但业务失败 → 消息丢；Sync() 被跳过 → 断电即丢最后一批消息。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
