静态变量在多线程下需用同作用域的static互斥锁保护，推荐封装为类的private static成员并用std::lock_guard实现raii；函数内static mutex虽可行但易被误用，应优先避免。
静态变量在多线程环境下极易成为数据竞争的源头，尤其当它是全局或类内 static 成员时——多个线程可能同时读写它，导致结果不可预测。直接用 std::mutex 保护是可行的，但关键在于锁的声明位置、生命周期和作用域是否匹配静态变量的访问模式。
静态变量和互斥锁必须同级声明
如果静态变量是全局的，互斥锁也得是全局的；如果是类的 static 成员变量，互斥锁必须是同级别的 static 成员，不能是局部变量或非静态成员。
- 错误写法：
void func() { static int counter = 0; std::mutex mtx; std::lock_guard<:mutex> lg(mtx); ++counter; }</:mutex>—— 每次调用都新建一个mtx，完全起不到保护作用 - 正确写法：把
mtx和counter都声明为static，且在同一作用域（如函数内或类中） - 更推荐：将二者一起封装进类里，作为
private static成员，避免全局污染
std::lock_guard 是唯一安全的选择
静态变量的访问往往跨线程、跨函数调用，手动调用 lock()/unlock() 极易出错——比如提前 return、抛异常、或忘记 unlock。RAII 是刚性要求。
-
std::lock_guard构造即加锁、析构即解锁，作用域结束自动释放，无需人工干预 - 不要用
std::unique_lock去保护简单静态变量——它支持延迟加锁和手动控制，但增加了复杂度和出错可能，纯属过度设计 - 注意：
std::lock_guard不支持std::defer_lock，传入std::adopt_lock仅适用于你已手动加锁的场景，不适用于静态变量常规保护
类内 static 成员变量的典型保护模式
这是最常见也最易出错的场景：多个对象共享一个 static 计数器、缓存或配置，必须确保线程安全。
- 互斥锁必须是
static成员，否则每个实例都有自己的锁，等于没锁 - 锁和变量应同为
private，通过public静态接口访问，避免外部绕过锁直接操作 - 示例片段：
class Counter {
private:
static int count_;
static std::mutex mtx_;
public:
static void increment() {
std::lock_guard<:mutex> lg(mtx_);
++count_;
}
static int get() {
std::lock_guard<:mutex> lg(mtx_);
return count_;
}
};
int Counter::count_ = 0;
std::mutex Counter::mtx_; // 必须在类外定义
</:mutex></:mutex>
漏掉最后一行定义（std::mutex Counter::mtx_;）会导致链接错误：undefined reference to 'Counter::mtx_' —— 这是新手高频踩坑点。
函数内 static 变量 + 局部 static mutex 的边界情况
有时你会看到这种写法：void f() { static int x = 0; static std::mutex m; std::lock_guard<:mutex> lg(m); ++x; }</:mutex>。它能工作，但有隐含风险：
- C++11 起，函数内
static变量初始化是线程安全的，但仅限于初始化那一刻；后续访问仍需显式同步 - 多个线程首次调用该函数时，
static std::mutex m的构造本身是线程安全的（由编译器保证），但别指望它能帮你保护x—— 你仍需自己加锁 - 真正麻烦的是：若该函数被频繁调用，
static std::mutex会一直驻留内存，且无法复位或销毁；长期运行的服务中，这类“隐藏静态锁”容易被遗忘和误用
所以，除非逻辑极其简单且生命周期明确，否则优先走类封装路径——把静态状态和它的锁绑在一起，看得见、管得住。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
