必须用sql.NULLString当数据库字段允许null且用string接收时，否则scan报错；字段定义not null或业务确保非null时可用原生string。
sql.NullString 什么时候必须用，什么时候可以不用
go 的 database/sql 包不会自动把数据库里的 NULL 映射成 Go 的零值（比如空字符串），而是直接报错：sql: Scan Error on column index 0: unsupported Scan, storing driver.Value type <nil> into type *string</nil>。所以只要字段在数据库里允许为 NULL，且你用的是普通 string 类型接收，就一定会崩——这时候 sql.NullString 不是“可选优化”，是刚需。
反过来说：如果字段定义了 NOT NULL，或者你确定永远不会有 NULL（比如刚插入的记录、有严格业务校验），那用原生 string 更干净，没必要套一层 sql.NullString。
- 常见错误现象：用
string接收可能为NULL的列，查询时 panic 或静默失败 - 性能影响极小，只是多一个
Valid bool字段，无额外内存分配或 GC 压力 - 注意：它不是泛型，
sql.NullInt64、sql.NullBool等需按类型分别选用
Scan 到 Struct 时怎么正确绑定 sql.NullString
不能直接在 struct 字段上写 string，得显式声明为 sql.NullString，然后靠 Scan 自动识别其 Scan 方法。否则会因类型不匹配跳过赋值，字段保持零值但 Valid 仍为 false，容易误判。
示例：
立即学习“go语言免费学习笔记（深入）”；
type User struct { ID int Name sql.NullString Email sql.NullString } var u User err := db.QueryRow("SELECT id, name, email FROM users WHERE id = ?", 1).Scan(&u.ID, &u.Name, &u.Email) if err != nil { // 处理 err } // 使用前必须检查 Valid if u.Name.Valid { fmt.Println("Name:", u.Name.String) } else { fmt.Println("Name is NULL") }- 必须取地址传给
Scan（&u.Name），否则不会修改原字段 -
sql.NullString.String是值，不是方法；它只是个普通字段，和Valid并列 - 别在 struct tag 里加
sql:"name"这类——标准库不认，纯属干扰
从 NullString 安全转回 string 的三种写法及区别
没有“默认 fallback”的魔法函数，你要自己决定 NULL 时返回什么。最常见的是空字符串、占位符或 panic，但每种都有隐含逻辑风险。
-
u.Name.String：不管Valid直接取值——NULL时返回空字符串，但你无法区分“真是空”还是“数据库 NULL” -
if u.Name.Valid { ... } else { ... }：推荐。明确分离两种语义，避免数据污染 -
u.Name.String + " (Nullable)"类拼接：危险！NULL时String是空串，结果变成" (nullable)"，业务逻辑可能出错
特别注意：sql.NullString 的零值是 {String: "", Valid: false}，所以新声明的变量默认就是 “NULL 状态”，别依赖初始化值做判断。
ORM（如 GORM）里要不要还手动用 sql.NullString
GORM v2 默认会自动处理 NULL：字段声明为 *string 就能接 NULL，sql.NullString 反而会被当成普通 struct 处理，导致扫描失败或字段被忽略。
- GORM 推荐写法：
Name *string（指针），NULL→nil，非空 → 指向字符串 - 如果你混用
database/sql原生查询和 GORM，保持类型统一反而更麻烦，建议全切到一种风格 - 第三方驱动（如 pgx）可能提供更高级的
NullXXX类型，但跨库迁移成本高，除非真有性能瓶颈，否则 sticking withsql.Null*更稳
最易被忽略的一点：json 序列化时，sql.NullString 默认输出为 {"String":"xxx","Valid":true}，不是字符串。要兼容 API 返回，得自己实现 MarshalJSON，或者中间转成 *string 再序列化。