原生移动应用开发为何不直接用独立JSON文件替代本地数据库？

当前业务逻辑简单、数据量极小的时候，读写JSON确实是最轻量的方案，但一旦数据规模、业务复杂度上来，数据库的优势会非常明显，核心差异点如下：

• 读写效率差距随数据量扩大被快速放大：读写JSON文件的逻辑本质是全量IO——哪怕你只需要修改某条数据里的一个字段，也要把整个JSON文件完整读入内存、反序列化为对象、修改值、再全量序列化后覆盖写回磁盘。在KB级别的小数据场景下这个过程几乎无感知，但当数据量增长到几MB甚至更大时，全量读写带来的磁盘IO开销、内存占用会陡增，很容易造成UI掉帧卡顿。而移动端常用的本地数据库（SQLite、系统封装的Room、Core Data等）是按数据页做磁盘读写，支持按需读取指定行、指定字段，写入也是增量更新，不需要加载全量数据，万级条目量级下的操作性能比全量读写JSON高两个数量级以上。
• 原生支持并发安全，不用自己处理锁逻辑：直接操作JSON文件没有内置的并发控制能力，如果出现多线程同时读写、后台线程写文件时主线程读文件的场景，很容易读到半写入的脏数据，甚至直接把文件写坏。要解决这个问题你需要自己实现文件锁、维护串行读写队列，稍有遗漏就会出难以复现的线上bug。数据库本身内置了成熟的读写锁、并发调度机制，多线程操作的安全问题不需要业务层额外造轮子。
• 事务机制保障数据一致性：如果你需要同时更新多组关联数据，写JSON文件时如果遇到App闪退、进程被系统杀死的极端情况，很可能出现部分数据写入成功、部分没写完的中间状态，下次启动读取时就会出现逻辑错乱。数据库的事务具备原子性，同个事务内的所有修改要么全部生效，要么出错时全部回滚，不会出现半成功的脏数据状态。
• 后续业务扩展的维护成本极低：你当前觉得不需要查询语句，只是现阶段业务逻辑简单。等后续迭代需要做条件筛选、排序、聚合统计时——比如要拉取近30天产生的、状态为已完成的所有条目，用JSON你需要手动遍历全量数据写循环过滤，数据量大了性能很差；用数据库只需要写简单的查询条件，配合字段索引可以毫秒级返回结果。另外数据库自带结构化的schema升级能力，后续需要给数据加字段、改结构时，不需要自己写逻辑遍历全量JSON给老数据补默认值、做格式转换。
• 内置数据完整性校验：你可以在数据库层配置约束，比如指定某个字段非空、某个字段值唯一、关联数据的ID必须对应存在，从写入入口就拦截非法数据。如果用JSON存储，你需要在每一处写数据的业务代码里手动做所有规则校验，漏过一个校验点就可能存入不符合规则的异常数据，后续解析时甚至会直接引发崩溃。

补充说明：不是所有存储场景都必须用数据库。如果你的存储内容是KB级、几乎不会频繁修改、不存在并发写入的轻量配置（比如用户的主题偏好、上次启动时的临时状态），直接用JSON或者系统自带的轻量键值存储完全够用，没必要强行引入数据库增加额外复杂度。但如果存储的是持续增长的业务类数据、存在多线程读写可能、数据之间有关联关系，从长期维护的角度看，用数据库比自己折腾JSON文件的成本低得多。

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