B 端长会话前端内存监控告警：usedJSHeapSize 基线漂移导致误报，怎么区分慢泄漏和正常增长？

【背景】 B 端运营中台（React 18 + Vite 5），运营同学单会话经常挂 8 小时以上不刷新。今年把错误监控打通后，下一步想上「运行时内存监控 + 告警」，目标把「下午越用越卡、最后白屏」这类问题从工单倒查变成事前告警。

【现象】 用 performance.memory.usedJSHeapSize 每 30s 采样上报，跑了两周，告警全是噪音：

1. 不同页面内存基线差 3–5 倍（报表页天然重），用全局阈值（如 1.5GB）要么漏报要么误报；
2. 用「近 7 天同页面中位数」做基线，高峰期（10:00–11:00 大家都开大报表）基线被抬，告警反而变钝；
3. 用「增长率（MB/min）」做信号，用户加载一个 2 万行大表格就触发，但真正的慢泄漏（约 10MB/h）增长率太低，永远报不出来；
4. usedJSHeapSize 受 GC 周期影响，采样点落在 GC 前后能差 300MB+，同一会话 1 分钟内波动剧烈。

【已尝试】

• 全局固定阈值 → 误报为主；
• 按页面分基线（近 7 天 P50）→ 高峰变钝；
• 增长率告警 → 抓不到慢泄漏；
• 换 performance.measureUserAgentSpecificMemory() → 更准，但需要 crossOriginIsolated（COOP+COEP），我们生产是混合内容 + 第三方 iframe，开不了，pass；
• 离线 Heap Snapshot 那套（社区 #162 讲得很细）我们也会用，但那是「出事了再排」，我要的是「没出事就报」的运行时信号。

【期望得到的答案形态】

1. 你们生产里「运行时内存监控」到底用什么信号（usedJSHeapSize？JSHeapSizeLimit 占比？还是别的），采样频率多少，为什么？
2. 怎么把「慢泄漏」和「用户加载了大数据」区分开——是结合 DOM 节点数 / 事件监听器数一起看，还是有别的特征？
3. 告警阈值怎么定才不误报：绝对值、占比、还是相对自身历史基线的偏移？基线窗口取多长、用什么分位数？
4. 如果你们有「采样 + 上报 + 告警」的完整链路，贴一下关键代码或配置（采样器、上报字段、告警规则），我照着抄。
5. 顺带问一句：usedJSHeapSize 只在 Chromium 有，Safari/Firefox 你们怎么补的，还是直接放弃非 Chromium 的内存监控？

我手上有最小复现的采样器和两周原始数据，需要的话评论区给地址。