最轻量可控的集成方式是直接用database/sql搭配github.com/mattn/go-sqlite3与gin；需用绝对路径初始化db、显式ping校验连接、通过r.set注入全局*sql.db，并使用带context的begintx配合wal模式与serializable隔离级别确保事务安全。
直接用 database/sql + github.com/mattn/go-sqlite3 配合 Gin 是最轻量、最可控的集成方式；GORM 虽方便，但对 SQLite 这类嵌入式库会引入冗余抽象和默认行为（比如自动建表、隐式事务），反而容易在并发或文件锁场景下出问题。
sqlite3 驱动安装与 sql.Open 的路径陷阱
SQLite 数据库本质是单个文件，sql.Open("sqlite3", "./data/app.db") 中的路径是相对于**当前工作目录**（不是二进制所在目录，也不是 main.go 所在目录）。运行时若从其他路径执行 ./myapp，就可能创建空数据库或报 no such table 错误。
- 始终用绝对路径：用
filepath.Abs("./data/app.db")获取完整路径再传给sql.Open - 确保目录存在：
os.MkdirAll(filepath.Dir(dbPath), 0755)在sql.Open前调用 - 加
_vacuum和_busy_timeout参数提升健壮性：./data/app.db?_busy_timeout=5000&_journal_mode=WAL
Gin 中注册全局 *sql.DB 实例的正确时机
不能在 init() 或包级变量里直接调用 sql.Open，因为此时日志、配置加载等前置逻辑尚未就绪，且错误无法被上层捕获。必须在 Gin 启动前完成 DB 初始化，并显式检查连接。
- 在
main()函数开头调用初始化函数，例如db, err := setupDB() -
err = db.Ping()必须执行——sql.Open只校验 DSN 格式，不真正连库 - 把
*sql.DB注入到 Gin 的gin.Engine中：r.Set("db", db)，后续 handler 用c.MustGet("db").(*sql.DB)取出 - 避免用
context.WithValue传递 DB， Gin 的Set/MustGet更直接、无泄漏风险
事务处理中 db.Begin() 与 c.Request.Context() 的关系
SQLite 不支持真正的并发写入，WAL 模式下也仅允许多读一写。如果 handler 内部用 db.Begin() 开启事务，但没配合请求上下文做超时控制，一个慢查询或死锁会卡住整个连接池。
- 务必用带上下文的
db.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelSerializable}) - 将
c.Request.Context()传入，这样按 Ctrl+C 或客户端断连时，事务能自动回滚 - 不要在事务内调用
c.JSON—— 一旦响应已写出，就不能再回滚；应先 commit/rollback，再统一返回 - SQLite 默认隔离级别是
READ UNCOMMITTED，写密集场景必须显式设为LevelSerializable，否则可能读到未提交数据
SQLite 文件锁机制比网络数据库更敏感，PRAGMA journal_mode = WAL 和合理的 _busy_timeout 是底线；所有 SQL 操作都该有明确的 context 控制，而不是依赖 defer 或全局超时。Gin 本身不干预 DB 层，所以这些细节全靠你手动兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
