不能用裸指针跨线程管理thread_local存储，因各线程TLS内存独立，&x在t1中有效地址在t2中无效，导致段错误或垃圾值；唯一安全用法是本线程内使用。
不能用裸指针跨线程管理 thread_local 存储——每个线程的 thread_local 变量是独立副本，地址互不相通，传地址过去解引用就是段错误或垃圾值。
为什么 &thread_local 变量在线程间传递必然出错
编译器为每个线程在 TLS 段（或 Windows 的 TlsGetValue 查表机制）中分配独立内存块。&x 在线程 t1 中返回的地址，在 t2 中根本无效。即使变量声明为全局 thread_local int x，两次取地址结果也绝不会相同。标准明确禁止将该地址作为“共享句柄”跨线程使用。
- 常见错误现象：
segmentation fault、读到随机整数、程序偶发崩溃 - Windows 下更隐蔽：TlsSetValue 存的是指针值，但
TlsGetValue返回nullptr无法区分“未设置”和“存了空指针”，必须配额外标志位 - 即使你用
std::this_thread::get_id()打印地址，看到的也是本线程视角，对其他线程毫无意义
thread_local + 指针的唯一安全用法：仅限本线程内
指针可以合法用于线程内部间接访问，前提是生命周期可控、不逃逸出当前线程上下文。
- 把
thread_local std::vector<char></char>的缓冲区首地址传给 C API：write(fd, &buf[0], size) - 用
thread_local FILE*管理线程专属日志文件句柄，只在本线程调用fputs、fclose - 线程单例懒初始化：
thread_local std::unique_ptr<logger> g_logger;</logger>——g_logger.get()的值只能在本线程用，绝不能塞进全局队列或原子变量里供其他线程读取
想真正共享指针？用 C++20 atomic_shared_ptr
如果你需要多个线程安全地读写同一个智能指针（比如切换配置对象、更新状态句柄），std::atomic<:shared_ptr>></:shared_ptr> 是正解。它提供原子 load() / store() / compare_exchange_weak()，底层无锁或细粒度锁，性能远超手动加 std::mutex。
立即学习“C++免费学习笔记（深入）”；
- 示例：
std::atomic<:shared_ptr>> g_config;</:shared_ptr>，writer 调用g_config.store(new_cfg)，reader 调用g_config.load()获取副本 - 注意：它保护的是指针本身的读写，不是所指对象的内容；若要修改
*g_config.load()，仍需对象内部同步（如成员变量加std::atomic或锁） - 不支持
std::unique_ptr原子化，因为其所有权语义与原子操作冲突；必须用shared_ptr配合引用计数
Windows TLS API 手动存指针的硬坑
绕过 thread_local 直接调用 TlsAlloc/TlsSetValue 存裸指针，风险极高：
- 存的指针必须指向堆内存（且在线程退出前不释放），或指向本线程栈上长期存活的对象；绝不能存主线程栈变量地址
- 必须在所有线程终止后、进程退出前调用
TlsFree，否则 TLS 插槽泄漏（Windows 默认仅 1088 个） -
TlsGetValue返回nullptr不代表没设值——可能是你存的就是nullptr，得靠额外布尔标志位区分“未初始化”和“已置空”
这些细节极易遗漏，而 thread_local + RAII 封装（如 std::unique_ptr）能自动规避大部分生命周期问题；手动 TLS 管理只应在极特殊场景（如 hook 系统函数、编写运行时库）中考虑。
