直接用std::ofstream按大小切分日志会丢数据，因为缓冲区未及时flush导致切片临界点时待写数据既不在旧文件也不在新文件；必须在切片前强制flush()并用seekp(0,ios::end)获取真实大小，而非依赖tellp()。
为什么直接用 std::ofstream 按大小切分日志会丢数据？
因为写入是缓冲的，flush() 不及时或没调用，切片临界点（比如刚好写满 10MB）时新日志可能还卡在缓冲区里，旧文件就关了——结果最后一段日志既不在旧文件也不在新文件。关键不是“怎么切”，而是“怎么确保切的时候所有待写内容已落盘”。
- 必须在判断是否需要新建文件前，先
flush()当前流，再seekp(0, std::ios::end)获取真实大小 - 不要依赖
tellp()返回值做切片判断——它返回的是缓冲区偏移，不是磁盘实际字节数 - 每次写入后不立即
flush()（性能差），但切片点必须强制flush()+sync_with_stdio(false)配合关闭 C stdio 同步
logrotate 风格命名 vs 时间戳命名：选哪个？
时间戳命名（如 app-20240520-142315.log）适合调试和人工排查，但无法天然支持“单个文件不超过 10MB”；logrotate 风格（app.log、app.log.1、app.log.2）便于滚动归档，但需额外管理序号和最大保留数。实际项目中，二者常组合使用：主文件用当前名（app.log），归档时重命名为带时间戳+序号（app-20240520-142315-001.log）。
- 纯大小切片场景，优先用序号后缀（
.1,.2），避免频繁 stat 时间戳文件造成 syscall 开销 - 如果要求“每小时一个文件”，那就用时间戳，但注意跨小时瞬间的写入可能落到旧文件末尾——得在写入前检查当前小时是否变化
- Windows 下文件重命名可能失败（文件被占用），建议先
close()再rename()，Linux 下基本可靠
如何避免多线程写日志时的性能瓶颈？
锁整个 write() 函数是最简单做法，但吞吐量上不去；无锁队列 + 单独日志线程是常见解法，但引入了延迟和内存占用。折中方案是：用 std::shared_mutex（C++17）保护文件句柄和当前文件大小，写操作只读锁，仅在切片时写锁——因为切片本身是低频事件（比如每 10MB 一次），大部分时间多个线程可并发写。
- 别用
std::mutex锁住每次operator，哪怕只是 <code> 也会成瓶颈 - 每个线程写前先获取当前
std::ofstream*，然后直接write()原始字符指针（绕过 iostream 格式化开销），比快 2–3 倍 - 提前分配好 buffer（如
std::array<char></char>），避免每次格式化都 new 临时 string
切片边界容易忽略的三个细节
文件大小达到阈值时，不是“超过就切”，而是“写完当前条日志后再切”。否则一条日志被硬生生截断到两个文件里，解析器会崩溃。
- 记录每条日志的原始长度（含换行符），在写入前判断：当前文件剩余空间
- 切片后，新文件第一行必须是完整日志，不能把上一条日志的后半截带进来——所以切片动作必须在上一条日志
write()+flush()完成后立刻执行 - 程序异常退出时，最后那个未满的文件要能被识别为“有效日志”，不要因缺少 EOF 或不完整结尾而被清理工具误删
真正难的不是逻辑分支，而是把 flush、stat、rename、open 这几个系统调用的时序和错误码兜住——尤其是磁盘满或权限不足时，得降级到 stderr 输出并暂停写文件，而不是让整个服务卡死。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
