std::call_once要求callable可移动构造且once_flag必须静态或线程局部；传入lambda需避免捕获已销毁局部变量，once_flag不可复制移动，生命周期须覆盖所有调用。
std::call_once 为什么不能随便传函数对象
它要求传入的 callable 必须是可调用且满足 std::is_nothrow_move_constructible（C++17 起）或至少能被完美转发构造。常见翻车点：捕获局部变量的 lambda、带非静态成员函数指针但没绑定对象、或者用了 std::ref 包裹临时对象。
- 错误示例：
[x]{ /* x 是局部 int */ }()—— 若x在std::call_once执行前就销毁，行为未定义 - 正确做法：把需要的数据提前 move 进 lambda，或用静态/全局变量承载初始化逻辑
- 注意：
std::call_once内部会 move 构造一次 callable，所以传入的 lambda 必须支持移动（默认捕获的 lambda 通常满足）
std::once_flag 必须是 static 或 thread_local
否则每次调用都新建一个 std::once_flag，等于白用 —— 它没法跨调用维持“已执行”状态。
- 错：在函数内声明
std::once_flag flag;，然后传给std::call_once(flag, ...) - 对：声明为
static std::once_flag flag;，或放在类静态成员、命名空间作用域里 - 进阶：若想每个线程各自初始化一份（比如 TLS 初始化），可用
thread_local static std::once_flag flag;，但得确认这真是你想要的语义
std::call_once 报 “invalid argument” 或直接 crash
大概率是 std::once_flag 被复制、移动或析构了 —— 它是不可复制、不可移动的类型，且必须保持活跃直到所有 std::call_once 调用完成。
- 典型误操作：把
std::once_flag放进std::vector、std::map或作为函数返回值 - 检查是否在对象析构函数里调用了
std::call_once，而此时once_flag可能已被销毁 - Windows 上若混用 MSVC 和 MinGW 工具链，
std::once_flag的 ABI 不兼容，也会触发断言失败
和 std::mutex + 手动 flag 比，性能差在哪
不差，反而更好。第一次调用时有原子操作开销，但后续调用几乎零成本 —— 编译器通常生成类似“测试-跳转”指令序列，比加锁/解锁快得多。
立即学习“C++免费学习笔记（深入）”；
-
std::call_once底层依赖平台原语（如 Linux 的 futex、Windows 的 SRWLock），不是纯用户态忙等 - 别自己写
if (!inited) { lock(); if (!inited) { init(); inited = true; } unlock(); }—— DCLP（双重检查锁定）在 C++11 前不安全，C++11 后也容易因内存序漏写std::atomic_thread_fence出错 - 真正要注意的是：别在 hot path 里反复调用
std::call_once，哪怕它很快，频繁原子读也有 cacheline 争用风险
最常被忽略的一点：std::once_flag 对象的生命周期必须严格长于所有对它的 std::call_once 调用 —— 它不是“用完即弃”的工具，而是状态锚点。
