首选 IndexedDB 或 Dexie.js：IndexedDB 原生支持键路径索引、范围查询和游标遍历，性能优于 JSON 解析；Dexie.js 提供链式 SQL 风格查询，自动管理事务与索引；避免 SQLite WASM（体积大、初始化慢、内存压力高）。
网页端离线数据库（如基于 SQLite、Dexie.js、IndexedDB 或嵌入式 WebAssembly MySQL）的核心约束是：无服务端、资源受限（内存/磁盘/CPU）、单用户本地运行。要兼顾查询性能与磁盘占用，不能照搬传统服务端思路，得从数据模型、存储选型、索引策略和访问模式四方面做针对性取舍。
选轻量但可索引的存储引擎
优先用 IndexedDB 或 Dexie.js（封装 IndexedDB），而非纯 localStorage 或 JSON 文件：
- IndexedDB 原生支持键路径索引、范围查询和游标遍历，查询性能远高于手动解析大 JSON；
- Dexie.js 提供类 SQL 的链式查询语法（如 .where('ip').equals('192.168.20.35')），自动管理事务和索引，开发效率高；
- 避免 SQLite WASM 方案除非必须兼容已有 SQL 脚本——它体积大（~1MB+）、初始化慢、且在低配设备上易触发内存限制；
- 若数据极简（
表结构按查询意图垂直切分
不追求范式完整，而是按高频操作场景拆表，减少单次加载体积和冗余字段：
- 例如 IP 管理场景，拆成三张表：ip_records（IP、MAC、租约状态、最后活跃时间）、devices（设备名、位置、责任人、类型）、history（变更时间、操作人、旧值/新值）；
- 每张表只保留该场景必需字段，比如 ip_records 不存设备描述，靠 device_id 关联；
- 对历史类数据启用压缩存储（如用 msgpack 序列化后存为 ArrayBuffer），查询时再解压关键字段；
- 静态元数据（如网段划分、部门列表）单独存为只读 JSON 文件，启动时预加载进内存，不进 IndexedDB。
索引宁少勿滥，聚焦高频过滤字段
IndexedDB 每个索引都额外占用磁盘空间并拖慢写入，必须克制：
- 只对 WHERE 条件中稳定出现的字段 建索引，例如 IP 地址、MAC 地址、状态字段（'active'/'conflict'/'reserved'）；
- 组合索引慎用——IndexedDB 不支持多字段范围查询优化，ip + status 索引仅在同时按两者过滤时生效，否则不如单字段索引灵活；
- 避免对长文本（如备注字段）或低基数字段（如只有 'yes/no' 的标记）建索引；
- 用 keyPath 索引替代普通索引：比如把 {ip: "192.168.20.35", mac: "aa:bb:cc..."} 的 ip 设为主键，直接用 openCursor(IDBKeyRange.only("192.168.20.35")) 查，比额外建索引更省空间、更快。
查询逻辑前置，减少运行时计算
离线环境无法靠服务端聚合，要把“重活”移到数据写入或同步阶段：
- 冲突检测不在查询时遍历全表比对，而是在新增/修改 IP 记录时，同步检查并写入 conflict_flag 字段；
- 常用统计（如“各网段在线数”）不现场 COUNT，而用维护好的汇总表 subnet_stats，每次 IP 状态变更时原子更新；
- 模糊搜索需求（如按设备名查）改用前端轻量库（如 Fuse.js）做内存内匹配，而非在 IndexedDB 中建全文索引（开销太大）；
- 导出报表类操作，提前生成带时间戳的快照文件（如 export_20261010.json.gz），避免每次点“导出”都遍历全库。
