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 等标准函数，好处是：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不绑定 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 唯一键）。
