用 database/sql + github.com/mattn/go-sqlite3 是 Go 操作 SQLite 的唯一推荐方案，必须以下划线方式导入、用 sql.Open 初始化、事务中统一使用 tx 方法、内存库须用 file::memory:（双冒号），且需手动处理目录创建、外键启用、WAL 模式设置及结构校验。
用 database/sql + github.com/mattn/go-sqlite3 才是正路
Go 官方不自带 SQLite 驱动，必须靠第三方包。别试 go-sqlite 或其他名字相近的冷门包——它们要么已归档，要么不维护，要么连 sql.Tx 都不支持。只认准 github.com/mattn/go-sqlite3，它和 database/sql 配合最稳，也最接近你写 MySQL/PostgreSQL 的手感。
常见错误现象：import "github.com/mattn/go-sqlite3" 后编译报 undefined: sqlite3.Open ——说明你没走 database/sql 接口，而是想直接调 C 函数；或者 cannot use db (type *sql.DB) as type sqlite3.Conn，这是类型强转误用。
实操建议：
- 导入方式必须是
import _ "github.com/mattn/go-sqlite3"（下划线前缀），不是import sqlite3 "github.com/mattn/go-sqlite3" - 连接字符串用
"file:./data.db?_foreign_keys=1"，加_foreign_keys=1才能真正启用外键约束 - 首次打开数据库时，SQLite 会自动建文件，但目录必须存在；
os.MkdirAll("data", 0755)得自己做，驱动不会帮你建父目录
sqlite3.Open 不是函数，别在代码里调它
有人搜 “golang sqlite open function”，然后翻到 go-sqlite3 文档里真有个 sqlite3.Open，就直接用了——结果 panic：未定义、或返回 *C.sqlite3 指针，根本没法和 database/sql 一起用。这不是 bug，是设计如此：这个 Open 是底层 C 封装，面向的是极少数需要绕过 SQL 层直操作句柄的场景（比如自定义 VFS）。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 一律用
sql.Open("sqlite3", "file:app.db")，不是sqlite3.Open(...) -
sql.Open不真正连数据库，只是初始化连接池；第一次db.Ping()或执行查询才触发实际 I/O - 如果要确保数据库可写，
db.Exec("PRAGMA journal_mode = WAL")建议在Ping之后立刻执行，否则 WAL 模式可能不生效
事务里别混用 db.Query 和 tx.Query
错误现象：开了事务 tx, _ := db.Begin()，却在事务体里继续用 db.Query("SELECT ...")，结果查到的是事务外的数据，甚至事务回滚后，那些 db.Query 查到的结果还“看起来没变”——其实是读到了旧快照。
SQLite 的 WAL 模式默认开启快照隔离（snapshot isolation），但前提是所有操作都在同一个 *sql.Tx 上进行。一旦混用，就脱离了事务上下文。
实操建议：
- 事务中所有查询、更新、插入，都必须用
tx.Query、tx.Exec、tx.Prepare，绝不能出现db.开头的调用 - 别为了省一行，把
tx传进一个接受*sql.DB的函数里——类型不匹配，Go 编译器会拦住你，这是好事 - 如果函数确实要通用，就让它接受
interface{ Query(...), Exec(...) }，或直接用sql.Tx+sql.Stmt组合，别硬塞*sql.DB
嵌入式场景下，file:memory: 和 file::memory: 差一个冒号，行为天壤之别
很多人想测试或临时缓存，随手写 sql.Open("sqlite3", "file:memory:")，发现每次 sql.Open 都得到一个全新空库，数据不共享。其实你想要的是共享内存数据库，得写成 file::memory:（两个冒号）。
原因：SQLite 把 file:memory: 当作独立文件名处理，每个 sql.Open 实例都开一个新内存实例；而 file::memory: 是 SQLite 内置的“特殊数据库名”，所有连接共用同一块内存空间（前提是用同一个连接字符串、且没加 ?cache=shared 等干扰参数）。
实操建议：
- 单元测试用内存库，固定写
"file::memory:?_fk=1"，别漏掉双冒号 - 如果多个 goroutine 并发访问
::memory:库，不需要额外加锁——SQLite 的内存模式本身是线程安全的（前提是编译时启用了SQLITE_THREADSAFE=1，mattn 包默认满足） - 但别在生产环境用
::memory:持久化数据，进程一挂全丢；真要轻量持久，就老实用file:./data.db，并确保路径可写
INSERT INTO t(a,b) VALUES (?,?) 中值与列名错位的问题，出错了只报 no such column 或静默截断，得靠测试和 PRAGMA table_info 主动检查。 
