std::call_once通过std::once_flag的原子状态和平台同步原语保证线程安全，仅一个线程执行函数，其余阻塞等待；once_flag必须为静态或全局生命周期且默认初始化，否则触发未定义行为。
std::call_once 为什么能保证线程安全？
它底层依赖 std::once_flag 的原子状态 + 平台级同步原语（比如 pthread_once 或 Windows InitOnceExecuteOnce），不是靠简单加锁模拟的。多个线程同时调用 std::call_once，只会有一个成功执行传入的函数，其余全部阻塞等待，等那个线程执行完才一起返回——不会重复执行，也不会竞态读写 once_flag 本身。
关键点在于：std::once_flag 必须是静态或全局生命周期，不能是局部栈变量（否则每次调用都新建，失去“once”意义）；也不能是类成员且未正确初始化（会导致未定义行为）。
怎么写才不会触发“undefined behavior”？
常见崩溃/未定义行为直接来自 std::once_flag 的误用：
-
std::once_flag声明在函数内部但没加static—— 每次调用都构造新对象，std::call_once对不同 flag 调用，完全失去同步作用 - 把
std::once_flag放在栈上（比如作为函数参数传入或临时变量），函数返回后 flag 析构，后续再用就是野引用 - 用
memset、memcpy或聚合初始化（如{}）手动操作std::once_flag—— 它是不可复制、不可移动、不可重初始化的类型
正确姿势只有一种：静态存储期 + 默认初始化。例如：
static std::once_flag init_flag;<br>std::call_once(init_flag, []{ /* 初始化逻辑 */ });
立即学习“C++免费学习笔记（深入）”；
lambda 捕获值时要注意什么？
如果初始化逻辑需要外部变量，捕获方式直接影响线程安全和生命周期：
- 用
[&]捕获局部变量？危险——那些变量可能在其他线程执行 lambda 时早已销毁 - 用
[=]捕获局部对象？仅限于 trivially copyable 类型，且要确保拷贝过程本身线程安全（比如不含指针或共享资源） - 推荐做法：捕获静态变量、全局变量、或通过
std::shared_ptr管理的堆对象，确保生命周期覆盖所有可能的调用时机
例如：
static auto config = std::make_shared<Config>();<br>std::call_once(flag, [config]{ load_config(*config); });
std::call_once 和 std::mutex + if-guard 比有什么实际差别？
表面上都是“首次检查+加锁+执行”，但 std::call_once 更轻量、更可靠：
- 双重检查锁定（DCLP）手写容易出错：内存序漏加
std::memory_order_acquire/release，导致某些平台看到部分构造对象 -
std::call_once内部已处理好所有平台相关内存屏障，用户无需操心 - 性能上，非首次调用时
std::call_once通常只是几个原子读，比 mutex lock/unlock 开销小得多 - 错误处理：如果 lambda 抛异常，
std::call_once会传播异常，且该once_flag仍视为“已触发”，后续调用直接返回——这点必须心里有数，别指望重试
所以除非你明确需要失败后重试，否则别自己手写双重检查。
最常被忽略的是：一旦 std::call_once 中的函数抛异常，这个 once_flag 就永久标记为“已完成（尽管失败了）”，后续调用不再执行也不报错——得靠外部状态或日志确认是否真初始化成功。
