泄露分类型，其中定时器属于活引用泄露，对象被意外强引用（如Timer），Leaks无法检测，因此我们使用
一. 难以检测的定时器泄露：
检测难点：隐式强引用、延迟性、小体积导致的“存在感低”。
排查关键：用 Allocations 过滤定时器，结合 Generations 追踪 Persistent 数量变化，辅以堆栈跟踪。
防御核心：用weak打破循环引用，在合适的时机（如页面消失）调用invalidate()或cancel()，或改用 GCD 定时器。
按照步骤可得每次定时器泄露都会导致Persistent 数量持续增加, 正常情况下，定时器在页面退出时应被invalidate()并释放，Persistent 数量应归零或减少。
按照下图步骤操作：
正常情况下，退出后这条timer数据会消失，因为控制器释放了，也是修复成功的标志
双击定时器详情，获取下图右侧的堆栈跟踪信息，查看到createTimerLeak方法，双击蓝色行可跳转到具体代码(不要双击@objc前缀的，跳转过去是无用的信息）
操作到这里，你已经知道是哪段代码出现了泄露
课外知识点：
查看引用计数数量，发现RefCt始终>=1, 代表可能内存泄露了；因为正常释放RefCt=0
引用计数变化轨迹（如Malloc/Retain/Release事件），定位未配对释放的Retain（如Retain +1后无对应Release），从而确认是否因定时器强引用target且未调用invalidate()导致泄漏。
常用面板操作按钮也就是这些，过滤搜索框也很有用
检测循环引用
检测内存增长
