thread_local仅对静态存储期变量生效，pod类型首次访问时零初始化，类类型首次访问时构造；析构在线程终止前自动调用（若已构造）；不可跨线程取地址。
thread_local 在 C++11 里怎么写才真正生效
不是所有声明了 thread_local 的变量都如你所想那样隔离——它只对静态存储期变量（全局、static 局部、static 成员）起作用，普通局部变量加 thread_local 是编译错误。
-
thread_local不能修饰函数参数、for 循环里的变量、非 static 的类成员（C++20 才支持 non-static 成员） - 初始化时机取决于变量类型：POD 类型在首次访问该线程中该变量时零初始化；带构造函数的类类型，在该线程第一次访问时执行构造（可能抛异常）
- 注意链接性：
extern thread_local int x;合法，但必须在某处有定义（无extern的那行），否则链接失败
为什么用 thread_local 比 pthread_key_t 更安全
手动用 pthread_key_create + pthread_setspecific 容易漏掉析构清理，导致线程退出时资源泄漏；thread_local 对象的析构函数会在线程终止前自动调用（前提是对象已构造）。
- 如果
thread_local变量是类类型，且构造成功，则其析构函数一定在线程结束前被调用（顺序与构造相反） - 但若构造函数抛异常，该线程中该变量视为“未构造”，析构不会发生——这点和普通栈对象一致
-
pthread_key_t需显式注册 destructor 函数，且只能注册一个；thread_local支持每个变量独立生命周期管理
thread_local 和 static 局部变量的区别在哪
两者都“首次访问时初始化”，但作用域和生命周期完全不同：static 局部变量是进程级单例，所有线程共享；thread_local 是每线程一份副本。
- 写
void f() { static int x = 0; ++x; }→ 所有线程共用一个x - 写
void f() { thread_local int x = 0; ++x; }→ 每个线程有自己的x，互不干扰 - 性能上，
thread_local访问通常比普通全局变量慢一点（需查 TLS 表），但远快于pthread_getspecific的函数调用开销
常见崩溃点：跨线程取地址或传递 thread_local 变量
获取 thread_local 变量的地址（比如传给另一个线程的 lambda）是危险操作——那个地址只在当前线程有效，其他线程解引用就是未定义行为。
立即学习“C++免费学习笔记（深入）”；
- 错误示例：
int* p = &my_tls_var; std::thread([p]{ use(*p); }).join();→p在新线程里指向无效内存 - 正确做法：要么把值拷贝过去（
int val = my_tls_var;），要么让目标线程自己访问自己的my_tls_var - 调试时看到
segmentation fault或EXC_BAD_ACCESS且堆栈涉及 TLS 访问，优先检查是否跨线程用了地址
最易被忽略的是初始化顺序：多个 thread_local 变量之间无跨线程初始化顺序保证，同一线程内按定义顺序初始化，但不同线程之间完全独立——别假设线程 A 初始化完，线程 B 就能安全读它的值。
