提到文档数据库，MongoDB几乎是默认答案，但如果项目规模不大、又不想额外部署一个数据库服务，SQLite配合JSON1扩展其实也能撑起一套完整的文档式存储方案。本文将从两者的文档模型差异讲起，再用SQLite做一个贴近实战的文档存储实现，最后对比各自的适用边界。
一、两种文档模型的底层差异
MongoDB的存储单位是BSON文档，每条记录本身就是一棵自描述的树结构，字段名、类型、嵌套层级全部内嵌在数据里。这种设计带来的好处是schema自由：同一个集合里可以放结构完全不同的文档，新增字段不需要任何DDL操作，写入时数据结构即最终结构。
SQLite则从根本上说是关系型模型，存储单位是行和列，表结构在建表时就固定了。不过从3.9版本开始，SQLite内置了JSON1扩展，提供了一整套JSON函数，允许把一段JSON文本存进某个TEXT或BLOB列，再用函数去解析和修改它。这相当于在关系模型之上叠加了一层文档抽象，虽然底层依然是行存储，但对外表现出接近文档数据库的使用体验。
两者最核心的区别在于查询引擎如何对待数据。MongoDB的查询规划器理解文档结构，可以直接对嵌套字段建索引；而SQLite把JSON当作不透明字符串，必须借助生成列把嵌套路径物化成普通列，索引才能生效。理解这一点，是后面实战部分的基础。
二、用SQLite模拟文档集合的实战
设计思路很直接：建一张表，主键对应MongoDB的_id，另一个字段存完整JSON文档。为了让嵌套字段可查询，再借助生成列把常用路径提取出来。
-- 创建一个类似 MongoDB collection 的表
CREATE TABLE users (
doc_id TEXT PRIMARY KEY, -- 相当于 _id
doc TEXT NOT NULL, -- 完整 JSON 文档
-- 生成列：把嵌套路径物化成普通列，可建索引
name TEXT GENERATED ALWAYS AS (json_extract(doc, '$.name')),
age INTEGER GENERATED ALWAYS AS (json_extract(doc, '$.profile.age')),
city TEXT GENERATED ALWAYS AS (json_extract(doc, '$.address.city'))
);
-- 为生成列建索引，等价于 MongoDB 的二级索引
CREATE INDEX idx_users_city ON users(city);
-- 插入文档，字段结构可以各不相同
INSERT INTO users(doc_id, doc) VALUES
('u1001', '{"name":"张三","profile":{"age":28},"address":{"city":"杭州"},"tags":["vip","beta"]}'),
('u1002', '{"name":"李四","profile":{"age":35},"address":{"city":"北京"},"hobbies":["reading"]}');插入时完全不用关心文档内部结构，u1002没有address字段也照常写入，这一点和MongoDB的行为一致。生成列是虚拟的，由SQLite在写入和更新时自动维护，不需要应用层手动同步。
查询方面，json_extract负责取值，配合普通SQL的where、order by即可完成大多数文档查询。下面的例子演示了等价于MongoDB常见操作的写法。
-- 等价于 db.users.find({city:"杭州"}, {name:1})
SELECT json_extract(doc, '$.name') AS name
FROM users
WHERE city = '杭州';
-- 等价于数组元素匹配：查询 tags 数组包含 vip 的文档
SELECT doc FROM users
WHERE EXISTS (SELECT 1 FROM json_each(users.doc, '$.tags')
WHERE json_each.value = 'vip');
-- 局部更新：只改 age，不动文档其余部分
UPDATE users
SET doc = json_set(doc, '$.profile.age', 29)
WHERE doc_id = 'u1001';注意json_set返回的是新JSON文本，必须整体写回doc列，生成列会随之自动刷新。这和MongoDB的原子性局部更新在语义上接近，但实现机制是读改写整条文档，文档特别大时会有性能代价。
三、索引、性能与方案取舍
直接对JSON表达式建索引在SQLite里是行不通的，所有查询优化都必须落在生成列上。实践中有两条原则：一是只为高频查询路径建生成列，不要贪多，每个生成列都会增加写入开销；二是数组类字段用json_each配合EXISTS查询，或者单独建一张关联表做反范式拆分，后者在数组元素需要独立查询时性能明显更好。
和MongoDB横向比较，这套方案的劣势在于没有聚合管道，复杂统计需要写大量SQL或应用层处理；事务粒度也不同，SQLite是库级写锁，高并发写入场景下吞吐远不如MongoDB的分片集群。但反过来，SQLite是单文件零运维，没有网络开销，嵌入式场景、桌面应用、中小型网站读多写少的场景下，性能常常反超走网络协议的MongoDB。
我的建议是：如果团队已经在用关系型数据库，只是偶尔需要存一点半结构化数据，JSON1扩展完全够用，没必要引入新组件；如果文档结构变化极其频繁、嵌套层级深、且查询以文档为单位整体进出，那MongoDB的文档模型仍然是更省心的选择。工具没有银弹，理解数据访问模式再做选型，比追逐技术名词重要得多。