sqlmock在Go微服务测试中“不生效”的根本原因是未将mock的*sql.DB注入业务实际使用的实例，导致SQL直连真实数据库；需确保DI容器注入mock实例、正确配置驱动名、避免包级初始化，并严格匹配SQL字符串。
为什么 sqlmock 在 Go 微服务测试中常“不生效”
根本原因不是 sqlmock 本身有问题，而是微服务里数据库连接通常被封装在全局变量、单例或依赖注入容器中，而 sqlmock 必须接管 sql.DB 实例的底层 driver.Conn 才能拦截 SQL——如果测试时没把 mock 的 *sql.DB 注入到业务代码实际使用的那个实例上，所有 SQL 就照常发往真实数据库。
常见错误现象：panic: sql: expected 1 arguments, got 0 或者测试通过但日志里出现真实 DB 连接尝试（比如 PostgreSQL 报 dial tcp [::1]:5432: connect: connection refused），说明 mock 根本没挂载成功。
- 确保业务层使用的
*sql.DB是测试中用sqlmock.New()创建并传入的，而不是通过sql.Open()初始化的 - 若用
github.com/go-sql-driver/mysql或lib/pq等驱动，必须在sqlmock.New()时传入对应 driver name（如"mysql"或"postgres"），否则sqlmock不会接管该连接 - 避免在
init()或包级变量里提前初始化*sql.DB，这会让测试无法替换
如何让 sqlmock 和依赖注入（如 Wire / Dig）协同工作
微服务常用 DI 框架管理 DB 实例生命周期，测试时需“覆盖”生产配置中的 DB 实例。关键不是改 DI 逻辑，而是让测试构造的 mock DB 被 DI 容器识别为同一类型依赖。
以 Wire 为例：业务代码依赖 DB *sql.DB，Wire 的 provider 函数返回真实 DB；测试时写一个同签名的 provider 返回 mock DB，并在 wire.Build() 中替换。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 定义测试专用 provider：
func provideMockDB() (*sql.DB, sqlmock.Sqlmock) { db, mock, _ := sqlmock.New(sqlmock.QueryMatcherOption(sqlmock.QueryMatcherEqual)); return db, mock } - 在测试文件中调用
wire.Build(..., wire.FieldsOf(new(MockSet), "DB", "Mock"))，其中MockSet是个 struct，字段含DB *sql.DB和Mock sqlmock.Sqlmock - 务必在每个测试用例末尾调用
mock.ExpectationsWereMet()，否则未验证的期望会静默忽略，导致“假成功”
sqlmock 模拟事务时的陷阱与写法
微服务中事务常跨多个函数调用，而 sqlmock 默认不支持嵌套事务（BeginTx 返回的 *sql.Tx 无法再被 mock 拦截），直接调用 tx.QueryRow() 会 panic。
正确做法是：对事务内所有操作，显式用 mock.ExpectQuery() / ExpectExec() 绑定到事务对象，且必须用 mock.ExpectBegin() 和 mock.ExpectCommit() 或 ExpectRollback() 包裹。
- 不要写
db.Begin()后再传给业务函数——业务函数拿到的是*sql.Tx，mock 对其内部调用无感知；应让业务函数接收context.Context和sqlmock.Sqlmock，由测试控制事务边界 - 若业务代码调用
tx.Stmt()，需额外调用mock.ExpectPrepare()并指定 SQL 字符串，否则报could not find statement - 注意
sqlmock.AnyArg()仅适用于参数匹配，不能代替 SQL 文本匹配；事务内 SQL 必须字面量完全一致（除非启用sqlmock.QueryMatcherLike）
性能敏感场景下要不要用 sqlmock？
答案取决于测试目标：如果测的是 DAO 层 SQL 正确性、错误路径、事务行为，sqlmock 是合适选择；但如果测的是 ORM 查询性能、连接池争用、慢查询优化，mock 反而掩盖问题——它不模拟网络延迟、锁竞争、事务隔离级别副作用。
- 单元测试用
sqlmock验证 SQL 构造逻辑和错误处理分支（如ErrNoRows是否被正确转换） - 集成测试应连接真实轻量 DB（如 SQLite 内存模式或本地 Docker PostgreSQL），跑带事务、索引、外键的真实 SQL
- 避免在 Benchmark 测试中使用
sqlmock，它的 hook 开销比原生sql.DB高 3–5 倍，数据无意义
最易被忽略的一点：mock 的 SQL 匹配是严格字符串相等，默认区分空格和换行。业务代码若用 fmt.Sprintf 拼接 SQL，测试里就得写完全一样的格式，否则 ExpectQuery 失败——建议统一用 strings.TrimSpace 处理预期 SQL，或改用 QueryMatcherLike。
