JSON文件存储 vs SQLite核心场景大量零散小文件、数据持续累积增长下面对比重点围绕这个痛点。说明这里 JSON 指「一个 / 多个独立.json文件存数据」不是 JSON 字段存在数据库里。一、核心优缺点对比 JSON 文件零散小文件方案✅ 优点简单零依赖不需要服务、不需要库直接读写文件随手用文本编辑器打开查看。单条数据隔离一条记录一个 json 文件时单个文件损坏不会影响其他文件。增量备份简单只需要同步新增 / 修改的小文件。程序调试友好出错直接打开 json 看内容。❌ 缺点就是你关心的小文件越来越多之后的大坑文件系统瓶颈最致命操作系统的目录有 inode / 目录项上限。几十万个小文件放在同一个文件夹下ls、遍历、查找都会巨慢。 哪怕文件很小每个文件都要占用一个 inode占用额外磁盘元数据空间。没有事务写文件中途断电 / 程序崩溃JSON 文件直接半截损坏数据丢失。查询、过滤极慢想查满足条件的数据必须遍历打开全部 json 文件、解析不能索引。更新开销大修改一条记录要完整重写整个 json 文件不能局部修改。并发读写麻烦多进程同时写同一个 json极易文件覆盖需要自己加锁。磁盘碎片大量频繁改写的小文件碎片会越来越多。缓解办法拆分目录按日期 / ID 哈希分文件夹比如data/00/01.json但只是延缓不能根治。️ SQLite单文件数据库✅ 优点完美解决大量零散小文件痛点全部数据打包在 1 个或少量db 文件不会产生成千上万个小文件inode 占用极低。文件系统压力几乎不受记录条数影响。支持索引按字段查询、过滤、排序速度远高于遍历 json。事务 ACID写操作要么完整成功要么回滚不会出现半截损坏的数据。支持局部更新只修改需要的字段不用重写全部数据。内置锁机制原生支持多进程 / 多线程读写控制。支持 JSON 字段SQLite 本身就可以存 JSON 文本还能对 json 内部 key 建立索引。❌ 缺点单文件损坏风险磁盘 IO 崩溃、断电极端情况下整个 db 文件损坏但开启 WAL 模式能大幅降低风险。不能直接用文本编辑器浏览查看数据需要数据库工具。超大库千万级记录以上会有性能拐点百万级以内通常非常稳。多机器同时写同一个 db 文件性能很差SQLite 不适合网络多机并发写。备份需要复制整个 db 文件可以用VACUUM、在线备份 API 优化。二、针对你的场景数据不断新增小文件持续变多什么时候选 JSON 文件总数据量不大文件数控制在几万以内几乎不需要复杂查询大多按 ID 直接读取单条简单脚本不想引入数据库依赖数据很少修改只读为主。❌ 不推荐长期运行持续新增文件数量会涨到几十万、上百万。目录遍历、文件元数据开销会成为性能天花板。什么时候选 SQLite长期持续写入记录数量持续上涨担心小文件爆炸需要按字段搜索、筛选数据需要保证写入可靠性防止断电坏数据希望避免大量 inode 占用、目录卡顿。✅ 推荐绝大多数本地持久化业务单设备读写优先 SQLite甚至你可以继续把 JSON 存在 SQLite 的 TEXT 字段里保留 JSON 灵活性同时享受数据库能力。三、补充方案参考可选SQLite JSON 字段推荐折中方案。记录主体放 JSON 字符串查询简单字段建立索引兼顾灵活和性能。LevelDB / RocksDBKV 嵌入式数据库也是单文件组适合高吞吐写入查询能力弱于 SQLite。适合只做 key-value 存取不需要复杂 SQL。四、简单总结一句话如果数据会长期累积小文件数量持续增长优先 SQLite避免文件系统 inode 爆炸 JSON 零散小文件适合轻量、短期、文件总量可控的场景文件一多性能和稳定性会明显变差。