Go语言中字符串字段在ORM模型映射中的零值与NULL处理探讨-Golang-PHP中文网

go结构体string字段零值为""，无法表示null；需用*string或sql.nullstring区分“空字符串”与“未设置”，orm映射时须匹配数据库null约束。

go语言中字符串字段在orm模型映射中的零值与null处理探讨

Go结构体字符串字段默认值是空字符串，不是NULL

Go语言中string是值类型，零值固定为""（空字符串），没有null概念。ORM（如GORM、SQLX）映射时，若结构体字段声明为string，即使数据库该列为NULL，查询后也会被自动转成""；反之，插入""会写入空字符串而非NULL。这不是ORM bug，而是Go类型系统的自然表现。

常见错误现象：
– 数据库某字段允许NULL，但Go模型用string接收，结果查不到“未填写”和“填了空格”之间的区别；
– 插入时想存NULL，却误存了""，导致后续WHERE name IS NULL查不到数据。

若需区分“未设置”和“设为空字符串”，必须改用*string（指向字符串的指针）
*string的零值是nil，ORM能将其映射为SQL NULL（前提是驱动和ORM支持）
GORM v2 默认支持*string → NULL双向映射；SQLX需配合sql.NullString或自定义Scan/Value方法

GORM中`*string`与`sql.NullString`怎么选

两者都能表达可空字符串，但语义和行为不同。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。

下载

*string更轻量、更Go idiomatic，GORM直接识别并生成IS NULL条件，例如db.Where("name IS NULL").Find(&users)可正常工作
sql.NullString是标准库类型，包含String字段和Valid布尔标记；GORM也支持，但查询条件需显式写db.Where("name IS NULL")，不能用db.Where("name = ?", sql.NullString{})
性能差异微乎其微，但*string在JSON序列化时默认为null（符合API习惯），而sql.NullString序列化后是{"String":"","Valid":false}，需额外处理
注意：GORM的Updates方法对*string字段有特殊逻辑——传nil会跳过更新，不设为NULL；要强制置NULL，得用map[string]interface{}{"name": nil}或Select("name").Updates(...)

数据库迁移时字符串列的`NULL`约束必须与Go模型对齐

哪怕ORM支持*string，如果数据库列定义为NOT NULL，插入nil仍会报错ERROR: null value in column "name" violates not-null constraint。

建表或修改列时，确认DDL含NULL（例如ALTER TABLE users ALTER COLUMN name DROP NOT NULL）
使用GORM AutoMigrate时，*string字段默认生成NULL列，但若已有表且原列为NOT NULL，AutoMigrate不会自动删约束——得手动执行SQL或用gorm.ModifyColumn
PostgreSQL中""和NULL在索引、唯一约束、COALESCE中行为完全不同，比如UNIQUE (email)允许多行NULL，但不允许多行""

API输入校验时别混淆`""`、`nil`和空白字符串

用户提交{"name":""}应视为“明确清空”，而缺失name字段才是“未提供”。但JSON反序列化到*string时，两者都变成nil，无法区分。

解决方案一：用map[string]interface{}先解析，检查key是否存在，再决定赋nil还是&""
解决方案二：加一个SetByName标志字段，如SetEmail bool `json:"set_email,omitempty"`，配合*string
更稳妥的做法：API约定空字符串""代表“清空”，字段缺失代表“忽略更新”，此时模型仍用*string，但反序列化后检查json.RawMessage是否包含该key
别忘了trim空格：strings.TrimSpace后再判断，否则" "会被当成有效值，但实际可能是误操作