静态库中全局变量无“库内隔离”，非static变量被复制进可执行文件，static变量则每编译单元一份，无法跨线程共享；线程安全须靠原子操作、互斥锁或函数内static局部变量实现。
静态库中全局变量的链接行为决定线程安全起点
静态库（.a 或 .lib）本身不参与运行时链接，它只是目标文件的归档。当你链接静态库时，其中定义的全局变量（非 static 修饰的）会被复制进最终可执行文件的 `.data` 或 `.bss` 段 —— 每个可执行文件一份，不是“库内独有”。这意味着：你遇到的线程安全问题，和直接在主工程里写一个全局变量完全等价，不存在“库内隔离”这回事。
常见误判是认为“静态库里的变量天然私有”，但实际只要符号未被 static 或 inline 限定、且未用 __attribute__((visibility("hidden")))（GCC/Clang）或 __declspec(dllexport) 控制，它就可能被主程序或其他静态库重复定义，引发 ODR 违规或未定义行为。
- 确认变量是否真的只被一个编译单元定义：检查静态库源码中是否有
int g_counter = 0;这类定义（而非仅声明extern int g_counter;） - 若多个
.o文件都定义了同名全局变量，链接器通常报multiple definition错误；但若用-fcommon（默认开启），可能静默合并，导致行为不可控 - 避免跨静态库共享同一全局变量名 —— 即使加
static修饰，也只限制于单个.o文件，不同.o仍各自一份，无法协同
static 修饰的全局变量在静态库中是线程安全的假象
在静态库源文件中写 static int g_local_to_lib = 0;，每个包含它的编译单元会得到一份独立副本。看起来“线程安全”，实则毫无意义：线程 A 调用库函数修改的是副本 A，线程 B 调用同一函数修改的是副本 B，二者完全不互通。这不是线程安全，是彻底割裂。
这种写法唯一合理场景是：变量纯属内部临时状态，比如某个辅助函数的缓存，且不依赖跨调用持久性。一旦你需要“所有线程看到同一个值”，static 就失效了。
- 不要用
static全局变量实现跨线程计数、标志位或配置缓存 - 若必须封装状态，改用类 + 静态成员变量，并显式控制其初始化与同步（见下一条）
- 注意：
static局部变量（函数内）是线程安全初始化的（C++11 起），但static全局变量不是 —— 后者初始化发生在 main() 前，由主线程单次完成，无并发风险，但也不提供运行时保护
真正可行的方案：原子变量或带锁封装 + 显式导出接口
静态库应把共享状态的访问逻辑封装成函数接口，并在内部处理同步。外部不直接访问变量，只调用函数 —— 这样才能控制行为、适配不同使用场景。
推荐优先级：std::atomic > std::mutex 封装 > 线程局部存储（thread_local）
- 对简单整型计数、标志位，用
std::atomic<int></int>替代int：无需锁，性能高，且 C++11 起标准保证其内存序可配 - 若需复合操作（如“读-改-写-校验”），必须用
std::mutex或std::shared_mutex包裹临界区，且锁对象本身也得是静态库内定义的静态变量（否则又回到多份问题） - 导出接口函数时，避免返回引用或指针到内部静态变量（易引发生命周期问题）；更安全的是传入用户提供的缓冲区，或返回值语义对象
- 示例接口：
void lib_increment_counter();内部操作static std::atomic<int> s_counter{0};</int>—— 这份s_counter属于该编译单元，链接后唯一
容易被忽略的初始化顺序与析构风险
静态库中的全局变量初始化时间点不确定：它依赖于链接器符号解析顺序和 GCC 的 --whole-archive 等选项。若你的库函数依赖另一个静态库中尚未初始化的全局变量，就会触发未定义行为 —— 而这种 bug 在调试器里极难复现。
更隐蔽的是析构：静态库中定义的全局对象，其析构函数会在 main() 返回后、所有线程已退出时才调用。但如果库函数被工作线程调用，而该线程持有对全局对象的引用或回调，在析构发生后继续访问，就是野指针。
- 杜绝在静态库全局变量构造/析构函数中做任何跨线程操作（如启动线程、发消息）
- 若必须管理资源，改用“首次调用时初始化”模式（如函数内
static T instance;），C++11 保证其线程安全初始化 - 避免在静态库中定义需要复杂析构逻辑的全局对象；优先用 RAII 类型，让使用者显式创建/销毁
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
