绝不能在构造函数中启动线程，因为此时成员变量（如mutex、atomic等）尚未初始化，线程访问会导致未定义行为；安全方案是用工厂函数+shared_ptr延迟启动，或C++20 jthread配合stop_token协作退出，并在析构函数中确保join()。
要在C++类中让监控线程与对象严格共存亡，避免构造未完成就调用成员函数导致崩溃、析构时线程仍在运行引发std::terminate、或detach()后悬垂访问成员变量等致命问题，必须绕过构造函数内直接启动线程的陷阱，改用延迟初始化+智能指针生命周期绑定+协作退出机制。
为什么绝不能在构造函数里写 std::thread{this}
构造函数执行期间，对象内存已分配、this 指针有效，但成员变量（尤其是std::atomic<bool></bool>、std::mutex、std::condition_variable等）尚未完成初始化。此时若新线程抢先进入成员函数，可能读取未定义值、触发未构造互斥量的lock()——行为未定义，常见表现是段错误或静默数据损坏。更隐蔽的是：即使构造成功，若线程被detach()，对象析构后线程仍可能访问已释放内存，这种 bug 往往只在高并发或 ASan 关闭时暴露。
这一步没有补救办法——只要构造函数体内出现 std::thread{&T::func, this} 或任何隐式捕获 this 的 lambda 启动线程，就必须重构。
安全方案一：工厂函数 + std::shared_ptr 延迟启动
这是 C++11 起最成熟、无依赖、RAII 友好的解法，确保线程启动前对象已完全构造完毕，且引用计数延长对象生存期直至线程结束。
立即学习“C++免费学习笔记（深入）”；
第一步：将构造函数设为私有，禁用栈上创建和默认构造；声明静态工厂函数 create()。
第二步：在 create() 中先调用 std::make_shared<t>()</t> 完成完整构造，再立即调用私有成员函数 start_thread() 启动线程。
第三步：在 start_thread() 内使用 std::thread{&T::worker, this} —— 此时 this 所指对象所有成员均已初始化完毕，线程可安全访问。
【析构函数必须显式检查 thread_.joinable() 并调用 join()】 若忘记此步，std::thread 成员析构时会直接终止程序。
安全方案二：C++20 std::jthread 自动管理（推荐新项目）
若项目已启用 C++20 且工具链支持，std::jthread 可大幅简化代码，自动处理析构时的 request_stop() 和 join()，但前提是线程函数正确响应中断信号。
方法一：使用 stop_token 协作退出
在线程函数参数中接收 std::stop_token，循环内用 stoken.stop_requested() 判断退出条件；启动时传入 [this](std::stop_token stoken) { monitor_loop(stoken); }。
方法二：双保险原子标志 + stop_token
仍保留 std::atomic_bool m_running{true}，在 stop() 中先置 false，再调用 m_thread.request_stop()；线程循环条件写成 while (m_running && !stoken.stop_requested()) —— 防止旧逻辑未及时响应 stop_token 导致卡死。
注意：若线程阻塞在 cv.wait() 或 sleep_for()，需配合 cv.notify_one() 或使用 wait_until(…, stoken) 才能被中断唤醒。
关键收尾操作：析构函数中强制 join()
无论采用 std::thread 还是 std::jthread，析构函数第一件事就是确保监控线程已停止并回收资源。
① 对于 std::thread 成员：在析构函数开头写 if (thread_.joinable()) thread_.join();，不可省略 joinable() 检查，否则对已 join() 过的线程重复调用会崩溃。
② 对于 std::jthread 成员：析构时自动 request_stop() 并 join()，但你仍需保证线程函数内不持有裸 this 的长期引用；若线程中调用其他对象成员，应通过 std::weak_ptr 捕获并 lock() 验证有效性。
③ 若监控逻辑涉及条件变量等待，必须在析构前设置退出标志并调用 cv.notify_one()，否则 join() 将永久阻塞。
【析构函数必须为 virtual（若类可能被继承）】 否则派生类析构时基类析构函数不会被调用，线程无法被正确回收。
