因事件对象生命周期极短，常栈上构造、函数返回即销毁，裸指针传递易导致悬空指针崩溃；Qt 推荐用 const 引用接收，自定义框架应配合 RAII（如 unique_ptr/shared_ptr）或 std::function 管理所有权。
为什么不能直接用原始指针传事件对象
在 Qt、Dear ImGui 或自定义 UI 框架中，事件对象（如 QMouseEvent、ImGuiIO<em></em>、或自定义 Event）生命周期极短，常在栈上构造、函数返回即销毁。若用裸指针（Event*）跨组件传递，极易引发悬空指针——比如回调触发时原对象早已析构，访问 event->type() 就会崩溃。
常见错误现象包括：
- 程序随机 crash 在事件处理函数内，堆栈显示访问非法地址
- 调试时发现
event地址为0xfeeefeee（Windows 已释放内存标记）或0xdeadbeef（Linux 常见） - 仅在 Release 模式下出问题，Debug 下因内存填充侥幸通过
关键判断：只要事件对象不是由接收方负责生命周期管理，就绝不能用原始指针长期持有。
Qt 中推荐用 const 引用 + 信号槽机制传事件
Qt 的事件分发天然基于值语义和对象所有权清晰：事件由 QApplication 创建并传入 QWidget::event()，你只需在重载函数中用 const QMouseEvent& e 接收，不复制、不 new、不 delete。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 在自定义控件中重写
mousePressEvent()，参数是QMouseEvent& event—— 这是安全的引用，且框架保证其有效到函数返回 - 若需异步转发（如延后处理），应提取必要字段（
e.pos()、e.button()），存入QMetaObject::invokeMethod()的参数列表，而非传&event - 绝对避免：
new QMouseEvent(event)后传指针，这既冗余又易泄漏；也别把&event存进成员变量
性能影响：引用传递零开销；拷贝 QMouseEvent 本身也很轻（内部多为整数和简单结构体）。
在无 RAII 框架（如纯 C 风格 UI 库）中如何安全传事件指针
某些嵌入式 UI 或自研框架（如 LVGL、Nuklear）只提供 void* user_data 和裸函数回调，此时必须自己管控事件生命周期。
正确做法是：
- 事件对象统一由事件分发器（如
EventManager）在堆上分配，用std::unique_ptr<event></event>管理 - 分发时移交所有权：调用
callback(user_data, event.release())，接收方获得原始指针但明确承担析构责任 - 或更稳妥：用
std::shared_ptr<event></event>构造，传shared_ptr.get()给 C 回调，同时把shared_ptr存入接收方上下文（如 widget 成员），确保事件存活期 ≥ 使用期
容易踩的坑：
- 把
shared_ptr.get()传入多个不互通的回调，却只在一个地方reset()，导致其他地方仍用已析构指针 - 在回调里对
shared_ptr.get()做delete—— 这会破坏引用计数，后续shared_ptr析构时 double-free
为什么 std::function + lambda 比裸指针更适合事件转发
当需要把事件“转给另一个对象处理”，比如按钮点击后通知 ViewModel，用函数对象比传指针更安全、意图更清晰。
示例：
class Button {
std::function<void(const MouseEvent&)> on_click_;
public:
void set_on_click(std::function<void(const MouseEvent&)> cb) {
on_click_ = std::move(cb);
}
void emit_click(const MouseEvent& e) {
if (on_click_) on_click_(e); // 安全：e 是栈上引用，cb 内部不保存指针
}
};
这样做的好处：
- 调用方无需关心事件内存归属，接收方（lambda 体内）可按需拷贝字段或转发，不碰原始指针
- 可捕获
std::shared_ptr或this，自然绑定生命周期 - 避免了 C 风格回调中常见的
user_data类型擦除和强制转换风险
复杂点在于：如果 lambda 捕获了大型对象或需跨线程执行，得额外处理线程安全与资源释放时机——这时候裸指针反而更难兜底。
