weakset 不提供异步清理标记能力，也不影响 gc 频率；它仅通过弱引用避免阻碍 dom 节点回收，无 delete/clear/size/遍历方法，条目消失是 gc 副产品而非主动行为。
WeakSet 本身不提供“异步清理标记”能力，它也不参与或影响 GC 频率——GC 由 JavaScript 引擎自动调度，开发者无法控制其时机或频率。WeakSet 的作用是不阻碍节点被回收，而非“触发”或“加速”回收。所谓“异步清理标记”，本质是误用术语；WeakSet 只做一件事：弱引用标记，且无需你清理。
WeakSet 不是清理工具，而是“不添乱”的标记容器
WeakSet 存 DOM 节点时，不会延长其生命周期。只要节点从 DOM 中移除，且没有其他强引用（如事件监听器、闭包变量、Map/Set/全局变量持有），下一次 GC 运行时，该节点连同 WeakSet 中的记录会一并消失。
- WeakSet 没有
delete()、clear()或size，也不能遍历——这是设计使然，确保引擎能安全回收 - 调用
weakSet.has(node)返回false，只说明“此刻节点已不可达”，不表示“刚刚被清理” - 不存在“标记待清理”或“延后删除”的机制；WeakSet 中的条目消失是 GC 的副产品，不是 WeakSet 主动行为
真正影响 GC 频率的关键在强引用管理
GC 频率升高，往往源于内存持续增长——而增长主因是意外的强引用滞留。WeakSet 无法解决这些问题，但能帮你避开一个常见陷阱：
- ❌ 错误做法：用
new Set()记录已渲染节点 → 节点即使被remove()，仍被 Set 持有，长期驻留内存 - ✅ 正确做法：用
const rendered = new WeakSet()替代 → 节点卸载后，WeakSet 自动“失忆”，不拖慢 GC - ⚠️ 注意：若节点还绑着
addEventListener，或被Map.set(el, data)持有，则 WeakSet 无效——强引用链未断，GC 就不会启动回收
配合 WeakMap 实现安全的关联数据绑定
如果需要为已渲染节点附加状态（如初始化参数、观察器实例），应搭配 WeakMap 使用，而非自行维护清理逻辑：
-
const initOptions = new WeakMap()存每个节点的配置 -
const resizeObs = new WeakMap()存每个节点对应的ResizeObserver - 节点移除后，这些 WeakMap 条目自动失效，无需
obs.unobserve(node)后再手动map.delete(node) - 注意：WeakMap 的 value 仍是强引用，所以 observer 实例本身需显式
unobserve或disconnect，否则 observer 对象会滞留
调试与验证建议（仅限开发环境）
生产环境不要依赖任何“清理完成”信号，但调试时可辅助确认 WeakSet 是否按预期工作：
- Chrome DevTools 中执行
gc()（需开启--js-flags="--expose-gc"）强制触发一次 GC - 之后检查
rendered.has(el)是否返回false，验证节点是否已脱离 WeakSet - 用
Performance.memory.usedJSHeapSize观察内存趋势，比单次has()结果更可靠 - 避免在代码中写
if (!rendered.has(el)) { /* 假设 el 已销毁 */ }—— WeakSet 不保证实时性
