本文讲解如何在 Go 中为 *sql.DB 等标准库类型构建可测试的接口层，重点解决因返回类型不匹配（如 *sql.Rows 无法直接赋值给自定义 DatabaseRows 接口）导致的编译错误，并提供符合 Go 惯用法的解耦方案。
本文讲解如何在 go 中为 *sql.db 等标准库类型构建可测试的接口层，重点解决因返回类型不匹配（如 *sql.rows 无法直接赋值给自定义 databaserows 接口）导致的编译错误，并提供符合 go 惯用法的解耦方案。
Go 的接口实现是隐式的，但类型系统不允许自动将具体返回类型（如 *sql.Rows）向上转型为用户定义的接口（如 DatabaseRows）*，即使 sql.Rows 实际实现了全部方法。这是因为 Go 要求方法签名完全一致*：`sql.Rows.Query(...)返回的是*sql.Rows，而你的Database.Query(...)声明返回DatabaseRows`——二者属于不同类型，编译器不会自动桥接。
直接包装 *sql.DB 并试图让其“实现”你设计的 Database 接口是不可行的，除非你手动实现一层适配器。但更推荐、更符合 Go 工程实践的方式是：面向业务契约建模，而非面向底层 SQL API 建模。
✅ 正确做法：定义领域语义接口，而非 SQL 操作接口
例如，若业务需查询员工信息，应定义：
type EmployeeService interface {
GetEmployeeByID(id int) (*Employee, error)
ListEmployees() ([]*Employee, error)
}
type Employee struct {
ID int
Name string
Age int
Salary float64
}再分别实现真实版与测试版：
// 真实实现（依赖 *sql.DB）
type sqlEmployeeService struct {
db *sql.DB
}
func (s *sqlEmployeeService) GetEmployeeByID(id int) (*Employee, error) {
row := s.db.QueryRow("SELECT id, name, age, salary FROM employees WHERE id = ?", id)
emp := &Employee{}
if err := row.Scan(&emp.ID, &emp.Name, &emp.Age, &emp.Salary); err != nil {
return nil, err
}
return emp, nil
}
// 测试实现（纯内存，无依赖）
type mockEmployeeService struct {
data map[int]*Employee
}
func (m *mockEmployeeService) GetEmployeeByID(id int) (*Employee, error) {
if emp, ok := m.data[id]; ok {
return emp, nil
}
return nil, errors.New("not found")
}⚠️ 注意事项：
- ❌ 避免“镜像式接口”（如
Database/DatabaseRows），它们泄露了 SQL 细节，增加测试负担且难以维护； - ✅ 接口粒度应由业务用例驱动，一个接口对应一类业务能力；
- ✅ 在单元测试中，直接注入
mockEmployeeService，无需启动数据库或处理连接池、事务等副作用； - ✅ 若需复用 SQL 逻辑，可将
*sql.DB封装为私有字段，但绝不暴露其原始类型或行为到接口契约中。
总结：Go 的接口不是为了模拟标准库类型而存在，而是为了抽象行为契约。放弃对 *sql.Rows 的强类型适配执念，转而封装业务语义，才能写出真正松耦合、易测试、可持续演进的 Go 代码。
