主线程退出时子线程访问全局或thread_local对象必然崩溃，因全局对象在所有线程join前即被销毁，而thread_local析构更晚且顺序不可控；std::jthread可确保线程安全结束后再析构全局对象。
主线程退出时，子线程还在跑，全局对象和 thread_local 对象的析构顺序不可控，崩溃几乎必然发生——这不是偶发 Bug，是标准行为。
为什么主线程 return 后子线程访问全局/静态对象会崩溃
主线程执行完 main() 或调用 exit() 时，C++ 运行时会立即开始销毁所有非局部静态对象（包括全局变量、命名空间作用域 static 变量），这个过程不等待任何仍在运行的子线程。一旦某个全局对象被析构，其内存被释放或资源被关闭，子线程再访问它（比如调用成员函数、解引用指针、写日志）就会触发未定义行为，常见表现为段错误或访问已释放内存。
- 崩溃不是“运气不好”，而是标准保证的销毁时机：全局对象销毁发生在所有线程 join 完成之前
- 哪怕子线程只读取一个
static const int config_flag，若该变量在子线程读取前已被销毁（例如定义在另一个编译单元），结果仍是未定义 -
std::atexit注册的函数也受此影响，不能依赖全局状态
thread_local 和全局对象之间的析构依赖会直接翻车
当一个 thread_local 对象的析构函数里试图访问全局对象（比如单例、配置管理器、日志器），而该全局对象已在当前线程退出前被主线程销毁，就会立刻崩。更糟的是，多个 thread_local 对象之间也没有析构顺序保证，A 依赖 B，B 却先于 A 析构，同样出问题。
- 典型错误：
thread_local std::unique_ptr<logger> logger</logger>+ 全局std::unique_ptr<config> g_config</config>，logger 析构时尝试通过g_config->log_level()写日志 - 即使都在同一编译单元定义，
thread_local的销毁时机仍晚于全局对象（线程结束时才触发），但全局对象早已没了 - 不要指望“我把全局对象定义在最后”就能控制顺序——跨编译单元顺序未定义，且
thread_local不参与该顺序
std::jthread 是目前最稳妥的退出同步方案
C++20 的 std::jthread 在析构时自动调用 join()，确保线程函数执行完毕、本地栈展开完成、thread_local 对象析构完毕后，才允许主线程继续走全局析构流程。这是从根源上切断“子线程访问已销毁全局”的通路。
立即学习“C++免费学习笔记（深入）”；
- 替代
std::thread：把std::thread t{func}改成std::jthread t{func}，无需手动t.join() - 支持可取消性：传入
std::stop_token，让工作函数能响应中断，避免死等 - 注意：仍需确保
func内部不持有对全局对象的裸指针或引用；优先用局部拷贝或 RAII 封装后的资源句柄
真正安全的全局状态访问必须绕过析构期
如果你必须在子线程中访问某种“全局”配置或服务，唯一可靠方式是让它**不参与程序退出时的自动析构流程**——也就是不作为全局/静态对象存在，而改用延迟初始化 + 显式生命周期管理。
- 用局部静态变量实现 Meyer’s Singleton：构造在线程首次调用时发生，析构由该线程自己负责（即
thread_local级别），不依赖全局析构顺序 - 将关键服务封装为 RAII 类型，由每个线程在入口处构造、出口前显式销毁（比如
auto service = ServiceHandle::acquire()） - 避免任何跨线程共享的裸指针、FILE*、void* 句柄；改用
std::shared_ptr并确保所有持有者都在线程内释放 - 工具验证：用
-fsanitize=address编译，崩溃时 ASan 能准确定位到“use-after-free”发生在哪个全局变量上
最易被忽略的一点：崩溃往往不出现在你写的逻辑里，而出现在标准库内部——比如 std::cout 的缓冲区在全局析构时被清空，此时子线程还调用 std::cout << "done"，就直接踩进已释放内存。这种隐式依赖比显式调用更难排查。
