只读全局变量本身不会因并发初始化崩溃，真正崩溃的是看似只读、实则动态初始化的变量，如含std::mutex或依赖其他全局对象的单例；因其初始化时机不可控且非线程安全，易导致访问未初始化对象而崩溃。
只读全局变量本身不会因并发初始化崩溃——真正崩溃的是那些“看似只读、实则动态初始化”的变量，尤其是内部含 std::mutex 或依赖其他全局对象的单例。
为什么“只读”变量也会触发初始化竞争
所谓“只读全局变量”，如果其初始化表达式涉及运行时计算（比如调用函数、构造非 trivial 对象），就属于动态初始化，而非编译期静态初始化。这类变量在首次访问前必须执行初始化代码，而 C++ 标准不保证跨文件初始化顺序，更不保证多线程下首次访问时的竞态安全。
-
std::string g_config = loadConfig();：看似只读，但loadConfig()是运行时函数，std::string构造也是动态初始化 -
static const std::mutex g_mutex;：错误写法——std::mutex无 constexpr 构造函数，无法静态初始化；实际是动态初始化，且未定义行为 -
const int g_flag = computeFlag();：若computeFlag()非constexpr，则该初始化在 main 之前异步发生，时机不可控
std::mutex 全局实例是最常见的崩溃源头
崩溃日志常停在 std::mutex::lock() 或 _Mtx_lock，地址合法但锁对象内存为零或已析构——这几乎 100% 表明该 std::mutex 所在的全局对象尚未完成动态初始化，或已被提前析构。
- MSVC 下
std::mutex的内部状态（如_Myptr）在未初始化时为nullptr，调用lock()会触发0xc0000005访问违规 - 即使你没显式定义
std::mutex全局变量，只要某个单例类的静态成员含std::mutex，且该单例被多个线程在启动早期争抢访问，就会暴露此问题 - 崩溃复现率低、时机飘忽，是因为它依赖链接器顺序 + 线程调度 + DLL 加载时机等多重不确定因素
用函数局部静态变量替代全局对象
这是 C++11 起最可靠、最轻量的修复方式。编译器保证函数内首次执行到该声明时才初始化，且该初始化是线程安全的（无需额外锁）。
- 把
ConfigStore g_store;改成：ConfigStore& getConfigStore() { static ConfigStore instance; return instance; } - 把
std::mutex g_mutex;改成：std::mutex& getGlobalMutex() { static std::mutex m; return m; } - 注意：返回引用，不要返回值（避免拷贝）；函数体必须在 .cpp 中定义，不能仅在头文件里 inline
延迟初始化 + std::call_once 是复杂场景的兜底方案
当初始化逻辑需传参、需异常处理、或涉及多个协作对象时，std::call_once 比局部静态变量更可控。
- 声明全局
std::once_flag g_init_flag;和原始指针/引用容器 - 所有访问点统一走：
std::call_once(g_init_flag, []{ g_pConfig = new ConfigStore(loadConfig()); }); - 比双重检查锁定（DCLP）更安全：
std::call_once由标准库保障原子性与内存序，无需手动std::atomic或std::memory_order措施 - 缺点：无法自动析构，需配合
atexit()或显式清理逻辑
真正危险的不是“并发读”，而是“并发触发初始化”。哪怕变量标了 const 或 constexpr，只要初始化过程不是纯编译期可求值，就可能掉进这个坑。最稳妥的做法，是彻底消灭跨编译单元的动态初始化依赖——把初始化动作收束到函数入口，让语言标准替你扛住线程安全。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
