直接用std::ofstream全局单例多线程写入会崩溃，因其非线程安全；应结合std::call_once初始化+std::mutex保护写入，并避免析构竞态。
为什么直接用 std::ofstream 全局单例会崩溃
多线程下多个线程同时调用 operator<< 写同一个 std::ofstream 对象，不是线程安全的——标准库没保证流对象的并发写入互斥。常见现象是日志内容错乱、部分行被截断，甚至触发 std::terminate（比如内部缓冲区竞争导致 badbit 或析构时 double-close）。更隐蔽的问题是：即使加了锁，如果多个线程频繁争抢同一把锁，性能会急剧下降，且容易因异常跳过解锁造成死锁。
用 std::call_once + std::once_flag 做线程安全的首次初始化
全局日志文件只需打开一次，后续所有线程复用句柄。用 std::call_once 是最轻量、最标准的做法，它天然保证「仅执行一次」且线程安全，比手写双重检查锁（DCLP）更可靠、无内存序风险。
实操建议：
- 把文件打开逻辑封装进一个自由函数（如
init_log_file()），里面做std::ofstream::open()、检查is_open()、设置std::ios::app和std::ios::sync_with_stdio(false) - 在全局
std::ofstream对象定义处不构造，改用指针或std::unique_ptr<std::ofstream>，并在init_log_file()中 new 或 make_unique - 声明一个静态
std::once_flag，每次写日志前先调用std::call_once(flag, init_log_file)
示例关键片段：
立即学习“C++免费学习笔记（深入）”；
static std::unique_ptr<std::ofstream> g_log_stream;
static std::once_flag g_log_init_flag;
void init_log_file() {
g_log_stream = std::make_unique<std::ofstream>("app.log",
std::ios::out | std::ios::app);
if (!g_log_stream->is_open()) {
// 处理失败，比如写到 stderr 或 abort
return;
}
g_log_stream->imbue(std::locale::classic()); // 避免本地化干扰格式
}
void log_message(const std::string& msg) {
std::call_once(g_log_init_flag, init_log_file);
if (g_log_stream && g_log_stream->is_open()) {
*g_log_stream << msg << '\n';
g_log_stream->flush(); // 关键：避免缓冲区滞留
}
}
写入阶段必须加锁，但锁粒度要细
std::call_once 只管初始化，不保护写操作。多个线程仍可能同时进入 *g_log_stream << ...，必须加互斥锁。但锁不能包住整个 log_message（比如包含字符串拼接、时间获取），否则变成串行日志，失去并发意义。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实操建议：
- 只锁真正访问
g_log_stream的那几行：<<、flush() - 用
std::mutex而非std::recursive_mutex，递归锁掩盖设计缺陷 - 避免在锁内调用可能抛异常的函数（如
std::to_string一般不会，但自定义格式化函数需确认） - 考虑用
std::lock_guard<std::mutex>自动管理，别手写lock()/unlock()
补充说明：如果日志量极大（万条/秒以上），锁仍是瓶颈，这时该换无锁队列 + 单独日志线程模型，但那是另一层复杂度了。
注意 std::ofstream 析构和程序退出时的竞态
全局 std::unique_ptr<std::ofstream> 的析构发生在 main() 返回后、静态对象销毁阶段，此时其他线程可能仍在运行（尤其用了 std::thread::detach()），继续调用 log_message() 就会解引用空指针或已析构对象。
实操建议：
- 禁止使用
std::thread::detach()；所有日志写入线程必须在main()结束前join() - 在
main()返回前显式关闭日志：调用g_log_stream.reset()或清空指针，并确保所有工作线程已停止 - 更稳妥做法是把日志系统封装成 RAII 类，在
main()作用域内构造，靠栈顺序保证先停线程、再析构日志对象
最容易被忽略的是：即使你没显式 detach，第三方库（比如某些网络库的后台心跳线程）也可能在静默运行，它们若调用你的日志函数，就踩进这个坑。上线前务必用 ASan + TSan 跑一遍压力测试。
