🆚 LiteDB vs SQLite（断线缓存场景对比）
用火狐浏览器打开github,不能打开就换浏览器。github不稳定，国内访问。
表格
| 项目 | LiteDB | SQLite |
|---|---|---|
| 代码风格 | POCO+LINQ，不用 SQL | SQL 语句 |
| 加密 | 原生 AES，开箱即用 | 原生无加密，需要 SQLCipher |
| 依赖 | 单个 450KB .NET dll | 原生库，Microsoft.Data.Sqlite 底层调用 sqlite |
| 多进程访问 | ❌不支持，单进程独占 | ✅支持多进程 |
| 管理工具 | LiteDB.Studio（轻量单文件） | DB4S、SQLiteSpy（极小）+ 系统自带 sqlite3 cli |
| 写入锁 | 集合写锁，多写串行 | 行 / 页锁，并发能力更强 |
| Ubuntu 远程 ssh 排查 | 无内置 cli，需要写小工具 | 内置 sqlite3 命令行，直接 ssh 查数据 |
🎯 推荐选型判断（你的断线缓存）
✅ 选 LiteDB，如果：
- 想要内置加密，不想折腾 SQLCipher；
- 采集程序是单进程，单线程消费队列写入缓存；
- 偏好 C# POCO，不想写 SQL；
- 现场排查 db 文件拷贝回 Windows，用 LiteDB.Studio 查看即可。
✅ 继续用 SQLite，如果：
- 需要ssh 登录 Ubuntu 服务器直接用命令行查询缓存数据（现场运维优势很大）；
- 未来有可能多个进程读写同一个缓存文件；
- 不需要加密，用 Linux 文件权限保护就足够。
小坑提醒 LiteDB
- 不要多线程同时写同一个集合；用队列，单线程写入；
- 大量删除旧数据后，LiteDB 同样不会自动释放磁盘空间，需要调用
db.Rebuild()回收空间（类似 VACUUM）； - 加密密钥写在配置文件，同样存在密钥泄露风险（和 SQLCipher 一样，只是加密是内置能力）。
