必须启用Safari开发菜单才能进行内存分析，否则后续所有步骤无法执行；接着用Performance面板捕获JS堆内存阶梯式上升趋势判断泄漏存在，再通过Memory面板比对堆快照定位泄漏对象，最后强制注销Service Worker并清空缓存验证是否为泄漏源。
当你发现Safari某个标签页打开几分钟后就变卡、风扇狂转、甚至弹出“此网页正占用大量内存”提示，而其他标签页一切正常，说明问题极可能集中在该页面的JavaScript执行逻辑或资源加载行为上——必须用Web检查器直接观测其内存生命周期，不能靠猜。
启用开发菜单并打开Web检查器
没有开发菜单，后续所有内存分析步骤都无法进行。这一步是硬性前提，跳过会导致整个排查流程中断。
点击顶部菜单栏Safari → 设置 → 高级，勾选【在菜单栏中显示‘开发’菜单】。关闭设置窗口，随便打开一个网页（比如safari://extensions），再点顶部“开发”→“显示网页检查器”。
用Performance面板捕获内存变化趋势
Performance面板能实时记录JS堆内存、节点数、监听器数量等关键指标随时间的变化，是判断是否存在内存泄漏的第一道筛子。
在网页检查器中切换到Performance标签页，勾选Memory选项（不勾选则不会采集任何内存数据）。
点击左上角灰色圆形录制按钮→在目标标签页上执行典型操作（例如：滚动长列表、切换Tab、打开又关闭模态框）→持续15秒以上→再次点击录制按钮停止。
停止后，选中Main线程，在下方内存图表中把鼠标悬停在JS Heap曲线上，观察【内存下限是否随操作次数增加而持续上移】。如果从12MB→18MB→24MB→31MB阶梯式抬高，且关闭操作后不回落，基本可断定存在泄漏。
用Memory面板比对堆快照定位泄漏对象
Performance只能告诉你“有泄漏”，Memory面板才能告诉你“谁在吃内存”。需要至少两个快照做差值分析，单个快照毫无意义。
方法一：手动触发两轮操作后抓取快照
第一步：切换到Memory标签页，点击“Take Heap Snapshot”，等待几秒生成Snapshot 1
第二步：回到目标网页，重复刚才引发卡顿的操作（如连续打开/关闭5次侧边栏）
第三步：再次点击“Take Heap Snapshot”，生成Snapshot 2
第四步：在Snapshot 2的筛选框中输入“Objects allocated between Snapshot 1 and Snapshot 2”，重点查看Constructor列中数量异常多的项（比如CustomModal、DataCache、EventEmitter）
方法二：使用Allocation instrumentation on timeline实时追踪
勾选下方Allocation instrumentation on timeline选项→点击录制→执行相同操作→停止→观察火焰图中持续不释放的蓝色长条，它们代表未被GC回收的对象实例。
注意：如果快照中大量出现“(closure)”或“Detached DOM tree”，说明闭包持有DOM引用或事件监听器未解绑——这是前端最常见泄漏源，需立刻检查对应JS文件中的addEventListener和变量作用域。
强制注销Service Worker并清空其缓存
某些PWA类网页会注册Service Worker并在后台长期驻留，即使你关掉标签页，它仍偷偷缓存资源、轮询接口、维持WebSocket连接。常规关闭标签页完全无效。
在网页检查器中切换到Application标签页→左侧展开Service Workers→查看右侧状态为“Activated”的条目→右键选择“Stop”，再右键选择“Unregister”。
接着展开左侧Cache Storage→逐个右键删除所有缓存条目，尤其注意以当前网页域名开头的缓存（如https://app.example.com）。
这一步做完，重新打开同一网页，再跑一遍Performance录制——如果内存下限不再爬升，说明泄漏源就是这个未注销的Service Worker。
