std::call_once不能直接传带捕获的Lambda，因类型推导失败或移动语义问题；once_flag必须静态/全局生命周期，不可复制移动；相比手写mutex+标志，它提供免锁、原子性及异常重试保证。
std::call_once 为什么不能直接传函数对象？
因为 std::call_once 要求第一个参数是 std::once_flag&，第二个及之后的参数会被完美转发给目标可调用对象——但它**不接受临时函数对象或 lambda 捕获列表为空以外的 lambda**。常见错误是写成：
std::call_once(flag, []{ init(); });这在 c++11/14 中合法，但若 lambda 有捕获（比如 [&x]{ x = 42; }），就可能因类型推导失败或移动语义问题编译不过。
更稳妥的做法是：用具名函数、静态 lambda（无捕获）、或显式绑定参数：
- 优先用普通函数或静态成员函数，类型稳定
- 若必须用 lambda，确保无捕获，或用
std::bind封装（注意std::bind返回对象需可复制） - 避免传递局部变量地址给异步执行的初始化逻辑，
std::call_once不保证调用时机，只保证“一次”
std::once_flag 必须是静态或全局生命周期
std::once_flag 对象本身**不可复制、不可移动**，且内部依赖静态状态做原子标记。如果把它放在栈上或作为类的非静态成员，在多线程反复创建/销毁该作用域时，会导致未定义行为——典型表现是程序崩溃或初始化被重复执行。
正确用法只有两种：
立即学习“C++免费学习笔记（深入）”；
错误示例：
void foo() { std::once_flag flag; // ❌ 栈上分配，每次调用都是新对象 std::call_once(flag, init); }和 std::mutex + 手动标志比，优势在哪？
核心是「免锁 + 强保证」：std::call_once 底层用原子操作+futex（linux）或类似机制实现，没有互斥锁开销；更重要的是它能保证：即使多个线程同时进入，也只有一个会真正执行初始化函数，其余线程会阻塞等待，且等待期间不会重复尝试——而手写标志+std::mutex 容易漏掉内存序（missing std::memory_order_acquire）、双重检查时序错乱、或忘记 unlock。
典型手写陷阱：
- 用
bool inited = false;+if (!inited) { lock(); if (!inited) { init(); inited = true; } unlock(); }—— 缺少volatile或原子操作，编译器/CPU 可能重排 - 用
std::atomic但没配合适当 memory order，导致其他线程看到部分初始化状态
std::call_once 把这些细节全封装了，你只要管好初始化函数本身的线程安全性即可。
初始化函数抛异常会怎样？
如果传给 std::call_once 的函数抛出异常，该次调用视为「初始化失败」，std::once_flag 保持未就绪状态，后续再次调用 std::call_once 会重试执行——这是标准明确规定的语义（C++11 §30.4.4.2）。也就是说，它不认为“抛异常 = 已完成”，而是“这次没成功，下次再来”。
所以要注意：
- 不要在初始化函数里吞掉关键异常（比如文件打开失败却 catch 后返回），否则可能无限重试
- 如果初始化逻辑本应只试一次（例如硬件 probe 失败即永久不可用），得在外层加额外标志控制，
std::call_once本身不提供“失败后不再试”的选项 - 异常对象需满足可拷贝（C++11 要求），否则可能在传播时崩溃
实际中，建议初始化函数尽量无异常，或把可恢复错误转为返回码，真正不可恢复的才 throw。