string不能直接接收NULL数据库字段，因Go标准库主动拦截以防止语义混淆；必须用*string或sql.NullString等NULL安全类型。
如果你试图直接用 string 类型去接收一个允许为 NULL 的数据库字段，程序一定会 panic。这可不是什么配置问题，而是 Go 语言 database/sql 标准库定下的硬性规矩。
为什么 string 不能直接 Scan NULL
Go 的设计哲学很明确：它不会自作主张地把 SQL 里的 NULL 偷偷转换成 Go 里的“空字符串”或者“零值”。为什么？就是为了避免语义上的混淆。你猜错误信息会是什么？通常是这样的：sql: Scan error on column index 0: unsupported Scan, storing driver.Value type 。注意看，日志里虽然写的是 *string，但问题的根源往往是你用了非指针的 string 类型。
一句话总结：只要数据库表里的列定义允许为 NULL，而你的 Go 结构体里对应的字段是 string、int64、time.Time 这类值类型，那么 Scan 操作就会立刻失败。
- 这可不是数据库驱动的 bug，而是标准库主动设下的“拦截网”，目的就是防止业务逻辑里稀里糊涂地把“数据缺失”当成了“默认值”。
- 反过来，对于那些定义为
NOT NULL的字段，你大可以放心使用值类型，不需要任何额外包装。 - 这里有个关键点：哪怕你百分之百确定某次查询的结果“肯定不是 NULL”，但只要数据库表结构（schema）允许该列为空，你就必须按照处理 NULL 的安全方式来写代码。
用 *string 是最简方案，但要注意解引用
最直接的解决方案是什么？用指针。Go 标准库原生就支持用 *string、*int64、*time.Time 这类指针类型来接收 NULL。它的工作机制很清晰：遇到 NULL 时，指针会被设为 nil；遇到有值的情况，则会分配内存并把值写进去。
立即学习“go语言免费学习笔记（深入）”；
而且，指针方案对 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 就派上用场了。它是一个内置的结构体，内部包含一个 String 字段和一个 Valid bool 字段。当 Valid == false 时，表示该字段被扫描过且值就是 NULL；只有 Valid == true 才表示存有有效的字符串。
它比指针方案稍微“重”一点，但优势在于语义的精确性。举个例子，假如你在做审计日志，需要明确区分“用户没填昵称”（数据库存的就是 NULL）和“查询这条记录时根本没 SELECT 昵称字段”（字段压根没被扫描，Valid 保持初始的 false），这时候 sql.NullString 就能帮上忙。
- 同样，必须用
&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类型字段，即使允许NULLsql.NullString来扫描。正确的做法是使用*string或者json.RawMessage。 - 如果你有自定义的枚举类型，并且它可能为
NULL，别强行套用sql.NullString，最好封装一个自己的NullEnum类型。 - 即使你使用了
gorp或其他第三方 ORM，同样受到database/sql底层约束：值类型字段遇到NULL必定报错，必须改用指针或sql.NullXXX类型。 - 最后，也是最重要的概念：数据库中的
NULL不等于空字符串、不等于零值、也不等于 false。在业务层面上，是否需要提供一个回退值（比如把NULL在界面上显示为"-"），必须由开发者显式地决定和处理，Go 没有提供任何“魔法函数”来自动兜底。
