安全写入日志需用std::ios::app模式、每条后flush()、避免信号处理中写入；多线程宜用thread_local缓冲+独立刷盘线程；拼接优先stringstream或C++20 format；路径需适配平台编码与分隔符。
怎么用 std::ofstream 安全写入日志文件
直接用 std::ofstream 追加写日志最轻量，但不加防护容易丢日志或阻塞主线程。关键不是“能不能写”，而是“多线程下会不会乱”“程序崩溃时最后一行还在缓冲区里吗”。
- 必须用
std::ios::app模式打开，否则每次写都会覆盖文件；但别用std::ios::ate，它会把文件指针移到末尾再读取，对日志无意义还多一次系统调用 - 每条日志后调用
flush()，否则std::ofstream的缓冲区可能滞留几 KB 数据——进程被 kill -9 时就彻底丢失 - 避免在信号处理函数（如
SIGSEGV）里直接写文件，std::ofstream不是 async-signal-safe，改用write()系统调用更稳妥
为什么 std::stringstream 拼接日志比 + 字符串快
日志格式通常是 [2024-06-12 14:23:05] INFO main.cpp:42 — User login failed，中间要插时间、级别、文件行号。用 std::string 多次 + 会产生大量临时对象和内存重分配。
-
std::stringstream内部维护动态缓冲区，多次<<只触发少数几次扩容，实测在千条/秒级日志下比+快 2–3 倍 - 别用
std::to_string()转数字——它分配堆内存；对整数优先用std::format（C++20）或snprintf到栈数组 - 如果编译器不支持 C++20，
std::ostringstream比std::stringstream更合适，只写不读，减少内部标记开销
多线程写同一个日志文件怎么不卡死
多个线程同时调用 ofstream <<，即使加了 std::mutex，也可能因锁粒度太粗导致吞吐骤降——尤其当日志量大时，所有线程排队等一个锁。
- 用
std::shared_mutex不解决问题，写操作本质是排他的，读写锁没意义 - 真正有效的做法是：每个线程先写到自己的
thread_local std::string缓冲区，再由单独的 logger 线程定时合并刷盘（比如每 10ms 或缓冲满 4KB） - 避免用
std::cout替代文件日志——它默认同步到stdout，而终端输出本身比磁盘还慢，且不同终端行为不一致（如重定向到文件时缓冲策略突变）
Windows 下路径硬编码 "logs/app.log" 会失败
不是权限问题，是 Windows 对长路径、Unicode、相对路径的处理和 Linux 差异极大。常见现象是文件创建成功但写入返回 0 字节，或者 ofstream::is_open() 返回 false 却不报错。
立即学习“C++免费学习笔记（深入）”；
- 绝对路径必须用正斜杠
/或双反斜杠\，单反斜杠在字符串字面量里是转义符，"logspp.log"实际变成"logs[响铃符]app.log" - 涉及中文路径时，
std::ofstream构造函数不支持 UTF-8 字符串（MSVC 默认窄字符 API），得用_wfopen+std::wofstream，或直接调用CreateFileW - Linux 下建议用
getenv("HOME")拼接日志路径，Windows 下优先查GetEnvironmentVariable(L"LOCALAPPDATA")，别依赖当前工作目录——服务模式启动时它可能是C:WindowsSystem32
真正的难点不在“怎么写进去”，而在“怎么确保它一定落盘”“怎么让调试时看到的日志和线上一致”“怎么避免日志本身拖垮业务逻辑”。这些细节不会报错，但会在高负载或异常退出时突然暴露。
