std::call_once 通过平台级原子操作（如 pthread_once）保证初始化函数仅执行一次，要求 std::once_flag 为同一静态/全局对象且不可拷贝；若初始化异常，后续调用直接返回但异常向上抛出。
std::call_once 为什么能保证只执行一次
它底层依赖平台级的原子操作和互斥机制（比如 pthread_once 或 Windows 的 InitOnceExecuteOnce），不是靠简单加锁模拟的。只要传给 std::call_once 的 std::once_flag 是同一个对象，不管多少线程同时调用，初始化函数最多被执行一次，且所有线程会阻塞到执行完成才继续。
常见错误现象：std::once_flag 被定义在局部作用域或作为临时对象（比如函数返回值、值传递参数），导致每个线程拿到的是不同实例，失去同步意义。
-
std::once_flag必须是静态存储期（static或全局）或由所有竞争线程共享的同一对象 - 不能对
std::once_flag做拷贝、移动、赋值——它被设计为不可复制 - 初始化函数若抛异常，
std::call_once仍视为“已调用过”，后续调用直接返回；但异常会向调用方传播，需自行捕获
典型用法：延迟初始化单例或全局资源
比如一个线程安全的日志器、配置加载器、或连接池。核心是把昂贵/有副作用的初始化逻辑包进 lambda 或函数，并用 std::call_once 包裹。
使用场景：多个线程首次访问某服务时，不希望重复加载配置文件、重复建立数据库连接、或重复构造全局对象。
立即学习“C++免费学习笔记（深入）”；
- 初始化函数应尽量轻量；若耗时长，其他线程会阻塞等待，影响响应
- 避免在初始化函数里再调用另一个
std::call_once（尤其是交叉依赖），可能引发死锁 - 如果初始化依赖外部状态（如环境变量、命令行参数），确保这些在第一次调用前已就绪
示例：
static std::once_flag init_flag;
static std::unique_ptr<DatabasePool> g_db_pool;
void ensure_db_pool() {
std::call_once(init_flag, []{
g_db_pool = std::make_unique<DatabasePool>("config.yaml");
});
}
std::call_once 和 std::mutex 对比：什么情况不该用它
它不是万能替代锁的工具。只适用于「一次性」动作，且该动作本身无返回值、不参与后续并发控制。
容易踩的坑：有人试图用 std::call_once 实现“首次访问加锁”，结果发现后续访问完全没保护——它不提供临界区语义。
- 需要反复读写共享数据？用
std::mutex+std::lock_guard - 初始化后还需持续同步访问？
std::call_once只管开头那一瞬，后面得另配同步机制 - 跨 DLL 边界时，
std::once_flag的地址可能因模块加载顺序不同而不可靠，Windows 上尤其注意
编译与兼容性注意事项
C++11 起支持，但早期 GCC（如 4.7）或 MSVC（2012）实现有缺陷：可能漏掉某些竞态路径，或异常处理不一致。
性能影响极小，底层通常编译为单条原子指令（如 x86 的 cmpxchg）加少量分支，远轻于完整互斥锁。
- 确保编译器标准设为
-std=c++11或更高（CMake 中用set(CMAKE_CXX_STANDARD 11)） - Clang 3.3+、GCC 4.8.1+、MSVC 2015+ 行为可靠；旧版本建议升级或改用平台原生 once 机制
- 静态链接 STL 时，
std::once_flag的内部状态不会跨模块重复初始化，但动态链接下需确保所有模块用同一份 STL
真正难的不是调用 std::call_once，而是判断「这个初始化逻辑是否真的适合放进它里面」——有没有隐式依赖、会不会抛异常、后续是否还要同步访问，这些地方一疏忽，线程安全就变成幻觉。
