golang如何处理数据库NULL值_golang数据库NULL值处理方法

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 into type *string。注意看，日志里虽然写的是 *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 没有提供任何“魔法函数”来自动兜底。