应返回零值结构体+nil错误而非nil+sql.errnorows，以区分“查无结果”与“数据库异常”；避免包装sql.errnorows，字段优先用值类型确保零值安全，混用orm时需统一空对象适配。
Go 的 sql.QueryRow 返回 sql.ErrNoRows 时别直接返回 nil
DAO 层查不到数据，最常见的是 sql.QueryRow 执行后返回 sql.ErrNoRows。这时候如果直接返回 nil（比如 return nil, err），调用方就失去了区分「查无结果」和「数据库异常」的能力——两者都表现为 err != nil，但语义完全不同。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 显式判断
err == sql.ErrNoRows，然后返回一个有意义的空对象（如零值结构体）+nil错误，例如：return User{}, nil - 若业务上「查不到」属于正常流程（如查用户详情、查配置项），就不该让错误穿透到上层；只有网络中断、连接超时、语法错误等才该透出真实 error
- 避免在 DAO 层做
if err != nil { return nil, err }这种无差别转发，它把控制权交给了调用方，而调用方通常并不知道这个 error 是不是真的该 panic 或重试
定义「空对象」时注意结构体字段的零值是否安全
Go 没有「空对象模式」的语法糖，所谓空对象就是你手动构造的一个合法、可序列化、不引发 panic 的零值实例。但它是否真「安全」，取决于字段类型和后续使用方式。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 字段尽量用值类型（
int、string、time.Time），避免指针字段（如*string）在零值时是nil，导致下游if u.Name != nil判断意外失效 - 如果必须保留指针字段（比如为了区分「未设置」和「设为空字符串」），那空对象里就别用
&""这种假指针，而是统一设为nil，并在文档里写清语义 - 对嵌套结构体（如
User.Profile），空对象里也要递归初始化为零值，否则u.Profile.AvatarURL会 panic
别在 DAO 层用 errors.Is(err, sql.ErrNoRows) 包装新错误
有些同学想“更明确地表达语义”，把 sql.ErrNoRows 转成自定义错误，比如 errors.New("user not found")。这反而破坏了错误分类能力——上层无法再用 errors.Is(err, sql.ErrNoRows) 做统一处理，也丢失了原始错误链中的上下文（比如哪条 SQL、哪个参数）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 除非你确定整个服务都弃用
sql.ErrNoRows并统一用自定义错误体系，否则不要包装它 - 如果真要加语义，用
fmt.Errorf("get user by id %d: %w", id, err)，保留%w，这样errors.Is依然能命中原错误 - 警惕日志中反复打印同一行
sql.ErrNoRows：它不是异常，只是查询结果为空，日志级别建议设为debug或关掉
ORM（如 GORM）默认行为可能掩盖空对象意图
GORM 的 First、Take 等方法在查不到时默认返回 gorm.ErrRecordNotFound，它和 sql.ErrNoRows 不同源。如果你混用原生 database/sql 和 GORM，又试图用同一套空对象逻辑兜底，就会漏判。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 项目里只选一种数据访问方式，避免 DAO 层同时出现
db.QueryRow和gorm.DB.First - 如果必须共存，封装一层适配器，在 GORM 调用后显式检查
errors.Is(err, gorm.ErrRecordNotFound)，并转为一致的空对象返回约定 - GORM v2 的
Find方法返回切片，查不到是空切片（[]User{}），这不是错误——注意别把它和First的错误返回混淆
