必须启用safari开发菜单并使用堆快照对比分析定位js内存泄漏源头：先设基准快照，再操作后拍多张快照，用comparison模式查delta为正的detached dom、closure等对象，通过retainers追溯至全局属性或闭包中的泄漏锚点。
要在Safari浏览器中精准定位JavaScript内存泄漏的源头，必须借助其开发者工具中的堆快照功能，完整捕获操作前后的内存状态并逐层展开引用链分析，不能只依赖内存曲线趋势判断。
开启Safari开发者工具与内存调试权限
点击顶部菜单栏「Safari 浏览器」→「偏好设置」→「高级」→勾选「在菜单栏中显示‘开发’菜单」。这一步是后续所有内存分析的前提，【未勾选则整个开发菜单不可见，Memory面板根本无法调出】。
重启Safari使设置生效，确保顶部菜单栏出现「开发」选项。
进入内存检查界面并拍摄首张堆快照
打开待检测的网页 → 点击「开发」→「显示网页检查器」→ 切换到「内存」标签页。
点击「录制内存分配」下方的「拍摄堆快照」按钮，等待几秒直至快照完成并显示在左侧列表中，命名为「Heap Snapshot 1」。
此时不要做任何交互，这张快照代表页面初始稳定态，是后续对比的基准线。
复现可疑操作并拍摄对比快照
执行可能触发内存泄漏的操作，例如：反复打开/关闭模态框、切换路由、滚动长列表、触发大量DOM增删等，持续30秒以上。
操作结束后，再次点击「拍摄堆快照」，生成「Heap Snapshot 2」。
建议重复该过程再拍一张「Heap Snapshot 3」，三快照对比能排除单次GC抖动干扰，更可靠识别持续增长对象。
使用Comparison模式定位泄漏对象
在快照列表中，右键点击「Heap Snapshot 1」→「设为基准快照」；然后选中「Heap Snapshot 2」→ 点击右上角「Comparison」视图。
重点查看「# Delta」列为正数且数值较大的类型，尤其是：
• Detached DOM trees
• Closure（闭包）
• 自定义构造函数（如ModalManager、ChartInstance）
• EventListener（尤其数量突增）
若某类对象Delta持续为+50、+120、+210，说明每次操作都新增实例却未释放，基本可确认泄漏。
深入Retainers追踪引用链源头
在Comparison视图中，点击一个高Delta的构造函数名（如「MyDataTable」）→ 右侧展开「Retainers」面板。
从底部向上读：最底层是「Window」或「Global」，往上逐级查看谁持有该对象——常见泄漏路径是：EventListener → 绑定的闭包函数 → 闭包中引用了组件实例 → 组件实例又持有DOM节点。
若发现某条路径中存在「(global property)」或「(closure)」且其父级是长期存活对象（如document.body、window、单例store），【这就是泄漏锚点，代码中必须切断该引用】。
验证泄漏是否修复
修改代码后，在同一页面刷新 → 重新走一遍「初始快照→操作→二次快照→Comparison」流程。
若之前高Delta的类型现在# Delta趋近于0，且Detached DOM trees数量不再累积，说明修复有效。
