Go问答：sql.NullString数据库 NULL 扫描后为什么变成空字符串为什么结果为空或不符合预期

如果数据库列允许为 NULL，直接把它扫描到 string 并不能表达“没有值”和“值为空”的区别。sql.NullString 看起来像是读出了空字符串，通常不是 NULL 被偷偷改写，而是你只看了 String，没有同时判断 Valid。

官方文档：https://pkg.go.dev/database/sql

判断可空字符串时，Valid=false 表示数据库值为 NULL；Valid=true 时才读取 String。因此空字符串是“有值但长度为 0”，NULL 是“没有值”，两者不能只靠 String 区分。

先把要保护的数据契约说清楚

这里真正需要保护的是字段语义：数据库中的 NULL 不能在扫描层被静默压成业务默认值，否则下游无法区分“用户没有填写昵称”和“用户明确填写了空字符串”。可以把风险分成三档：

• 低风险：展示层只需要显示为空，NULL 和空字符串确实可以合并。
• 中风险：更新接口需要判断是否改动字段，此时必须保留两种状态。
• 高风险：审计、导出或计费字段依赖“是否存在”，只能把 Valid 纳入业务契约。

这也是为什么 sql.NullString 有两个字段：String 存放文本，Valid 存放这个文本是否对应一个非 NULL 的数据库值。

为什么看起来像空字符串

可以用三种输入来理解结果：SQL NULL、长度为 0 的空字符串、普通文本。它们都经过 Scan，但只有前者会让 Valid 为 false。

package main

import (
	"database/sql"
	"fmt"
)

func printName(value any) {
	var name sql.NullString
	// Scan 的目标保留 NULL 状态，不能只声明一个 string。
	if err := name.Scan(value); err != nil {
		fmt.Printf("扫描失败: %v\n", err)
		return
	}
	// Valid=false 代表 NULL；Valid=true 时 String 才是有值结果。
	fmt.Printf("String=%q Valid=%t\n", name.String, name.Valid)
}

func main() {
	printName(nil)  // 数据库 NULL 的等价输入
	printName("")   // 有值但长度为零
	printName("Go") // 普通文本
}

因此，日志中看到 String="" 还不能推出数据库里就是空字符串。先看 Valid：false 才是 NULL 的关键信号。

把可空状态交给业务层

扫描完成后不要急着把值转成普通字符串。更稳妥的做法是先建立一个小的映射边界：Valid 为 false 时输出指针 nil 或 JSON null；为 true 时保留 String，即使它是空字符串。

package main

import (
	"database/sql"
	"encoding/json"
	"fmt"
)

type profile struct {
	Nickname *string `json:"nickname"`
}

func toProfile(value sql.NullString) profile {
	// NULL 映射为 nil，让 JSON 保留 null；空字符串仍然保留为非 nil 指针。
	if !value.Valid {
		return profile{}
	}
	return profile{Nickname: &value.String}
}

func main() {
	data, err := json.Marshal(toProfile(sql.NullString{String: "", Valid: true}))
	if err != nil {
		fmt.Println("编码失败:", err)
		return
	}
	fmt.Println(string(data))
}

如果接口需要区分“未提供”和“明确清空”，还要继续区分请求字段是否出现，不能只靠响应结构体的一个指针。sql.NullString 解决的是数据库扫描边界，更新语义仍然需要由 API 契约单独定义。

错误处理要挡住三条风险路径

把字段类型改成 sql.NullString 后，仍然要处理查询本身的错误。最容易遗漏的是把所有异常都当成“没有昵称”，这样会掩盖连接、驱动或 SQL 问题。

var name sql.NullString
err := db.QueryRowContext(ctx, query, id).Scan(&name)
if err != nil {
	// ErrNoRows 表示没有匹配记录，不等于匹配记录的字段是 NULL。
	if err == sql.ErrNoRows {
		return profile{}, fmt.Errorf("用户不存在: %w", err)
	}
	// 其它错误要原样保留上下文，不能伪装成空字段。
	return profile{}, fmt.Errorf("读取昵称失败: %w", err)
}

result := toProfile(name)
return result, nil

使用 Rows 时还要在循环结束后检查 rows.Err()，因为迭代期间的驱动错误不会由某一行的 Scan 自动替代。必要时也要按项目约定关闭 rows，避免资源泄漏。

上线前的判断清单

• 看到 String="" 时，是否同时记录并判断 Valid？
• 查询无行是否与“有一行但字段为 NULL”分开处理？
• 接口是否明确 NULL、空字符串和字段未出现的区别？
• 扫描、迭代和关闭结果集的错误是否都保留了上下文？

一句话记忆：sql.NullString 不是把 NULL 变成字符串的工具，而是把“文本值”和“是否存在”一起带过数据库边界的容器。只有业务确实不关心缺失语义时，才应该在更靠后的展示层把它们合并。

相关问题

sql.NullString 的 Valid 为 true 但 String 为空，正常吗？

正常，这表示数据库值不是 NULL，只是文本长度为 0。

查询不到记录时可以看成 NullString.Valid=false 吗？

不可以。查询不到记录通常由 sql.ErrNoRows 表示，根本没有可供扫描的那一行。

能不能直接把 NULL 扫描到 *string？

可以按驱动和项目约定选择指针，但 sql.NullString 的状态字段更直白，适合在数据库边界明确记录扫描结果。