要确认网页是否存在内存泄漏，需用Shift+Esc调出任务管理器查看JS活动内存，并通过miex://devtools生成堆快照分析Detached DOM等异常引用，再结合交互操作与gc()验证活动内存是否回落。
你想确认当前正在浏览的网页有没有偷偷吃掉太多内存，导致手机发烫、卡顿甚至被系统强制杀进程，就得直接看到它占用的本机内存和JavaScript堆内存这两项真实数据。
用任务管理器看网页总内存和JS活动内存
米侠浏览器没有图形化入口，但支持快捷键调出底层任务管理器，这里能实时显示每个标签页的物理内存与JS堆内存占用。
按下 Shift + Esc 快速唤出任务管理器——比从菜单点进去快得多，尤其页面已开始卡顿时更不能等。
右键点击列标题任意空白处 → 勾选「JavaScript 内存」→ 此时新增一列，格式为“总内存 (活动内存)”，例如“142.6 MB (93.1 MB)”。
【括号内的“活动内存”才是关键指标，它代表当前仍可被JS代码访问的对象实际占用，持续上涨即存在泄漏风险】。
在“类型”列为“标签页”的行中，找到“名称”与你当前地址栏标题一致的那条记录；若标题被截断，鼠标悬停即可浮出完整网页标题。
用DevTools抓取堆快照定位内存大户
任务管理器只能看总量，要揪出是哪个对象、哪段代码在占着内存不放，必须进开发者工具生成堆快照。
方法一：在地址栏输入 miex://devtools 并回车，进入开发者工具首页。
点击顶部「Memory」标签页 → 点击「Take heap snapshot」按钮 → 等待几秒，快照自动生成并加载完成。
在左侧快照列表中点击刚生成的条目 → 右侧按 Constructor 筛选，重点关注 Array、Object、Closure、Detached DOM tree 这几类占比异常高的构造器。
展开某高占比项，右侧显示具体引用链；若发现“[[Detached]]”标记却仍被全局变量或事件监听器持有，就是典型内存泄漏源头。
观察交互后内存是否回落
静态数值没意义，必须操作页面并验证内存能否被正常回收。
第一步：在目标网页按 Ctrl + R 强制刷新，绕过缓存，等待完全加载后记下“内存”列和“JavaScript 内存”列初始值。
第二步：滚动页面到底部→再滚回顶部→点击几个主要按钮→等待3秒；观察两列数值变化。
第三步：在控制台输入 gc()（仅限开启mi://flags中“Developer Tools Experiments”的调试模式）手动触发垃圾回收，或等待自动GC发生。
若“活动内存”数值在操作+GC后未明显下降，甚至继续爬升，基本可确认存在JS内存泄漏。
