在 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:
✅ 正确姿势：使用 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*，你的数据库层代码将既简洁、高效，又具备生产级可靠性。
