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语言免费学习笔记（深入）”；
技术上面应用了三层结构，AJAX框架，URL重写等基础的开发。并用了动软的代码生成器及数据访问类，加进了一些自己用到的小功能，算是整理了一些自己的操作类。系统设计上面说不出用什么模式，大体设计是后台分两级分类，设置好一级之后，再设置二级并选择栏目类型，如内容，列表，上传文件，新窗口等。这样就可以生成无限多个二级分类，也就是网站栏目。对于扩展性来说，如果有新的需求可以直接加一个栏目类型并新加功能操作
- 不绑定 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 唯一键）。
