thread_local变量在该线程首次访问时初始化，且仅一次；读、写或取地址均触发，pod类型零初始化，非pod类型须确保默认构造不抛异常。
thread_local 变量到底在哪个时机初始化
它不是程序启动时统一构造，也不是每次进入函数就新建——thread_local 变量的初始化发生在**该线程首次访问它的时候**（读、写、取地址 &var 都算），且仅一次。这个行为和 static 局部变量类似，但作用域是线程级而非函数级。
常见错误现象：thread_local std::vector<int> buf;</int> 在主线程里没用过，子线程一调用就崩溃；其实是因为子线程首次访问时触发了 std::vector 默认构造，而此时若内存分配失败或构造函数抛异常，直接 std::terminate。
- POD 类型（如
int、std::unique_ptr<t></t>）会被零初始化，无需显式初始化器 - 非 POD 类型必须提供不抛异常的默认构造函数，否则该线程后续所有访问都会终止进程
- 避免在初始化器中调用跨线程资源（如全局锁、单例），容易死锁
头文件里直接写 thread_local int x = 0; 会出什么问题
会触发 ODR（One Definition Rule）违规：多个编译单元包含该头文件后，每个 TU 都生成一份定义，链接时报错或行为未定义。
正确做法只有两种：
- 头文件中用
extern thread_local int x;声明，源文件中用thread_local int x = 0;定义 - 改用匿名命名空间 +
thread_local，例如namespace { thread_local int x = 0; }，限制于单个 TU（适合内部工具类）
类内静态成员不能直接加 thread_local；得写成 static thread_local T member;，并在类外定义。
函数内 static thread_local std::mutex mtx; 是不是线程安全的
不是。C++ 标准明确禁止这种写法：static thread_local 在函数作用域内的初始化**不是线程安全的**。多个线程同时首次调用该函数时，可能并发执行 mtx 的构造，导致未定义行为。
替代方案：
- 把
std::mutex改成全局或命名空间作用域的thread_local变量（即去掉static） - 改用
std::call_once+std::once_flag手动控制初始化逻辑 - 更推荐：直接用普通
std::mutex配合std::lock_guard，除非你真需要每个线程一个互斥体
lambda 捕获 thread_local 变量会发生什么
lambda 默认按值捕获，捕获的是当前线程里那个 thread_local 变量的**快照值**，不是引用，更不是“绑定到该线程的变量本身”。所以在线程 A 中捕获后传给线程 B 执行，B 看到的是 A 当时的值，不是 B 自己的 thread_local 实例。
若需在线程间传递对各自本地存储的访问权：
- 不要传变量本身，应传函数指针或包装成
std::function<void></void> - 让目标线程在自己的上下文中访问自己的
thread_local - 切勿把
thread_local地址存进全局容器（如std::vector<int></int>），不同线程地址互不相干，且生命周期只到线程退出
真正容易被忽略的点是：即使你用 decltype(auto) 或 auto& 捕获引用，捕获的仍是当前线程的引用，无法跨线程复用。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
