小项目数据存 JSON 文件还是数据库

2026-09-16 JSON,数据存储,数据库选型,小项目

给烧烤店做小程序交付那会儿，后台只有几张配置表，我一开始真想直接写 JSON 文件算了。小项目数据存文件还是数据库，我的结论是：只读的配置放文件，会被改动的数据放数据库，按这个分，基本不会错。

一、先摆六个维度的差别

| 维度 | JSON 文件 | 数据库 |

|---|---|---|

| 写入安全 | 写完整个文件，中途失败会留下半截 | 事务保证，要么都成要么都不成 |

| 并发 | 两个写入者会互相覆盖 | 由数据库协调写入顺序 |

| 查询能力 | 全读进内存自己筛 | 条件、排序、聚合都能交给它 |

| 结构变更 | 老数据可能缺字段，要靠代码兜 | 可写迁移脚本，改动可追溯 |

| 调试便利 | 文本直接看，改起来快 | 要工具或写语句 |

| 数据量上限 | 全量载入内存，量大就难受 | 按需读，量级不敏感 |

表里最要命的是第一行和第四行。文件写入不是原子的，结构变更没有记录，这两条是小项目后期最常见的两个坑。

二、什么情况下 JSON 文件就够

配置、开关、一次性导入的静态数据，放文件完全合理。

这类数据的共同点是不在运行时被频繁修改，读完就放内存里，改的时候是人手动改。我那个小程序的档位配置就是这种。

好处是调试快。文本文件直接打开就能看，改一个值刷新就生效，不用连数据库。

判断标准很简单：这份数据是由代码改的，还是由人改的。人改的，文件挺好用。

还有一类也适合放文件：数据量很小、启动时全量读进内存的那种。比如一份国家地区列表，几 KB，放文件比建表省事。

三、什么情况下必须上数据库

只要数据会被程序在运行时修改，就该用数据库。

用户提交的内容、订单状态、计数、日志，这类都是。文件方案在这里会出两个问题：写入不是原子操作，两个请求同时改会丢数据；数据一多就得全量载入内存。

我那次交付的收银相关数据就是程序在改的，所以那部分我用了数据库。

第三个问题是查询。文件方案要自己写筛选和排序逻辑，用数据库一条语句就够了。数据简单时这不叫事，字段一多就会变成维护负担。

四、小项目数据存文件还是数据库，混合用是常见答案

大多数小项目不需要二选一。

只读配置留在文件里，会变的数据放进数据库。这样你既能保住文件方案的调试便利，又不用为写入安全操心。

代价是两套东西要维护。所以要把边界定清楚：哪份数据归哪边，写下来，别靠记忆。

边界之外还有一种情况要避免：某个字段既在文件里也在数据库里，这基本一定会导致两边不一致。

同一份数据只允许有一个存放位置。

五、交付那次我实际怎么分的

我的后台选的是数据库，因为它的数据几乎全由程序写。

配置类的少量内容我保留在文件里。这样改动参数不用开数据库工具，改完重启就生效。

顺带说一句交付那次的账：那个小程序交付收入 ¥3000，其中我手写的代码不到 20 行。大部分工作是配置和串联，数据存储这块越简单越好。

如果重来一次，我在这块不会换方案。它不花哨，但它没给我添麻烦。小项目数据存文件还是数据库，按「谁改它」来分，基本一次就能定对。

常见问题

Q：JSON 文件存数据，量大了会怎样？

A：每次读取通常要全量载入内存，量上去以后内存和耗时都难受。而且写入时要重写整个文件，风险随大小上升。

Q：用 JSON 文件会不会丢数据？

A：会。写到一半进程退出，文件可能只剩下半截。要降低风险就先写临时文件再替换，但并发问题它解决不了。

Q：小项目直接上数据库是不是过度设计？

A：如果数据只由人手动改，是有点重。但只要程序会写它，用数据库就是省事而不是加负担。