配置文件几乎是每个程序都绕不开的东西，从最早期的INI，到后来流行的JSON、YAML、TOML，格式换了一轮又一轮，但本质都一样：把配置以纯文本形式持久化到磁盘。这种做法简单直接，可一旦配置项数量膨胀、更新频率变高、或者需要多进程共享读写，纯文本方案的短板就会显现。SQLite作为一个零配置的嵌入式数据库，恰好能补上这些缺口，而且它本身也只是单个文件，和配置文件的部署体验几乎一致。
纯文本配置文件的三大痛点
第一个痛点是原子性问题。程序运行时修改配置，常规做法是先把新内容写到临时文件，再rename覆盖原文件，以此来保证写入的原子性。但很多项目并没有严格执行这个流程，直接覆盖写入，一旦中途断电或进程崩溃，配置文件就会损坏成半截内容，下次启动直接解析失败。SQLite天生带有事务机制，写入要么完整提交，要么完全回滚，配合WAL模式，损坏风险被压到极低。
第二个痛点是并发读写。JSON、YAML这类格式没有行级定位能力，改一个配置项也要把整个文件读进内存、修改后整体写回。多进程同时写同一个配置文件时，很容易出现后写覆盖先写的丢更新问题。虽然可以借助文件锁，但跨平台文件锁行为不一致，坑不少。SQLite内置了成熟的锁管理，多个进程并发读写同一个数据库文件是它的看家本领。
第三个痛点是查询和校验能力。配置项多了以后，想在文本文件里快速找到某类配置、做条件筛选或者部分更新，只能把全部内容加载解析后再处理。而SQLite支持SQL的where条件、索引、部分更新，还可以用CHECK约束和NOT NULL在写入时就拦截非法配置值，校验逻辑从应用层下沉到了存储层。
用SQLite存储配置的表结构设计与读写封装
设计配置表时，通常有两种思路。一种是宽表模式，每个配置项一行，键值对存储；另一种是分组模式，模拟传统配置文件里的section概念，用section和key联合定位。下面是一个常用的建表语句，采用分组模式并加上类型字段：
CREATE TABLE IF NOT EXISTS config (
section TEXT NOT NULL,
key TEXT NOT NULL,
value TEXT,
value_type TEXT DEFAULT 'string' CHECK (value_type IN ('string','int','float','bool')),
updated_at TEXT DEFAULT (datetime('now','localtime')),
PRIMARY KEY (section, key)
);
-- 写入或更新（upsert）
INSERT INTO config (section, key, value, value_type)
VALUES ('server', 'port', '8080', 'int')
ON CONFLICT (section, key)
DO UPDATE SET value = excluded.value, updated_at = datetime('now','localtime');
-- 读取单个配置
SELECT value FROM config WHERE section = 'server' AND key = 'port';
-- 读取整组配置
SELECT key, value FROM config WHERE section = 'server';
在应用侧做一层薄封装即可。以Python为例，利用标准库sqlite3，几十行代码就能实现一个Config类：
import sqlite3
import json
class SQLiteConfig:
def __init__(self, path='config.db'):
# 建议开启WAL，提升并发读写表现
self.conn = sqlite3.connect(path, check_same_thread=False)
self.conn.execute('PRAGMA journal_mode=WAL;')
self.conn.execute('PRAGMA synchronous=NORMAL;')
self._init_schema()
def _init_schema(self):
self.conn.execute('''
CREATE TABLE IF NOT EXISTS config (
section TEXT NOT NULL,
key TEXT NOT NULL,
value TEXT,
PRIMARY KEY (section, key)
)''')
self.conn.commit()
def set(self, section, key, value):
# 复杂结构用JSON序列化后存储
if not isinstance(value, (str, int, float, bool)):
value = json.dumps(value, ensure_ascii=False)
self.conn.execute('''
INSERT INTO config (section, key, value) VALUES (?, ?, ?)
ON CONFLICT (section, key) DO UPDATE SET value = excluded.value
''', (section, key, str(value)))
self.conn.commit()
def get(self, section, key, default=None):
row = self.conn.execute(
'SELECT value FROM config WHERE section = ? AND key = ?',
(section, key)).fetchone()
return default if row is None else row[0]
这个封装有几个细节值得注意。第一，开启了WAL日志模式，读写可以并行，读操作不会被写阻塞；第二，synchronous=NORMAL在WAL模式下兼顾了性能与可靠性；第三，复杂结构先序列化为JSON再入库，既保留了灵活性，又能整体存取。如果希望启动时仍能导出一份人类可读的配置快照，只需一条查询把结果导成JSON文件即可，两者并不冲突。
SQLite方案与文本方案的对比及适用场景
下面这张表从几个关键维度做了对比：
| 维度 | JSON/YAML/TOML | SQLite |
|---|---|---|
| 可读性 | 直接打开即可读 | 需工具查看，但可导出 |
| 原子写入 | 需自己实现临时文件加rename | 事务保证，天然支持 |
| 并发读写 | 需文件锁，跨平台差异大 | 内置锁机制，支持多进程 |
| 部分更新 | 整体读改写 | SQL按条件更新 |
| 数据校验 | 依赖应用层 | CHECK、NOT NULL约束 |
| 配置历史 | 需配合版本控制 | 可加历史表记录变更 |
| 部署依赖 | 无 | 无，单文件零部署 |
哪些场景适合迁移？一是配置项频繁变更的运行时热更新场景，SQLite的细粒度更新和触发器能力很有优势；二是多进程需要共享配置的服务型程序，比如一个主进程写、若干工作进程读；三是需要记录配置变更历史的场景，可以加一张历史表，通过触发器在每次修改时自动留痕，这在排查问题时非常有用。
哪些场景不必迁移？如果是纯静态配置、只在发布时修改一次、且需要开发人员直接手工编辑，YAML和TOML的可读性与注释支持仍然是不可替代的优势。SQLite的数据库文件不方便直接阅读，也不适合放进Git做版本diff。另外要留意SQLite的写并发上限——同一个时刻只允许一个写入者，超高频写入场景需要评估是否满足要求。实践中的一个折中做法是：静态框架配置放TOML，动态运行时状态与可变参数放SQLite，两类需求各取所长。
迁移时的注意事项
从文本配置迁移到SQLite，有几点经验值得提前了解。首先是导入与导出的对称性，建议实现一套完整的转换工具，既能把现有JSON配置批量导入数据库，也能从数据库反向导出JSON，这样在过渡期可以双轨运行，随时回退。导出示例很简单：
import json
def export_to_json(conn, path='config_export.json'):
rows = conn.execute('SELECT section, key, value FROM config').fetchall()
data = {}
for section, key, value in rows:
data.setdefault(section, {})[key] = value
with open(path, 'w', encoding='utf-8') as f:
json.dump(data, f, ensure_ascii=False, indent=2)
其次要注意备份策略。单文件是SQLite的优点，但备份时机要避开写入中间状态，最稳妥的方式是使用VACUUM INTO或者备份API，而不是直接复制文件。最后，数据库文件的权限管理要和敏感配置的安全需求匹配，SQLite支持SEE等加密扩展，也可以在应用层对敏感字段做加密后再入库。
总体来看，SQLite作为配置存储并不是要彻底取代文本配置文件，而是为高动态、高并发、需要追溯能力的配置场景提供了一个工程上更扎实的选择。结合两者、按需求分工，往往是更务实的架构决策。