BroadcastChannel 本身不持DOM引用，但不当使用会因重复创建、闭包捕获或未调用close()导致内存增长；需检查实例数量、回调闭包、关闭时机及辅助缓存。
BroadcastChannel 本身不持有页面 DOM 或业务数据的引用，但不当使用会间接引发内存增长和“假性残留”——表面看是 Channel 没释放，实则是监听函数闭包捕获了大量上下文，或重复创建实例未清理。识别这类问题，关键不在 Channel 对象本身，而在它绑定的回调和生命周期管理。
检查是否重复创建 BroadcastChannel 实例
一个常见误操作是在组件多次挂载（如 React useEffect 多次执行、Vue watch 触发）中反复 new BroadcastChannel('xxx')。虽然浏览器允许同名频道共存，但每个实例都独立持有 onmessage 回调，导致同一消息被同一个页面处理多次，同时闭包持续引用外层作用域变量。
- 在控制台执行 Object.keys(window).filter(k => k.includes('bc') || k.includes('channel'))，快速查看是否有多个疑似 BroadcastChannel 实例挂在全局
- 打开 DevTools 的 Memory 面板 → Take heap snapshot，筛选 constructor 名为 BroadcastChannel 的对象数量；正常应为 1（单例），若出现 5+ 个，大概率存在重复初始化
- 搜索代码中所有 new BroadcastChannel( 出现位置，确认是否包裹在可重入逻辑里（如未加 guard 的 useEffect、mounted 钩子、或事件监听器内部）
排查 onmessage 回调引起的闭包泄漏
真正吃内存的往往不是 BroadcastChannel 实例，而是它绑定的 onmessage 函数所捕获的 this、props、state、ref、大型数组等。尤其当回调内直接调用 setState 或触发渲染时，整个组件树可能被意外保留在内存中。
- 在 onmessage 回调开头加一句 console.trace('bc message received')，观察控制台堆栈是否频繁出现、是否总关联到已卸载组件（如 “Warning: Can’t perform a React state update on an unmounted component”）
- 用 Chrome DevTools 的 Performance 面板录制一段操作 → 查看 JS Heap 曲线是否阶梯式上升，再点开对应帧的 “Allocation instrumentation on timeline”，定位哪些对象在消息到达后被分配且未释放
- 避免在回调中直接使用箭头函数闭包访问组件内部状态；推荐解耦：用纯函数处理 event.data，再通过安全方式（如 useRef + flag 判断）通知组件更新
验证 bc.closed 状态与显式 close() 调用时机
BroadcastChannel 实例不会自动销毁，必须手动调用 bc.close()。若忘记关闭（尤其在 SPA 页面切换、组件卸载时），实例虽不再收消息，但其监听器仍驻留内存，且可能因未解绑而阻断 GC。
- 在组件卸载前（如 useEffect cleanup、beforeUnmount）打印 bc.closed —— 若为 false，说明未 close
- 不要依赖 window.beforeunload/close 事件来 close，该事件不可靠（如进程崩溃、强制关页）；应在明确的生命周期终点调用
- close() 后再次 postMessage 不报错但静默失败，可用 bc.addEventListener('messageerror', ...) 捕获异常辅助判断是否已失效
区分真实泄漏与正常缓存行为
BroadcastChannel 无内置缓存，但开发者常配合 localStorage 或内存 Map 做消息去重或状态同步，这些辅助结构容易被误认为是 Channel 引起的泄漏。
- 检查是否有类似 window.__bc_cache = new Map() 的全局缓存对象，确认其 size 是否随标签页打开时间线性增长
- 若使用自定义消息 ID 去重，确保 Map 的 key 被及时 delete（例如只保留最近 100 条），而非无限累积
- 对比关闭所有其他标签页后，仅留当前页运行一段时间，再拍内存快照 —— 若 BroadcastChannel 相关对象仍不下降，才需深入排查
