能接，但得避开cgo、避免共享连接、不用于高并发写场景——微服务里sqlite适合做配置快照、本地缓存、离线策略库，不是主业务数据库。
为什么不用 mattn/go-sqlite3 驱动？
它依赖 CGO 和系统级 SQLite C 库，破坏微服务的纯 Go 编译链和容器镜像轻量化目标。交叉编译失败、Alpine 镜像报 undefined reference to 'sqlite3_*'、CI 构建卡在 CGO_ENABLED=1 是高频问题。
- 纯 Go 实现的替代方案只有
github.com/ncruces/go-sqlite3（注意不是 mattn 的）或更激进的github.com/etcd-io/bbolt（但它是 KV，非 SQL） -
ncruces/go-sqlite3支持CGO_ENABLED=0，兼容GOOS=linux GOARCH=arm64，且 API 与标准database/sql兼容 - 如果你已用
mattn/go-sqlite3，加//go:build cgo注释并确保构建环境装了libsqlite3-dev—— 这在 CI/CD 中等于主动引入运维负担
如何安全地复用 db 连接而不阻塞请求？
SQLite 默认是串行化写入（WAL 模式下可读写并发，但写仍是单线程），sql.Open 返回的 *sql.DB 虽支持连接池，但底层文件锁会让并发写请求排队甚至超时。
- 对配置类只读场景，设置
db.SetMaxOpenConns(1)+db.SetMaxIdleConns(1)，避免连接泄漏和锁竞争 - 写操作（如动态更新配置）必须走事务，并显式调用
db.Exec("PRAGMA journal_mode = WAL")初始化一次（仅首次） - 绝对不要在 HTTP handler 里直接
db.Exec写配置；应通过 channel 或 worker queue 异步提交，防止请求被 SQLite 写锁拖垮 - 检查错误是否为
sqlite3.ErrBusy（需重试）或sqlite3.ErrLocked（说明 WAL 未启用或路径权限不对）
配置表设计要注意哪些 SQLite 特性？
SQLite 没有原生 JSON 类型，也没有严格模式（比如插入字符串到 INTEGER 字段不会报错），这对配置数据的可靠性是隐患。
- 用
TEXT CHECK(json_valid(value))约束 JSON 字段，配合json_extract()查询，避免全表扫描 - 配置键建议用复合主键：
CREATE TABLE config (service TEXT, key TEXT, value TEXT, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY(service, key)) - 避免
INTEGER PRIMARY KEY AUTOINCREMENT—— 微服务配置不需要自增 ID，还多占 8 字节 - 查询时强制用
WHERE service = ? AND key = ?，别依赖LIKE或全文索引，SQLite FTS5 在小数据集上反而慢
文件路径和权限容易被忽略的细节
微服务常以非 root 用户运行，而 SQLite 文件路径若写成 /tmp/config.db，容器重启后丢失；若写成 /app/data/config.db，可能因目录不存在或权限不足导致 no such table 错误（其实是 open 失败，但 sql.Open 不报错）。
- 启动时先
os.MkdirAll(filepath.Dir(dbPath), 0755)，再os.Chown目录给目标用户（如1001:1001） - 连接 DSN 推荐用
file:/app/data/config.db?_journal_mode=WAL&_busy_timeout=5000，显式启用 WAL 并设超时 - 内存数据库
:memory:只适合单实例测试，微服务多副本时各跑各的，无法共享配置 - 用
sqlite3 ./config.db ".dump"手动验证表结构是否生效，比日志里看Exec返回值更可靠
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
