c++双向绑定需手动实现观察者模式，核心是数据变更通知监听器并支持反向写回，关键在引用管理、回调触发和生命周期控制。
双向绑定不是C++原生特性，得自己搭观察者骨架
标准C++没有像Vue或Qt那样的内置双向绑定，必须靠手动维护数据与视图间的同步关系。核心是用观察者模式：数据变更时通知所有监听者，监听者更新后也能反向写回数据。关键不在“绑定”这个词，而在谁持有引用、谁触发回调、谁负责生命周期管理。
常见错误现象：std::weak_ptr没用导致循环引用崩溃；notify()在迭代监听器容器时又新增/删除监听器引发迭代器失效；值拷贝导致通知的是旧快照而非最新值。
- 数据类需持有一个
std::vector<:function>></:function>或更安全的std::vector<:weak_ptr>></:weak_ptr>来存监听器 - 每次修改成员变量（如
m_value）前，先保存旧值；修改后调用notify()，把新旧值都传给监听器（便于做diff更新） - 监听器注册必须返回一个
std::unique_ptr或std::shared_ptr句柄，供使用者显式unobserve()，不能依赖析构自动清理——否则UI控件销毁早于数据对象时会出问题
用std::function + std::shared_ptr实现轻量通知链
比起手写抽象基类+虚函数，用std::function更灵活，尤其适合临时lambda监听。但要注意捕获方式：用[this]容易延长对象生命周期，用[w = weak_from_this()]才是安全做法。
使用场景：配置项热更新、调试面板实时显示变量、游戏属性面板同步角色状态。
立即学习“C++免费学习笔记（深入）”；
性能影响：每次notify()都是线性遍历+函数调用，监听器超20个且高频触发（如帧循环）时，建议加简单开关（m_is_dirty）或合并通知（defer_notify()）。
- 数据类定义通知接口：
void on_value_changed(std::function<void old_val int new_val> cb)</void> - 内部存储用
std::vector<:pair>, std::function<void int>>>></void></:pair>，第一项是句柄（用于解绑），第二项是回调 - 解绑函数要遍历查找并erase，别用
remove_if后不shrink——vector里留着空洞会拖慢后续遍历
Qt信号槽不是“双向绑定”，但能复用为通知底座
如果你已在用Qt，别重复造轮子。Qt的Q_PROPERTY + QMetaObject::connect可支撑基础双向同步，但注意它默认是单向信号驱动，要双向就得手动补反向逻辑。
常见错误现象：Q_PROPERTY声明了WRITE但没实现setter，或setter里忘了调用emit valueChanged(...)；用QObject::connect时信号和槽参数类型不匹配导致静默失败（编译期不报错，运行时不触发）。
- 必须同时提供
READ函数（返回const &）、WRITE函数（接受const &）、NOTIFY信号（参数类型须严格一致） - UI控件（如
QSpinBox）的valueChanged信号要连到数据对象的setter，而数据对象的valueChanged信号再连到控件的setValue——两路独立连接 - 跨线程时，
Qt::QueuedConnection是必须的，否则直接调用可能破坏GUI线程约束
容易被忽略的坑：生命周期、线程、值语义
最常栽跟头的地方不在机制设计，而在三处细节：监听器对象比被监听对象死得早；多线程下notify()没加锁或用了错误锁粒度；用int等基本类型做绑定时，误以为改了局部变量就等于触发了绑定。
比如这段代码看似合理，实则危险：
auto x = obj.value(); x = 42; // 不会触发任何通知真正生效的永远只有
obj.set_value(42)这一条路径。
- 所有setter必须是唯一入口，禁止public成员变量，连
friend类都不该绕过它 - 若支持多线程，通知容器读取用
std::shared_lock，增删用std::unique_lock，避免读写冲突；但别在锁内调用用户回调——可能死锁 - 测试时务必构造“监听器析构 → 数据修改 → 通知遍历”时序，验证是否访问了已释放内存（ASan能抓到）
