析构函数中直接调用cancel()不安全，因异步任务在其他线程运行，析构时对象已销毁，访问this或成员将导致未定义行为；正确做法是在对象有效时主动调用shutdown()发起协作式取消。
析构函数里直接调用 cancel() 通常不安全
因为异步操作（比如 std::async、boost::asio::async_wait、std::future 关联的后台任务）往往在别的线程运行，而析构函数执行时对象生命周期已结束，若此时强行中断或访问已销毁的资源（如绑定的 this 指针、成员变量），极易触发未定义行为——最常见的是崩溃或内存访问违规。
真正可行的做法不是“在析构里取消”，而是“让取消逻辑在对象还活着时完成”。关键在于：取消必须发生在对象状态仍有效、所有捕获的上下文（如 this、引用、shared_ptr）尚未释放之前。
- 不要在析构函数中直接调用
cancel()或stop_source.request_stop() - 避免在 lambda 中捕获裸指针
this后延迟执行取消逻辑 - 如果使用
std::jthread或std::stop_token，确保 stop request 在析构前发出，且 handler 不访问已析构成员
用 std::stop_source + std::stop_token 主动控制生命周期
C++20 引入的协作式取消机制，是目前最标准、最可控的方式。它不强制终止线程，而是通知任务主动退出，避免资源竞争和状态不一致。
典型结构是：在类中持有 std::stop_source，将 std::stop_token 传给异步任务；任务内部定期检查 token.stop_requested() 或注册回调；外部通过 stop_source.request_stop() 发起取消 —— 这一步必须在对象析构前调用。
立即学习“C++免费学习笔记（深入）”；
class AsyncWorker {
std::stop_source m_stop_source;
std::jthread m_thread;
void do_work(std::stop_token stoken) {
while (!stoken.stop_requested()) {
// 执行一段工作
if (some_condition) break;
}
// 清理资源（此时 this 仍有效）
}
public:
AsyncWorker() : m_thread(&AsyncWorker::do_work, this, m_stop_source.get_token()) {}
~AsyncWorker() {
// ❌ 错误：这里才 request_stop，m_thread 可能还在用 this
// m_stop_source.request_stop();
// m_thread.join(); // 风险：this 已析构，do_work 中访问成员会崩
}
void shutdown() {
m_stop_source.request_stop();
if (m_thread.joinable()) m_thread.join();
}
};
用户必须显式调用 shutdown()，不能依赖析构自动完成。否则一旦忘记，异步任务就变成悬空操作。
用 std::shared_ptr 管理异步任务的生存期
当异步任务需捕获 this 且无法改用 stop_token 时（例如封装第三方回调 API），可借助 std::shared_ptr 延长对象生命周期，确保回调执行时对象仍存在。
核心技巧是：把对象改为继承 std::enable_shared_from_this，在发起异步调用时用 shared_from_this() 捕获，而不是 this；同时在析构前清空所有 pending 的异步句柄（如 boost::asio::steady_timer 的 cancel()），并等待其回调执行完毕。
-
cancel()本身只是标记任务为“已取消”，不会等待回调返回 —— 必须配合io_context::run()或wait()确保回调已退出 - 若使用
boost::asio::post()调度清理逻辑，需保证io_context仍在运行，否则回调永远不会执行 - 多个异步操作时，需维护一个
std::vector<std::shared_ptr<some_handle>>，并在shutdown()中逐个cancel()+reset()
为什么不能依赖 RAII 自动取消？
RAII 的前提是对称性：构造获取资源，析构释放资源。但异步操作的“资源”本质是跨线程的时间窗口和状态一致性，不是简单的内存或句柄。析构时刻与异步任务实际结束时刻天然不同步，强行在析构中同步等待（如 join()、wait_for()）容易导致死锁 —— 尤其当异步任务又反过来等待当前线程（如锁、信号量）时。
更隐蔽的问题是：即使用了 std::jthread，其析构默认调用 join()，但如果线程内代码依赖当前对象的成员变量，而这些变量在析构函数体开始执行后就不可靠了（虚函数表可能已重置、成员已析构），join() 就成了定时炸弹。
所以真正的安全边界只有一个：所有取消请求和同步等待，必须发生在对象成员仍有效的任意时刻 —— 也就是用户可控的 shutdown 流程中，而不是编译器决定的析构时机。
