内存泄漏预防的关键在于设计之初就防住，而非事后修复；需通过raii、defer+closer、disposable钩子、弱引用等机制，将资源释放变为不可绕过的自然环节。
内存泄漏预防的关键不在“发现之后再修”，而在于“设计之初就防住”。真正有效的资源释放，不是靠后期排查工具补救，而是通过结构清晰、职责明确的设计模式，把释放动作变成不可绕过的自然环节。
RAII：让资源生命周期自动绑定对象生命
这是C++中最成熟、最可靠的资源管理范式。核心是：资源在构造时获取，在析构时释放，不依赖人工调用或异常处理逻辑。
- 所有动态分配（内存、句柄、锁等）都封装进类，构造函数中完成申请，析构函数中完成释放
- 避免裸指针传递所有权；改用 std::unique_ptr 或 std::shared_ptr，它们本身就是RAII的实现
- 即使函数中途抛异常，栈展开也会自动调用析构函数，资源不会遗漏
defer + closer：Go中确定性清理的标准路径
Go没有析构函数，但用 defer 配合统一的关闭接口，能达成类似效果。关键不是“记得关”，而是“关的动作写在打开之后、紧邻的位置”。
- 每次打开文件、网络连接、数据库会话，立刻跟一句 defer internal.CloseAndLogError(res, path)
- 项目级定义 io.Closer 兼容的关闭函数，确保所有资源类型行为一致
- 静态分析可强制校验：只要匹配到
$res, err := ...且$res实现io.Closer，就必须有对应 defer
Disposable + 生命周期钩子：响应式与模块化系统的释放契约
在Reactor、SDRPlusPlus这类模块化系统中，资源常跨线程、跨阶段存在。此时需显式定义“谁创建、谁负责停”。
- 每个模块实现 init/start/stop/end 四阶段接口，end() 是唯一清理入口
- 流式处理中，订阅后拿到 Disposable 对象，业务结束时必须调用 dispose()
- 并发任务使用 context.WithCancel，并在函数退出前 defer cancel()，防止 goroutine 泄漏
弱引用与自动淘汰：缓存与集合类的柔性释放
Java/C# 中很多泄漏源于“本该被回收的对象，被静态集合或监听器长期强引用”。这时不能只靠手动清理，要靠设计降低耦合。
- 缓存优先选 WeakHashMap 或 SoftReference 包装值，GC 可介入回收
- 监听器注册后，务必提供配套反注册方法，并在宿主对象销毁时（如 Activity.onDestroy、Bean.destroy）调用
- 静态集合必须配套清理机制——不是“永不清理”，而是提供 clearCache()、evictExpired() 等明确出口
