SQLite做feature flag存储够用，尤其适合中小流量、内部工具和灰度发布初期；它零网络开销、免运维、schema灵活、读写快，但需规避数据库锁、连接泄漏等问题，并配合缓存与规则解析策略。
用 SQLite 做 feature flag 存储够不够用
够用，而且在中小流量、内部工具、灰度发布初期场景下，是性价比最高的选择。它没网络开销、不用维护额外服务、schema 灵活，关键是写入快、读取毫秒级——feature_flags 表查一次 SELECT enabled FROM feature_flags WHERE key = ? 就能拿到开关状态。
常见错误现象：sqlite3.OperationalError: database is locked，多线程/多进程直连同一 DB 文件时高频读写会触发；或者用 sqlite3.connect() 每次都新建连接却不 close，导致 fd 耗尽。
- 只开一个连接 + 连接池（如
sqlite3.Connection复用），避免频繁 open/close - 读操作用
PRAGMA journal_mode = WAL，提升并发读性能 - 写操作（比如后台管理界面 toggle 开关）加简单锁：用
threading.Lock或文件锁flock，别依赖 SQLite 自带的 busy timeout - 表结构建议至少包含：
key（主键，TEXT）、enabled（INTEGER CHECK(enabled IN (0,1))）、updated_at（REAL，存time.time()）
Python 里怎么快速读取 flag 状态不拖慢请求
不能每次 HTTP 请求都查一次 DB。得缓存，但又不能缓存太久——灰度开关要能秒级生效。
使用场景：Django/Flask/FastAPI 中间件、Celery task、CLI 工具判断是否启用新逻辑。
立即学习“Python免费学习笔记（深入）”；
- 用
functools.lru_cache(maxsize=128)包裹读 DB 函数，但加typed=True防止字符串/bytes 键冲突 - 缓存失效靠「时间戳」：每次查 DB 时顺带读
updated_at，如果本地缓存的updated_at比 DB 小超过 1 秒，就强制刷新 - 避免用
@lru_cache直接包get_feature_flag('pay_v2')，因为参数是 str，无法感知 DB 变更；改用带版本号的封装，比如get_flag_with_version('pay_v2')返回(value, version) - 如果项目已用
redis，那优先把 flag 同步到 Redis（用SETNX+ 过期时间），Python 层直接redis_client.get('flag:pay_v2')——比 SQLite 缓存更可控
SQLite 不支持 JSON 怎么存复杂规则（比如按用户 ID 百分比放量）
不硬上 JSON，用字段拆解 + 简单解析。SQLite 3.38+ 虽然支持 json_extract，但 Python 里用 sqlite3 模块默认不启用 JSON 扩展，开启麻烦还影响移植性。
参数差异：enabled 字段只管“开/关”，复杂规则全扔进 rules 字段（TEXT），内容是纯 JSON 字符串，Python 层负责 json.loads()。
- 示例值：
{"type": "percent", "value": 5.0, "seed": "pay_v2"}或{"type": "whitelist", "users": ["u123", "u456"]} - 读取时统一用
json.loads(row['rules'] or '{}')，加try/except json.JSONDecodeError容错，失败则当空规则处理 - 别在 SQL 里做规则计算（比如
WHERE json_extract(rules, '$.value') > 5），这种查询没法走索引，且语义模糊——规则解释权必须收归 Python 层 - 如果规则变多、变重，说明该拆服务了，别死撑 SQLite
上线后发现 flag 切换不生效，先查哪几处
90% 是缓存没清或没刷，不是数据库写错了。
性能影响：缓存层 miss 一次会打 DB，但只要缓存命中的 QPS 在 1k 以内，SQLite 完全扛得住；真正卡住的是应用层反复解析 JSON 或没设超时的 HTTP 调用。
- 检查 Python 进程是否 reload 过——
lru_cache是 per-process 的，gunicorn 多 worker 下每个 worker 缓存独立，切 flag 后要滚动重启或加信号触发清缓存 - 确认 DB 文件路径是不是被不同环境共用（比如 dev/staging 共用
./flags.db），用绝对路径 +os.path.abspath()初始化连接 - 查日志里有没有
sqlite3.IntegrityError（比如重复插入同一key），SQLite 默认不报错，但 insert or replace 要显式写 - 用
sqlite3CLI 连上去执行SELECT * FROM feature_flags WHERE key = 'xxx';，看enabled和updated_at是否真变了
最常被忽略的是：缓存 key 拼写和 DB 里的 key 不一致，比如代码里写 'payment_v2'，DB 里存的是 'pay_v2'，查不到就回退默认值，而默认值往往设成了 False，于是以为“关着”，其实根本没读到。
