双缓冲日志中std::atomic不能直接保护缓冲区内容，因其仅保障切换标志原子性，无法确保数据已落盘或被内核接收；Crash安全需依赖O_DSYNC等系统级持久化语义及结构化校验恢复机制。
双缓冲日志中，std::atomic 不能直接保护整个缓冲区内容
很多人以为用 std::atomic 切换缓冲区就安全了，其实不然。原子变量只能保证切换标志位本身不撕裂，但无法保证：写入缓冲区的那几百字节数据已真正落盘、或至少被内核接收。进程 Crash 时，如果数据还卡在用户态内存或页缓存里，就会丢失。
关键点在于：双缓冲解决的是「多线程写冲突」，不是「Crash 安全」；后者必须依赖系统级持久化语义。
- 缓冲区切换必须和实际写入动作严格配对：先填满 A 缓冲 → 原子标记 A 可刷 → 启动异步刷盘 → 刷完再复用 A
- 不能在标记“可刷”后立刻重置缓冲区指针，否则未刷数据会被覆盖
-
mmap+msync(MS_SYNC)比write()+fsync()更可控，但需注意MAP_SHARED和文件长度预分配
用 O_DSYNC 打开日志文件，比 fsync() 更轻量也更可靠
在 Linux 上，O_DSYNC 让每次 write() 返回前，确保数据和必要元数据（如 mtime、size）已落盘——这正是日志最需要的语义。相比手动 fsync()，它避免了“写完忘了同步”的疏漏，也不像 O_SYNC 那样强制同步所有元数据（性能差一截）。
注意：O_DSYNC 是 open 时指定的，不是 write 时控制的；且仅在支持该 flag 的文件系统上生效（ext4/xfs 都支持，btrfs 需确认内核版本）。
- 打开文件必须用：
open(path, O_WRONLY | O_APPEND | O_CREAT | O_DSYNC, 0644) - 不要混用
O_APPEND和手动lseek()，否则可能破坏原子追加行为 - 若用
FILE*（如fprintf()），无法启用O_DSYNC，必须用底层write()
Crash 前最后一段日志没写完？靠固定长度记录头 + 校验和自恢复
即使用了 O_DSYNC，极端情况下（比如写入中途断电），仍可能留下半截日志记录（例如只写了 12 字节头，本该 24 字节）。这时需要结构化设计来识别并跳过损坏记录。
推荐每条日志以固定格式开头：uint32_t len（含头+正文总长） + uint16_t crc（校验正文），全部小端。读取时逐条解析，遇到 len 超出剩余文件长度、或 crc 不匹配，就丢弃该条并从下一位重新对齐。
- 记录头必须紧凑（≤ 8 字节），避免因对齐填充导致解析错位
- 不要用文本分隔符（如
\n）做边界，Crash 可能恰好断在换行符中间 - 日志轮转时，旧文件末尾补零或写 EOF 标记，避免新文件误读残留垃圾
缓冲区刷盘失败时，别静默吞掉错误，要触发降级策略
调用 write() 或 msync() 返回 -1 并设置 errno（如 ENOSPC、EIO）时，说明磁盘已不可写。此时继续往缓冲区塞日志只会让问题恶化——要么丢更多，要么阻塞线程。
应立即切换到最小可行输出路径：比如把最后几条日志 write() 到 /dev/console 或临时 stderr（若进程还在终端），同时通过 kill(getpid(), SIGUSR2) 触发外部监控进程介入。
- 不要依赖
atexit()—— Crash 时不会执行 - 信号安全函数有限，刷盘失败处理逻辑里只能调用
write()、sigprocmask()、_exit()等 async-signal-safe 函数 - 记录失败事件本身也要走同样持久化路径，否则会形成“连环丢日志”
缓冲区大小、刷盘时机、记录格式、错误响应——这四个点只要有一处松动，Crash 丢日志就大概率发生。尤其容易被忽略的是：刷盘失败后的降级路径是否真的信号安全、是否测试过磁盘满时的行为。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
