IndexedDB适合存储拓扑图等复杂结构化数据，应按语义拆分为nodes、edges、graphMeta等objectStore，直接存原生数组避免JSON序列化，用事务批量写入并建索引提升查询效率。
IndexedDB 是浏览器中适合存储复杂结构化数据的方案，尤其适合缓存拓扑图这类包含节点（Node）、连线（Edge）、分组、层级、样式等多维信息的数据。关键不是“能不能存”，而是如何设计 schema、序列化策略和读写逻辑，让拓扑图数据可持久、可查询、可增量更新。
用对象存储设计拓扑图数据结构
不要把整张图塞进一个 value 里。建议按语义拆分为多个 objectStore：
-
nodes：每个节点存 id、x、y、width、height、label、type、metadata（如设备型号）等字段；主键设为
id（字符串或数字均可） -
edges：每条连线存 id、sourceId、targetId、points（折线坐标数组，如
[[100,200],[150,250],[200,200]]）、style、label 等；主键也用id -
graphMeta（可选）：存图名、缩放比例、画布偏移量、版本号等全局状态，只存一条记录，key 可设为
"current"
这样设计便于按节点 ID 快速查点、按 sourceId 查出边、支持增删单个元素而不重写全图。
正确处理坐标数据的序列化与反序列化
拓扑图中的坐标通常是浮点数数组（如 points: [[x1,y1], [x2,y2], ...]），IndexedDB 原生支持 Array、Object、Number、Date 等类型，无需 JSON.stringify / parse——直接存原生数组即可，性能更好、精度不丢失。
立即学习“Java免费学习笔记（深入）”；
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
注意两点：
- 避免存函数、DOM 引用、undefined 或循环引用对象（会报 DataCloneError）
- 若节点含 canvas 绘图路径（Path2D）或 SVG 元素，需转为可序列化格式（如 pathData 字符串或简化后的点序列）
批量写入与事务控制保障一致性
加载一张含数百节点/连线的图时，应使用单个事务一次性写入，避免多次 openCursor 或 add 调用导致部分失败、状态不一致：
- 用
transaction(['nodes','edges'], 'readwrite')同时打开多个 store - 对 nodes 和 edges 分别调用
store.put()，所有操作在同一个 transaction 内完成 - 监听
transaction.oncomplete再触发 UI 渲染，确保数据已落盘 - 若某次更新只改了 3 个节点，就只 put 这 3 条，不用重写全部 —— 利用 IndexedDB 的 key 更新机制实现精准同步
带索引的快速查询能力
为提升交互响应速度，给常用查询字段建 index：
- 在
edgesstore 中，用createIndex('bySource', 'sourceId')，支持“查某节点所有出边” - 在
nodesstore 中，用createIndex('byType', 'type')，方便筛选服务器、交换机等特定类型节点 - 若需按区域框选（如 x ∈ [100,300] && y ∈ [50,200]），可存
bounds: {left, top, right, bottom}，再用 IDBKeyRange 查询（但注意：IndexedDB 不支持复合范围索引，需结合 client-side 过滤）
索引在 upgradeNeeded 阶段创建，仅需一次，后续自动维护。
不复杂但容易忽略：每次打开数据库前检查 version，升级时用 onupgradeneeded 清理旧 schema；读写大量坐标数据时启用压缩（如 lz-string）可减小体积，但通常 10MB 以内原生存储更高效。
