std::function+std::shared_ptr组合无法安全处理回调自动注销，因std::function不暴露捕获列表，无法在被观察者销毁时反向清理回调；需用std::weak_ptr配合ObserverToken实现RAII式自动退订。
为什么 std::function + std::shared_ptr 组合无法安全处理回调自动注销
直接把观察者回调存进 std::vector<:function>> </:function>，看似简单，但一旦回调里捕获了某个对象的 this 指针（比如 [this]{ do_something(); }），而该对象提前析构，后续通知就会触发野指针调用。更麻烦的是，你没法在被观察对象销毁时“反向遍历所有回调并清除它们”——std::function 不提供访问捕获列表的接口。
RAII 风格的观察者必须让“订阅生命周期”与“观察者对象生命周期”绑定，而不是和“被观察者生命周期”强耦合。
- 关键不是“谁负责删回调”，而是“谁拥有这次订阅关系”
- 订阅动作应返回一个可析构的对象（如
ObserverToken），其析构即代表退订 - 被观察者内部只需维护一个弱引用容器（如
std::vector<:weak_ptr>></:weak_ptr>），避免延长观察者生命
如何用 std::weak_ptr<void></void> 实现无侵入式自动注销
不强制要求观察者继承基类，也不依赖 enable_shared_from_this —— 只需在订阅时传入一个能被 std::shared_ptr 管理的句柄（通常是 this 所在对象的 shared_ptr），然后我们把它转成 std::weak_ptr<void></void> 存起来。每次通知前，先 lock()，失败则跳过。
示例核心逻辑：
立即学习“C++免费学习笔记（深入）”；
class Subject {
std::vector<std::pair<std::weak_ptr<void>, std::function<void()>>> observers_;
public:
template<typename T>
auto subscribe(std::shared_ptr<T> owner, std::function<void()> cb) -> ObserverToken {
observers_.emplace_back(owner, std::move(cb));
return ObserverToken{[this, ptr = observers_.end() - 1]() {
auto it = ptr;
if (it != observers_.end()) {
observers_.erase(it);
}
}};
}
<pre class="brush:php;toolbar:false;">void notify() {
// 注意：遍历时不能 erase，先标记再清理
for (auto it = observers_.begin(); it != observers_.end(); ) {
if (it->first.lock() == nullptr) {
it = observers_.erase(it);
} else {
it->second();
++it;
}
}
}};
这里 ObserverToken 是个轻量 RAII 封装，构造时记录迭代器位置，析构时安全擦除对应项；而 notify() 中的 lock() 判断确保只对存活观察者调用回调。
ObserverToken 析构时机与多线程下的竞争问题
单线程下，ObserverToken 在作用域结束时析构，立即从 observers_ 中移除对应项，不会导致重复调用或悬空调用。但多线程下有两处风险：
- 多个线程同时调用
subscribe()→observers_的emplace_back()非线程安全，需加锁（如std::mutex） -
notify()和ObserverToken析构可能并发修改observers_→ 必须统一用同一把锁保护整个容器读写 - 若通知频率极高，锁会成为瓶颈；可考虑用
std::shared_mutex（C++17）分离读/写路径，但注意erase()仍是写操作
别省略锁 —— 即使你认为“只是临时用”，一旦观察者是 UI 对象或网络 handler，多线程退订+通知并发几乎必然发生。
为什么不用 std::signal 或第三方库（如 Boost.Signals2）
std::signal 是 C 风格信号机制，不支持对象生命周期管理；Boost.Signals2 功能完备但体积大、编译慢、依赖重，且其自动断连依赖 boost::shared_ptr 和信号槽绑定时的类型擦除，实际仍需用户显式管理连接对象（connection）。而 RAII 轻量方案的核心价值在于：零依赖、头文件即用、内存布局透明、调试友好。
真正容易被忽略的一点是：很多团队在封装时把 ObserverToken 返回值直接丢弃，等于没订阅。务必在代码审查中检查所有 subscribe() 调用是否被赋值给局部变量 —— 它不是可选的返回值，是资源本身。
