weakref 仅提供弱持有，不自动销毁数据；需结合视口监听、主动清理和安全访问机制实现视口外数据释放。
WeakRef 本身不能实现“视口外自动销毁”，它只负责不阻止对象回收；真正触发销毁必须由你主动判断并执行。构建这类管理器的关键，是把 WeakRef 当作**安全的弱持有手段**，配合显式的视口状态监听、生命周期钩子和手动清理逻辑。
核心思路：弱持有 + 视口感知 + 主动清理
大型图表数据集（如百万级时间序列、地理热力网格）往往体积大、构造成本高，但用户同一时刻只看到其中一小块（即当前视口）。与其让整个数据集长期驻留内存，不如只对当前可见部分保持强引用，其余部分交由 WeakRef 持有——一旦被 GC 回收，就视为“已销毁”；而更重要的是，在视口变化时，主动释放不再需要的数据块。
- WeakRef 不用于包裹原始数据集本身（比如一个巨型 Float32Array），而是包裹它的轻量封装对象（如
{ id, bounds, dataRef }），确保该封装对象可被 GC，且不拖累数据本体 - 真正的“销毁”动作（如
dataRef = null、arrayBuffer?.detach()、或触发worker.terminate()）必须在检测到数据块完全移出视口后立即执行 - WeakRef 的作用是兜底：当封装对象因其他原因（如意外丢失强引用）提前被 GC，缓存中不会残留无效句柄，避免后续误用
结构设计：Map + WeakRef + 视口监听器
推荐使用 Map<string weakref>></string> 存储所有已加载的数据块，key 是唯一标识（如 "time_1620000000_1620003600" 或 "tile_z5_x12_y8"），value 是对 DataChunk 实例的弱引用。每个 DataChunk 应包含：
- bounds：描述其覆盖的坐标/时间范围，用于与当前视口做快速重叠判断
- dataRef：指向实际数据（ArrayBuffer、TypedArray、或 Web Worker ID）的强引用
- lastUsed：时间戳，便于 LRU 辅助淘汰（非必需，但建议）
每次图表滚动/缩放时，调用 updateVisibleChunks(newViewport)，遍历 Map 中所有 key，检查对应 chunk 是否仍在视口内。若不在，且该 chunk 当前未被任何 UI 组件强引用，则调用 chunk.destroy() —— 这个方法应显式释放 dataRef 并清空内部状态。
安全访问：每次 get 都要 deref + 验证
不能假设 weakRef.deref() 返回的对象一定有效或仍匹配当前视口。正确流程是：
- 从 Map 获取 WeakRef
- 调用
deref()，若返回null，说明已被 GC，需重新加载 - 若返回实例，再检查
chunk.bounds.intersects(viewport)；不相交则视为“过期”，不返回，也不复用 - 若相交，才更新
chunk.lastUsed = Date.now()并返回数据
这样既利用了 WeakRef 避免内存泄漏，又通过主动验证确保数据语义正确——“弱持有”不等于“可随意使用”。
补充：FinalizationRegistry 不适合此处
不要用 FinalizationRegistry 来响应数据销毁。因为：
- 它的回调发生在 GC 之后，无法获知当时视口状态，也无法区分“因视口移出被主动销毁”和“因内存压力被 GC”
- 回调中拿不到原始数据引用，无法做任何资源释放操作（如
transferToWorker或postMessage(null)） - 注册键若用字符串 id，回调里只能删 Map 中的 key，但此时 chunk 可能早已被主动清理过，导致重复操作或报错
FinalizationRegistry 在这里是冗余的。视口驱动的销毁是确定性行为，应由业务逻辑控制，而非依赖不可控的 GC 时机。
