WeakRef 是探针而非开关，仅允许对象被回收但不主动通知；实现视口外自动销毁需结合 IntersectionObserver 主动清理、用 WeakRef 包裹可重建中间态数据，并及时切断弱引用路径。
WeakRef 本身不销毁数据，也不能直接触发清理动作；它只提供一种“可被回收但暂不阻断访问”的持有方式。要实现“视口外自动销毁”，关键不是靠 WeakRef 单独工作，而是把它作为信号探测器，配合显式的生命周期管理策略——比如监听元素脱离可视区域、主动释放关联资源、避免强引用滞留。
核心逻辑：WeakRef 是“探针”，不是“开关”
WeakRef 的作用是让 JS 引擎在没有其他强引用时，允许对象被垃圾回收。但它不会主动通知你“该删了”，也不会自动调用销毁函数。在大型异步数据集场景中（例如虚拟滚动里成百上千条记录），你真正要控制的是：
- 哪些数据项当前属于“活跃视口”，需要保持解码/解析/渲染状态
- 哪些已滑出视口、长期未访问，应主动丢弃其内存占用（如 JSON 解析结果、格式化后的对象、缓存的 DOM 片段）
- 如何避免因缓存结构自身持强引用，导致本该释放的数据无法 GC
用 WeakRef 管理“可重建”的中间态数据
适合放进 WeakRef 的，是那些能快速重建、不持久依赖外部状态的数据片段。例如：
- 某条记录经 transform 函数处理后的轻量视图对象（非原始大数据 blob）
- 已解析但未渲染的 HTML 字符串（用 DOMParser 生成的 DocumentFragment）
- 仅用于临时计算的数组切片或 Map 映射（不含闭包、事件监听器等强引用链）
把这些对象包裹进 WeakRef 存入 Map，键建议用唯一 ID（如 recordId + versionHash）。每次读取前必须调用 deref()，并接受返回 undefined 的可能性——这不是错误，而是设计预期。
视口变化时，主动清理不可恢复的数据
WeakRef 不解决“该不该留”的决策问题。你需要结合 IntersectionObserver 或滚动位置计算，明确标识哪些 recordId 已完全离开可视区域超过阈值（比如 2 屏之外）：
- 对这些 ID，在缓存 Map 中尝试
weakRef.deref()；若返回有效值，说明它还活着，此时应手动调用清理逻辑（如fragment.remove()、abortController.abort()） - 立即从 Map 中
delete(key)，切断最后的弱引用路径，加速 GC - 如果数据背后绑定了 fetch 请求、Web Worker 通信或 IndexedDB cursor，需同步终止或关闭
避免常见陷阱
很多团队误以为 WeakRef 能“全自动兜底”，结果仍出现内存持续增长。注意以下几点：
- WeakRef 不持有原始数据源（如 ArrayBuffer、大型 JSON 字符串），它只包装 JS 对象。若原始数据还在全局变量或闭包里，WeakRef 毫无意义
- 不要把整个 record 对象塞进 WeakRef 后就不管了——如果 record 内部有 addEventListener、setTimeout、Promise 链，这些都会形成强引用，阻止回收
- FinalizationRegistry 在这里帮助有限：它触发时机不确定，且无法保证与视口逻辑同步；更适合做兜底日志或资源泄漏报警，而非主清理通道
