string不能直接接收null数据库字段，因go标准库主动拦截以防止语义混淆；必须用*string或sql.nullstring等null安全类型。
直接用 string 接收允许为 NULL 的数据库字段，一定会 panic —— 这不是配置问题，是 Go database/sql 的硬性约束。
为什么 string 不能直接 Scan NULL
Go 不会把 SQL 的 NULL 当作 “空字符串” 或 “零值” 自动转换。它明确拒绝这种语义混淆：sql: Scan error on column index 0: unsupported Scan, storing driver.Value type <nil> into type *string</nil>（注意日志里写的是 *string，实际错误根源是目标字段为非指针 string）。
只要数据库列定义为 NULL，且你结构体字段是 string、int64、time.Time 这类值类型，Scan 就会立即失败。
- 这不是驱动 bug，是标准库的主动拦截，防止业务误把 “缺失” 当 “默认”
-
NOT NULL字段可放心用值类型，无需额外包装 - 哪怕你确定某次查询“肯定不 NULL”，只要 schema 允许，就仍需按 NULL 安全方式处理
用 *string 是最简方案，但要注意解引用
Go 标准库原生支持 *string、*int64、*time.Time 等指针类型接收 NULL：遇到 NULL 时自动设为 nil；有值时分配内存并写入。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
JSON 序列化也天然友好：json.Marshal 对 nil *string 输出 null，对非 nil 输出字符串字面量。
- 声明字段为
Username *string，Scan时传&u.Username（必须取地址） - 使用前必须判空：
if u.Username != nil { use(*u.Username) }，否则 panic - 不要在 struct tag 里加
sql:"username"——database/sql不识别，纯属干扰 - 性能无损耗，没有额外内存分配或 GC 压力
sql.NullString 适合需要显式区分“未扫描”和“显式 NULL”
sql.NullString 是带 Valid bool 字段的结构体，Valid == false 表示该字段被扫描过且值为 NULL；Valid == true 才表示有有效字符串。
它比指针更重一点，但语义更精确 —— 比如你做审计日志，需要明确记录“用户没填昵称”（NULL）还是“查这条记录时根本没 SELECT 昵称字段”（字段未被扫描，Valid 保持初始 false）。
- 必须用
&u.Name传给Scan，否则不会修改字段内容 -
u.Name.String在!u.Name.Valid时是空串，直接拼接会出错：u.Name.String + " (optional)"→" (optional)" - JSON 输出需手动控制：
if u.Name.Valid { return json.Marshal(u.Name.String) } else { return []byte("null") }，或封装MarshalJSON - 整数、布尔、时间分别用
sql.NullInt64、sql.NullBool、sql.NullTime，别混用
别踩这些坑
很多问题不是逻辑难，是细节漏掉导致运行时崩：
- PostgreSQL 的
JSONB或 MySQL 的JSON字段即使允许NULL，也不能用sql.NullString扫——得用*string或json.RawMessage - 自定义枚举类型若可能为
NULL，别硬套sql.NullString，应封装自己的NullEnum - 用
gorp或其他 ORM 时，同样受database/sql约束：值类型字段遇NULL必报错，必须改指针或sql.NullXXX -
NULL不等于空字符串、零值、false —— 业务上是否要 fallback（比如把NULL显示为"-"），必须由你显式决定，没有魔法函数自动兜底
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
