std::call_once必须配合std::once_flag使用，因后者是唯一合法的“执行状态载体”，缺一则编译失败；std::once_flag需静态或全局生命周期，不可复制移动，否则导致未定义行为。
call_once 为什么必须配 std::once_flag 使用
call_once 不是独立可用的函数，它强制要求传入一个 std::once_flag 对象引用——这是它的设计契约。漏掉或重复使用同一个 std::once_flag 会导致未定义行为（常见表现是程序崩溃或死锁），而用局部静态 std::once_flag 又可能因多线程同时初始化引发竞争。最安全的做法是把 std::once_flag 声明为静态变量或类成员变量，确保生命周期可控。
- 不能传临时对象：
call_once(std::once_flag{}, []{});是非法的，编译不过 - 不能跨线程复用未初始化的 flag：多个线程同时对未构造的
std::once_flag调用call_once会 UB - 静态局部 flag 在函数内声明是常见且安全的写法，但要注意该函数可能被多次调用
如何在多线程中安全触发一次初始化逻辑
典型场景是延迟初始化全局资源（比如单例、日志器、配置加载）。关键在于让所有线程共用同一个 std::once_flag 实例，并保证回调函数无副作用、不抛异常（否则 call_once 可能重试或卡住）。
- 回调函数若抛异常，
call_once会传播异常，且该 flag 仍视为“未执行成功”，后续调用会再次尝试——这通常不是你想要的 - 推荐把初始化逻辑封装进 try/catch，失败时设标志位或记录错误，避免异常逃出回调
- 示例：
static std::once_flag init_flag; static std::unique_ptr<Logger> logger; void ensure_logger() { std::call_once(init_flag, []{ try { logger = std::make_unique<Logger>("app.log"); } catch (...) { // 记录初始化失败，不抛出 } }); }
call_once 和 std::mutex + 手动标记比有什么区别
手动用 std::mutex 加锁 + bool 标志判断，看似简单，但容易写出有竞态的代码（比如 double-checked locking 没加 memory_order 或 volatile 修饰）。call_once 内部做了完整的内存序和线程同步保障，一次调用即原子生效，无需额外同步原语。
- 手写双检锁易错点：读标志没用
memory_order_acquire，写标志没用memory_order_release，导致其他线程看到部分初始化的对象 -
call_once自动处理所有 fence 和等待逻辑，底层可能用 futex 或类似机制，比 mutex 更轻量 - 性能上：首次调用稍重（要协调多个线程），但后续调用几乎无开销；mutex 方案每次都要进临界区
静态局部变量 vs call_once：选哪个
如果只是初始化一个对象，C++11 起静态局部变量本身就是线程安全的（如 static T x = factory();），编译器自动生成等效于 call_once 的保护逻辑。这时候硬套 call_once 反而多此一举。
立即学习“C++免费学习笔记（深入）”；
- 静态局部变量适合“构造即完成”的场景，且类型可默认构造或支持 constinit
-
call_once更适合需要显式控制时机、或初始化逻辑复杂（涉及多个步骤、条件分支、错误恢复）的情况 - 注意：静态局部变量初始化失败会抛
std::exception，且之后所有访问都直接 throw —— 这比call_once中捕获异常后静默失败更难调试
call_once 的调用。把它放在栈上、或者作为临时对象传入，是最常见的 crash 根源。 
