不能直接用 std::ofstream 配合轮转逻辑，因其关闭后文件句柄未必立即释放，rename/remove 可能失败，且标准库缺乏文件大小、修改时间等底层能力；需用系统 api 实时判断大小、落盘同步、异步信号安全关闭、时间戳命名+排序清理、多进程下确保换行结尾与原子写入。
为什么不能直接用 std::ofstream 配合轮转逻辑？
因为 std::ofstream 关闭后无法保证文件句柄立即释放（尤其在 Windows 上），若滚动时同名文件正被其他进程（如日志分析工具、tail -f）打开，rename() 或 remove() 会失败；更关键的是，C++ 标准库不提供文件大小查询、最后修改时间获取等底层能力，必须依赖系统 API 或第三方库。
实操建议：
- 用
fstat()（POSIX）或GetFileSizeEx()（Windows）实时判断当前日志文件大小，而非靠写入计数器——后者在多线程/崩溃重启场景下极易失准 - 滚动前先调用
fflush()+fsync()（Linux/macOS）或FlushFileBuffers()（Windows），确保缓冲区数据落盘，否则新文件可能丢失最后几 KB - 避免在信号处理函数（如
SIGUSR1触发滚动）中直接调用std::ofstream::close()—— 它不是异步信号安全的；应只设标志位，由主循环检测后安全关闭
如何让旧日志自动过期并清理？
按时间过期比按数量更可靠：日志量波动大时，固定保留 10 个文件可能导致磁盘占满（例如某天突发百万行错误）；而按天/小时保留则具备可预测性。但要注意 stat() 返回的 st_mtime 是文件内容最后修改时间，不是创建时间——滚动生成的新文件，其 st_mtime 和原文件一致，需靠文件名中的时间戳解析。
实操建议：
- 命名格式强制包含 UTC 时间戳，如
app.log.20240520-143022，避免本地时区歧义 - 清理前对目录内所有匹配
app.log.*的文件做std::sort，按文件名时间戳逆序排列，再从末尾开始unlink()直到剩余数量 ≤ 配置值 - 不要用
system("find ... -mtime +7 -delete")：跨平台差、权限风险高、无法捕获失败原因；C++ 原生遍历 +std::filesystem::last_write_time()（C++17）更可控
多进程写同一个日志文件怎么避免覆盖和损坏？
单靠 std::ofstream 的 std::ios::app 模式不够：它只保证每次 write() 原子性，但多进程同时 open(O_APPEND) 后，内核虽保证追加位置正确，若日志行未以换行结尾，两进程输出可能粘连成一行（如 A 写 "ERR:"，B 紧接着写 "timeout" → "ERR:timeout"）。
实操建议：
- 每个日志行必须以
'\n'结尾，且写入前用write(fd, buf, len)代替流式 - 用
fcntl(fd, F_SETLK, &lock)对整个文件加共享锁（F_RDLCK）再读取大小，加独占锁（F_WRLCK）再执行滚动，避免两个进程同时触发滚动导致文件被删或重命名冲突 - 若必须支持多进程（非多线程），放弃“单文件滚动”，改用进程 ID 命名分片日志（如
app.log.pid12345），由外部聚合脚本统一处理——更简单且无锁
std::filesystem::remove_all() 清理失败的常见原因
这个函数看似方便，但实际在日志管理中容易静默失败：它不抛异常（默认忽略错误），且对正在被其他进程打开的文件，在 Windows 上直接返回 false，Linux 上可能因权限或挂载点只读而失败。
实操建议：
- 永远检查返回值：
if (!std::filesystem::remove(file)) { log_error("failed to remove ", file.string()); } - 对失败文件尝试三次退避重试（间隔 10ms），再失败则记录警告但继续清理下一个——避免单个卡住的文件阻塞整个清理流程
- 不要对日志目录本身调用
remove_all()；只清理其中的旧日志文件，目录结构保留，防止后续open()因目录不存在而失败
实际最难的不是滚动逻辑，而是让清理行为在各种边界条件下都“不惊动业务”：磁盘满时不卡主线程，文件被占用时不崩溃，跨时区部署时不误删。这些细节往往藏在 fstat() 的返回值检查、errno 分支处理、以及每一步系统调用后的 sleep(0) 让出调度权里。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
