如何优雅处理数据库查询中的 NULL 值（Go 语言最佳实践）

在 go 中使用 `database/sql` 查询数据库时，直接扫描 `nil` 字段到 `*string` 等基础类型会 panic；正确方式是使用 `sql.nullstring` 等专用空值类型，并结合结构体嵌入或自定义类型提升可读性与可维护性。

Go 的 database/sql 包不会自动将 SQL 的 NULL 映射为 Go 的零值（如 "" 或 0）——这是有意设计，因为 NULL 在语义上明确表示“缺失值”，而非“空字符串”或“未初始化”。因此，当你尝试 rows.Scan(&s) 且数据库字段为 NULL，而 s 是 *string 或 string 时，就会触发 unsupported driver -> Scan pair: -> *string 错误。

✅ 正确姿势：使用 sql.NullString 等标准空值类型

Go 标准库提供了专为数据库 NULL 设计的类型：

• sql.NullString → 对应 string
• sql.NullInt64、sql.NullFloat64、sql.NullBool
• 所有类型均含 .Valid bool 字段（true 表示非 NULL，false 表示 NULL）

type udInfo struct {
   
 ID    sql.NullString `db:"id"`
    State sql.NullString `db:"state"`
}

func GetInfo(ud string) udInfo {
    db := getFileHandle()
    defer db.Close() // 注意：建议移至函数末尾统一 defer

    q := "SELECT id, state FROM Mytable WHERE id = ?" // ❗ 使用参数化查询，防止 SQL 注入
    row := db.QueryRow(q, ud) // 更简洁：单行用 QueryRow

    var info udInfo
    err := row.Scan(&info.ID, &info.State)
    if err != nil {
        log.Fatal("scan failed:", err)
    }

    return info
}

✅ 优势：无需额外转换函数、无冗余字节切片、25+ 字段也清晰可读；sql.NullString 内部已高效处理 []byte → string 转换，性能优于手动 []byte 处理。

? 进阶技巧：封装为业务友好型字段（推荐）

若你希望对外暴露 string 类型（如 info.ID.String()），但内部仍安全处理 NULL，可定义方法：

func (u udInfo) IDString() string {
    if u.ID.Valid {
        return u.ID.String
    }
    return "" // 或返回 "N/A", 或 panic("ID is NULL") —— 按业务语义决定
}

func (u udInfo) StateName() string {
    if u.State.Valid {
        return stateName(u.State.String) // 你的业务逻辑
    }
    return ""
}

调用时即自然、安全：

info := GetInfo("123")
fmt.Println(info.IDString(), info.StateName()) // 自动处理 NULL → ""

⚠️ 关键注意事项

• 永远避免字符串拼接 SQL：原代码 WHERE id='%s' 存在严重 SQL 注入风险。✅ 务必改用参数化查询（? 占位符 + 可变参数传递）。
• defer 位置要合理：defer db.Close() 应放在 db := getFileHandle() 后立即执行，确保资源释放；defer rows.Close() 在 Query 后立刻 defer。
• 不要用 []byte 手动模拟 NULL 处理：CToGoString 和双结构体模式既低效又易错（如 C 字符串零截断逻辑不适用于通用 DB 字段），且违背 Go 的类型安全哲学。
• *批量字段？用结构体 + `sql.Null完全可扩展**：25 个字段只需在结构体中声明 25 个sql.NullString/sql.NullInt64字段，Scan` 一行搞定，清晰、安全、无性能损失。

✅ 总结：Go 处理数据库 NULL 的 idiomatic 方式

方式	是否推荐	说明
sql.NullString 等标准类型	✅ 强烈推荐	类型安全、标准库支持、零额外开销、语义明确
自定义 *string + if != nil 判断	❌ 不推荐	Scan 本身不支持 *string 接收 NULL，会 panic
[]byte 中转 + 手动转换	❌ 不推荐	低效、易错、破坏抽象、难以维护
第三方 ORM（如 GORM）的 null.String	⚠️ 可选	若项目已引入 ORM，其封装更友好；但纯 database/sql 场景，标准 sql.Null* 已足够

Go 并非“不优雅处理 NULL”，而是要求开发者显式表达对缺失值的语义意图——这正是其健壮性的体现。用好 sql.Null*，你的数据库层代码将既简洁、高效，又具备生产级可靠性。