IndexedDB 无法原生支持空间索引，需应用层实现：可用 Geohash 拼接主键实现粗筛、RBush 构建内存 R-tree 并持久化、按地理网格分片多 objectStore 存储，所有计算密集操作应移至 Web Worker 执行。
IndexedDB 本身不支持空间索引（如 R-tree、Quadtree 或地理哈希），无法直接对经纬度做高效范围查询或邻近搜索。要实现大规模地理坐标的空间索引，必须在应用层构建并维护辅助索引结构，再结合 IndexedDB 的键路径（keyPath）和游标（cursor）能力模拟空间查询逻辑。
用地理哈希（Geohash）作为复合主键
Geohash 将二维经纬度编码为字符串，具有前缀相似性（越长前缀，位置越接近）。可将其与时间戳、ID 等拼接作为 objectStore 的 key，利用 IndexedDB 的字典序范围查询能力实现“矩形区域粗筛”。
- 存储时：将坐标转为 7～9 位 Geohash（平衡精度与粒度），例如 u09q8z（约 1km²），再拼接唯一 ID 构成主键：
"u09q8z_abc123" - 查询时：根据目标区域生成一组前缀（如中心点周围 8 个相邻 Geohash 前缀），用
IDBKeyRange.bound()分别查询每个前缀范围，合并结果后二次过滤（剔除落在前缀内但实际超出地理边界的点） - 注意：Geohash 在两极和国际日期变更线附近有突变，需在客户端做简单校验（如计算 Haversine 距离）
自建 R-tree 索引并持久化到 IndexedDB
使用轻量级 JS R-tree 实现（如 RBush），构建内存索引后序列化存入 IndexedDB。适合读多写少场景，且支持精确矩形/圆形查询。
- 初始化：从 IndexedDB 加载全部坐标点 → 构建 RBush 树 → 存入一个专用 objectStore（如
"spatial_index"），值为{ tree: serializedTree, version: 1 } - 更新：插入/删除点时，先更新内存树，再批量写回；或采用“懒更新”策略——仅在查询前检查数据版本是否一致，不一致则重建
- 查询：调用
search([minLng, minLat, maxLng, maxLat])获取候选 ID 列表，再用get()批量查原始坐标（避免全量遍历）
分片 + 多 objectStore 按区域划分
对全球或业务覆盖区域做静态网格划分（如按经度每 10°、纬度每 5° 切块），每个格子对应一个独立 objectStore（如 "grid_120_30" 表示东经 120°、北纬 30° 区域）。适用于热点区域集中、查询范围明确的场景。
立即学习“Java免费学习笔记（深入）”；
- 写入：坐标落点计算所属格子 ID（
Math.floor(lng / 10) + '_' + Math.floor(lat / 5)），存入对应 store - 查询：根据目标矩形反算涉及的所有格子 ID，发起多个并发
getAll()请求，结果合并去重 - 优势：天然水平拆分，规避单 store 性能瓶颈；缺点是跨格子查询开销略高，且格子大小需预估（太细→store 过多；太粗→单 store 数据膨胀）
配合 Web Worker 避免主线程阻塞
空间索引构建、Geohash 计算、R-tree 查询等计算密集操作应移至 Web Worker，通过 postMessage 与主线程通信，防止 UI 卡顿。
- Worker 内：封装 Geohash 工具、RBush 实例、格子映射逻辑，暴露统一查询接口（如
searchByBounds({ lng1, lat1, lng2, lat2 })） - 主线程：只负责调用 worker 并处理返回的 ID 列表，再触发 IndexedDB 的
get()或getAllKeys()获取详情 - 注意：IndexedDB 的
open()和事务不能跨线程，worker 中只能执行纯计算或调用主线程代理的 DB 操作
