Flutter中列表存储操作的数据库选型及问题咨询

先明确Firebase系列无法实现contains()过滤的核心原因 #

Firebase Realtime Database与Firestore本身定位是云侧实时同步存储，查询能力天生存在局限，并不适配高频本地列表操作场景：

• Firestore仅支持数组字段的精确成员匹配（自带的array-contains只能查询完全等于目标值的数组元素），不支持字符串包含、模糊匹配类的contains逻辑，要实现这类效果要么拉取全量数据到Dart层做本地过滤，要么提前给所有可能的查询条件建冗余索引字段，灵活性极差
• Realtime Database是JSON树结构存储，没有原生结构化查询能力，所有过滤、排序逻辑都需要拉取对应节点的全量数据后在本地计算，列表数据量过千后很容易出现掉帧、内存占用过高的问题

分场景选型推荐 #

场景1：纯本地存储、离线优先，无多端同步需求 #

这类场景优先选无桥接损耗、原生支持Dart的嵌入式数据库，对列表操作的适配度最高：

• 首选 Isar
  是目前Flutter生态对列表操作支持最好的本地数据库，没有原生桥接的性能开销：
  • 内置完整的查询语法，直接支持contains()、前缀/后缀匹配、多条件组合过滤、范围查询、排序分页，所有过滤逻辑直接在数据库层计算完成，万级数据量查询耗时稳定在毫秒级，不需要拉取全量数据到内存处理
  • 原生支持数组（列表）类型字段，可直接对列表字段做元素包含、长度判断、元素匹配等操作，不需要额外做序列化转换
  • 自带全文搜索、批量增删改、事务支持，完全覆盖列表下拉刷新、上拉加载、搜索过滤、批量操作的所有常规需求
    常规的关键词过滤代码示例：

  // 直接查询标题包含指定关键词的列表项，大小写不敏感
  final filteredList = isar.collection<ListItem>().filter()
    .titleContains(keyword, caseSensitive: false)
    .findAll();
  

• 次选 Drift
  基于SQLite封装的ORM框架，适合熟悉SQL语法的开发者：
  • 支持标准SQL的所有查询能力，通过LIKE语法即可实现contains类的字符串匹配，支持多表关联、索引优化、事务操作
  • 缺点是配置成本更高，需要通过代码生成DAO层，数组类型字段需要手动做类型转换，灵活度比Isar略低
    对应的关键词过滤代码示例：

  // 底层自动生成LIKE语句完成匹配
  final filteredList = (select(listItems)..where((item) => item.title.like('%$keyword%'))).get();
  

场景2：需要多端云同步 #

如果必须保留云同步能力，不建议直接调用云数据库接口响应列表操作，采用「云存储+本地嵌入式数据库」的分层架构即可：

• 云侧可以继续沿用已经熟悉的Firebase生态做数据持久化、跨端同步，首次拉取全量数据后同步写入本地Isar数据库
• 所有列表的过滤、排序、分页、增删改操作全部走本地Isar完成，数据变更后再异步同步回云端，既保留云同步能力，又解决云数据库查询能力弱、网络延迟影响列表交互的问题
  如果不想自己实现同步逻辑，也可以选择自带同步能力的ObjectBox，原生支持contains类查询语法，不过多端同步能力为付费功能。

避坑提示 #

• 当列表数据量超过500条时，不要直接通过云数据库接口响应列表交互操作，网络延迟+云侧查询限制会直接导致列表滑动、搜索卡顿，高频操作必须走本地数据库计算
• 不要用shared_preferences、本地文件等KV/文件存储方案存结构化列表数据，这类存储没有查询能力，每次操作都需要全量读取、反序列化、再序列化写回，数据量稍大就会出现明显的性能问题

内容的提问来源于stack exchange，提问作者JoeCodes