Golang数据访问对象模式实现与应用

DAO模式在Go中非必需，但利于隔离数据逻辑、切换数据源和单元测试；接口应窄，仅暴露必要操作；SQL层用database/sql原生API；事务由service控制；错误需精准分类。

DAO 模式在 Go 里不是必须的，但当你需要隔离数据逻辑、支持多数据源切换或做单元测试时，它确实能帮你把 db.Query 和业务逻辑剥离开——关键是别把它做成 Java 风格的抽象工厂套娃。

DAO 接口定义要窄，只暴露业务真正需要的操作

别一上来就定义 Save、UpdateByID、FindAllPaginated 这种大而全的接口。Go 的接口是隐式实现的，越小越灵活。比如用户模块只需要「按邮箱查」和「存新用户」：

type UserDAO interface {
    FindByEmail(email string) (*User, error)
    Create(u *User) (int64, error)
}

这样后续换数据库（PostgreSQL → SQLite）、加缓存层（加个 cacheUserDAO 包一层）或打桩测试都只需实现这两个方法，不会被冗余方法拖累。

SQL 执行层用 database/sql 原生 API，别封装死 sqlx 或 gorm

DAO 的实现体里直接用 db.QueryRow、db.Exec 等标准函数，好处是：

• 不绑定 ORM，避免 gorm.Model(&u).Where("id = ?", id).First() 这类隐藏 SQL 行为
• 错误处理更明确：你能区分 sql.ErrNoRows 和其他 error，而 GORM 的 RecordNotFound() 已被弃用且语义模糊
• 参数绑定清晰：原生 db.Query("SELECT * FROM users WHERE email = $1", email) 比 ORM 的 struct tag 映射更可控

如果项目已用 sqlx，可以保留其 StructScan 辅助解包，但 DAO 接口本身仍面向原生 *sql.DB。

事务控制必须由上层（service）发起，DAO 不管 commit/rollback

DAO 方法签名里不要出现 tx *sql.Tx 参数——这会让 DAO 变成事务感知的，破坏可复用性。正确做法是让 service 拿到 *sql.Tx 后，传给 DAO 的构造函数：

type userDAO struct {
    db *sql.Tx // 或 *sql.DB，运行时决定
}
func NewUserDAO(db any) UserDAO {
    switch d := db.(type) {
    case *sql.Tx:
        return &userDAO{db: d}
    case *sql.DB:
        return &userDAO{db: d}
    }
}

这样同一个 DAO 实现既能跑在事务里也能跑在普通连接上，而 service 控制何时调 tx.Commit()。

最容易被忽略的是错误分类：DAO 方法返回的 error 必须能区分「数据不存在」、「唯一键冲突」、「连接超时」等场景，否则上层 service 根本没法做精准重试或提示。建议用 errors.Is(err, sql.ErrNoRows) 判断缺失，用自定义 error 类型包裹数据库特有错误码（如 PostgreSQL 的 23505 唯一键）。