thread_local变量在各线程首次访问时初始化且仅一次；每个线程独有一份，线程结束时自动析构；必须声明为命名变量，函数内static thread_local非线程安全；调试需比对地址而非值。
thread_local 变量到底在哪儿初始化
它不是每次进函数就新建，也不是全局变量那种“程序启动时统一构造”——thread_local 变量的初始化发生在**该线程首次访问它的时候**，且仅一次。这个“首次访问”指的是第一次读或写，哪怕只是取地址（&var）也算。
常见错误现象：thread_local std::vector<int> buf;</int> 在主线程里没用过，但子线程一用就崩——其实是子线程第一次访问时调用了 std::vector 默认构造函数，而如果此时内存不足或分配器异常，就会 crash；不是语法错，是运行时隐式初始化失败。
- 静态生命周期：每个线程一份，线程结束时自动析构（顺序与构造相反）
- 不能用于函数参数、返回值、临时对象，只能用于命名变量（全局、命名空间作用域、static 局部、类 static 成员）
- 类内声明
static thread_local T member;必须在类外定义（即使有默认初始化）
和 pthread_key_t / __declspec(thread) 的关键区别
thread_local 是 C++11 标准机制，语义清晰、可移植；而 __declspec(thread)（MSVC）或 __thread（GCC 旧扩展）不支持非POD类型（比如带构造函数的类），也不能用于动态库中的全局变量（Windows 下 DLL 加载时可能出错）。
使用场景：跨平台项目必须用 thread_local；若需兼容极老编译器（如 GCC 4.7 之前），才考虑退化为宏封装的 pthread_key_t 手动管理。
立即学习“C++免费学习笔记（深入）”；
-
thread_local支持完整构造/析构语义，__declspec(thread)对 std::string 等可能跳过构造函数 - 动态库中：Linux 下
__thread有 TLS 模型限制（initial-exec 不支持 dlopen），thread_local自动适配 - 性能差异微小，现代编译器对两者都做了优化，不必为性能牺牲可读性
thread_local 静态局部变量的陷阱
写 void foo() { static thread_local std::mutex mtx; } 看似省事，但这是危险操作：C++ 标准规定，函数内 static thread_local 的初始化不是线程安全的——多个线程同时首次调用 foo()，可能并发执行 mtx 的构造，导致未定义行为。
正确做法只有两种：移到命名空间作用域（让编译器保证 per-thread 初始化安全），或改用 thread_local 指针 + 手动 new（自己管生命周期）。
- 错误示例：
static thread_local std::random_device rd;—— 多线程首次调用时可能 double-init - 正确示例：
thread_local std::random_device rd;（全局或 namespace 作用域） - 若必须函数内隔离，用
thread_local std::unique_ptr<t> ptr;</t>+ 检查空指针后 new
调试时怎么确认某个变量真是 per-thread
别靠猜。直接打印地址：printf("addr: %p\n", (void*)&my_var);，在不同线程里运行，看地址是否完全不同。注意：不要只比对值，因为值可能碰巧一样。
常见错误现象：调试器里看到所有线程的变量值相同——大概率你忘了加 thread_local，或者误写成 static（那是进程内唯一一份）。
- GDB 中可用
info threads切换线程，再print &var查地址 - Windows 下用 Visual Studio 调试器，“线程”窗口右键可“切换到线程”，再观察变量值
- 注意：ASan/TSan 对
thread_local变量的检测有限，别依赖它们报 data race
thread_local 对象析构时又去访问另一个 thread_local，容易踩到“析构期间访问已析构对象”的坑。 
