直接在构造函数启动监控线程可行，但须满足三前提：对象生命周期稳定、退出标志已初始化、线程析构前必join；否则易触发未定义行为。
直接在构造函数里启动后台监控线程是可行的，但必须满足三个硬性前提：对象生命周期已稳定、退出标志已完成初始化、线程句柄析构前必 join。否则极易触发未定义行为——比如读取未初始化的 std::atomic_bool，或析构时 std::thread 仍 joinable() 导致程序直接 terminate。
std::thread 成员声明顺序决定是否 crash
常见崩溃不是因为“用了 thread”，而是成员声明顺序错了：std::thread 成员若声明在 std::atomic_bool m_stop{false} 之前，构造函数中用 this 启动线程时，m_stop 还没被初始化，线程一运行就读未定义内存。
-
std::atomic_bool必须声明在std::thread成员之前 - 线程启动必须放在构造函数初始化列表里，例如：
t_(&Monitor::run, this) - 禁止在构造函数体里调用
std::thread构造函数（此时部分成员可能未初始化） - 若类继承自
std::enable_shared_from_this，且对象由std::make_shared创建，shared_from_this()才能在初始化列表中安全使用
析构时必须显式唤醒 + join，不能依赖“等它自己醒”
监控线程常阻塞在 std::condition_variable::wait 或 sleep_for 上，主线程进入析构时若只设 m_stop.store(true) 就直接调 t_.join()，会卡住数秒甚至永久阻塞。
- 析构函数第一行必须写：
m_stop.store(true, std::memory_order_release) - 紧接着调用
cv_.notify_one()（如果用了条件变量），或向 pipe / event 写 dummy 数据强制唤醒 - 最后才检查
t_.joinable()并调t_.join() - 绝对不要用
detach()—— 一旦 detach，你彻底失去对线程的控制权
std::jthread 看似省事，但坑藏得更深
std::jthread 析构时自动 join() 是真的，但它不解决对象生命周期问题。传进去的 this 还是裸指针，线程还在跑而对象已销毁，照样访问野指针。
- 仍需搭配
std::shared_ptr+std::weak_ptr，例如：[self = weak_from_this()]() { auto p = self.lock(); if (!p) return; ... } - 优先用
std::jthread的std::stop_token替代手写std::atomic_bool，语义更清晰 -
std::stop_token不可重置：一次request_stop()后不能再 reset —— 这是设计约束，不是 bug - 线程函数内必须主动轮询
st.stop_requested()，否则request_stop()完全静默失效
真正容易被忽略的是：协作式退出不是“设个标志就完事”，而是要把唤醒路径、内存序、对象生存期、阻塞点响应全部串成一条无断点的链。少一环，程序就在某个深夜退出时随机崩给你看。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
