GORM开发必备：Go结构体字段用值类型还是指针？

做Go后端开发，天天跟GORM打交道的人迟早会纠结一个问题：表结构对应的struct字段，到底要不要用指针？这问题没有标准答案，但我可以从一个线上事故讲起。之前维护一个订单管理系统，前端提交"把商品数量改成0"，后端接口返回成功，数据库里的数量却纹丝不动。数据库字段是int，模型字段也是int，代码逻辑看着也没毛病，可就是更新不进去。

后来排查才发现，问题出在GORM对结构体零值的处理方式上。这不是个例，几乎所有用GORM做业务的项目都会遇到类似的坑。这篇文章我想把"字段用不用指针"这件事彻底讲透：什么场景该用、什么场景千万别用、用了之后会带来哪些连锁反应，以及我最终沉淀下来的一套设计规范。适合正在写Go业务接口、经常被GORM零值坑到怀疑人生的同学参考。

1. 先把问题问清楚：值类型在ORM里到底"丢失"了什么

1.1 一个让我印象深刻的订单数量事故

我之前维护的那个订单系统，商品明细表大概长这样：

type OrderItem struct { ID uint SkuID uint Count int // 商品数量 }

更新数量的代码：

db.Model(&item).Updates(OrderItem{Count: 0})

前端把数量改成0的时候，后端接收到的确实是Count: 0，接口也返回了成功。但数据库里的行纹丝不动。我一度以为是事务没提交，后来把SQL日志打开，发现GORM生成的UPDATE语句里压根没有count字段。

问题就出在Count: 0上。对GORM来说，结构体字段的"零值"（0、""、false、nil）默认会被认为"这个字段没修改"，所以Updates直接跳过它。这就是经典的"零值陷阱"。

这个例子跟"要不要用指针"有什么关系？关系很大。如果当时Count是*int，我传一个指向0的指针，GORM就会发现"这个字段不是nil、是被显式赋值的"，从而正常执行更新。指针在这里解决的不是风格问题，而是表达能力问题。

1.2 值类型与NULL：Go的零值不等于数据库的NULL

Go里每个值类型都有零值：string的零值是""、int的零值是0、time.Time的零值是公元1年1月1日。关键是，这些零值和数据库里的NULL完全是两码事。

数据库里NULL表达的是"没有值"、"未知"、"从未填写过"。而0和""是"有值，只不过是零"。对很多业务而言，这两者有本质区别：用户评分没评过（NULL）和评了0分（0）能一样吗？手机号没绑定（NULL）和绑定了空字符串（""）能一样吗？商品库存未录入（NULL）和明确是0件（0）更是天壤之别。

值类型的问题在于：它只有"零值"这个位置，没有"空位"。一个string字段要么是""、要么是别的字符串，它没办法表达"这里压根没填"。当数据库返回NULL时，GORM扫描到string字段会静默变成""，扫描到int字段会变成0。于是"未填写"和"填了0"被无差别抹平了。

1.3 GORM更新结构体时对零值的特殊处理

GORM v2的Updates方法有个官方文档里讲得比较含蓄、但实际影响很大的行为：当传入结构体时，只有非零值字段会被更新。

db.Model(&user).Updates(User{Name: "", Age: 0}) // 生成的SQL：什么都没更新，因为字段都是零值 db.Model(&user).Updates(map[string]interface{}{"name": "", "age": 0}) // 这样写才会更新，map不走零值判断

这还不是全部。就算数据库某列本身允许NULL，你用值类型字段去更新，也只能写入零值 "" 或 0，没法写入真正的NULL。举个例子，用户清空了昵称，你想把这个字段置为NULL表示"未设置"，用string字段是做不到的——它只会把列更新成空字符串。

这时候把字段改成*string，行为立刻不同：

var empty = "" db.Model(&user).Updates(User{Name: &empty}) // Name指针不为nil，GORM会把它更新成 ""

如果把指针置为nil，配合Select还可以更新成数据库NULL。这就是指针类型在ORM里最大的价值：把"零值"和"NULL"从两个不同的维度解放出来。

2. 指针类型的真实能力：三态表达与读写NULL

2.1 nil、空值、具体值——三种业务状态

我一直觉得，指针在ORM里最大的意义不是"性能"也不是"风格"，而是它让字段具备了三种状态：

• nil：从未赋值，对应数据库NULL
• 指针指向零值（如&""、&0）：显式赋值了，但值是空的/零
• 指针指向具体值：有真实内容

用三个状态去锚定业务语义，"未填写"、"填写为空"、"填写了具体内容"就都能表达。有些系统里这个需求非常刚性。比如一个"备注"字段，业务上必须区分：用户没填（显示"暂无备注"）、用户填了空字符串（前端表单允许提交空串）、以及用户写了实际内容。

如果用string字段，第一种和第二种会被合并；如果用*string，nil表示没填、&""表示填了空、&"具体内容"表示正常，干干净净。产品同学要的报表维度，代码里直接就能拆出来。

2.2 指针在创建、查询、更新中的具体行为

针对GORM，把指针字段的行为拆开看会更清楚。

创建（Create）时，值类型字段会直接写入当前值（零值也会写进去），所以如果你想插入NULL，只能靠指针或者自定义类型：

nickname := "张三" db.Create(&User{Nickname: &nickname, Phone: nil}) // Nickname 插入 "张三"，Phone 插入 NULL

查询（Find）时，指针和值类型的差异体现在NULL列的读取结果上：

var u User db.First(&u, 1) // 如果 phone 列是 NULL，u.Phone == nil // 如果 phone 列是 ""，u.Phone != nil 且 *u.Phone == ""

这种差异在后续逻辑里能做真正的分支，而不是靠零值猜业务状态。

更新（Updates）时，规则要记清楚：

db.Model(&u).Updates(User{Phone: nil}) // 默认忽略，不会把字段置NULL db.Model(&u).Select("Phone").Updates(User{Phone: nil}) // 把Phone置NULL db.Model(&u).Updates(User{Phone: &phone}) // 更新为phone变量的值

注意一个容易被新手绕晕的点：指针的"零值"是nil，所以Updates判断"这个字段是否被修改"时，看的是"指针是否为nil"，而不是"指针指向的值是不是零值"。这是个很大的区别。只要指针不为nil，哪怕它指向的是""或0，GORM也会照单全收。

2.3 用表结构对照看：AutoMigrate后的列差异

在实际项目里，我经常用AutoMigrate建表，所以专门对比过这两者的迁移结果。以MySQL为例，大致是这样一个关系（不同版本的GORM和数据库方言会有细节差异，但思路一致）：

想强制非空也很简单，加tag：

Phone string `gorm:"not null;size:20"`

不过提醒一句：AutoMigrate只负责建表和简单的列变更，如果线上已经有一张老表、列属性跟新模型不一致，GORM未必会自动改列的可空属性。所以字段类型决定得对不对，最好在项目早期定下来，后面再去改，往往要写一堆数据订正脚本。

3. 什么样的字段该用指针：按业务语义分类的选型清单

3.1 建议使用指针的字段类型

我自己的经验是，出现下面这些情况的字段，优先考虑指针：

• 业务上允许"未填写"的字符串，比如手机号、昵称、头像URL、地址备注。用户可能压根没绑过手机，这和"他绑了个空手机号"显然不是一回事。
• 数值0有特殊业务含义、同时还需要区分"未设置"的字段，比如折扣率（0表示无折扣，未设置表示还没配）、评分、积分。这里0不是"没有"，而是"明确是零"，必须和"没填"分开。
• 可空的外键ID，比如一个商品的运营ID，业务上可能还没有分配，用*uint很自然。
• 某些枚举，比如性别，用*string或*int都行，nil代表未知，值代表明确的枚举。
• 所有你希望API返回null、而不是0或""给前端的字段。这个需求很常见：前端拿到null才知道要显示"暂无"。

3.2 坚决使用值类型的字段类型

反过来，下面这些字段我不会用指针：

• 数据库里有默认值的必填字段，比如创建时间、更新时间，统一用值类型time.Time。
• 业务上0就是合法有效值的数值，比如库存数量、订单金额、状态码。库存为0就是"没有库存"，不需要再用nil表达一层"未设置"，反而把逻辑搞复杂。
• 主键ID。主键永远非空，也不该是指针。
• 逻辑删除字段。GORM已经内置了gorm.DeletedAt，它内部本身就是可空结构，不用自己再拼一个*time.Time去实现软删除。

值类型最大的好处是：代码写起来简单、心智负担小。读出来直接用，不用到处解引用、判nil。只要业务不需要区分"零值"和"NULL"，就用值类型，这是性价比最高的选择。

提示：值类型没有NULL表达能力，但这不等于"值类型不好"。如果你的业务不需要区分NULL和零值，值类型永远是最简单直接的选择。

3.3 time.Time字段的特殊处理

time.Time是个很特殊的类型，它的零值是公元1年1月1日，序列化成JSON是"0001-01-01T00:00:00Z"，非常难看。如果你有"有效期""最后登录时间"这类可选时间字段，我建议用*time.Time。因为：

• nil表示"从未有过"
• 非nil表示一个真实时间
• 避免了"0001年"这种写着像bug的时间出现在API里

创建时间和更新时间则永远用值类型，因为它们在创建记录时一定存在，而且GORM会自动填充：

type User struct { ID uint `gorm:"primaryKey"` CreatedAt time.Time UpdatedAt time.Time LastLoginAt *time.Time // 可空，没登录过就是nil DisabledAt *time.Time // 可空，没禁用就是nil }

4. 指针的代价与副作用：JSON、内存、查询的连带影响

4.1 前后端交互：null与空字符串的语义差异

用了指针之后，最直接的变化出现在JSON序列化上。一个*string字段为nil时，输出是null；为&""时输出是""。如果模型直接当API的响应体用，这个差异前端程序员会非常敏感：

{ "phone": null, "nickname": "", "avatar": null }

不过这里有个连带问题：很多人习惯在字段上加json:"phone,omitempty"。对值类型来说，omitempty会把零值丢掉；对指针来说，omitempty会把nil丢掉，但一个指向""的指针不是nil，也会被保留。所以如果你期望"空的时候字段就不出现"，指针 + omitempty 并不能完全满足，还得自己写自定义MarshalJSON，或者接受"null出现"这个语义。

我自己在这块的原则是：既然是显式建模可空字段，API面向的语义就明确为"null = 未设置"，前端按这个约定处理，避免再用omitempty这套模糊方案。

4.2 内存分配与GC压力：值类型和指针谁的性价比更高

性能这块常被拿出来说，但得分清楚量级。一条记录里有几个指针字段，查询10万行，多出来的也就是每个指针8字节的引用加若干次堆分配。Go的逃逸分析下，指针变量的实际目标多数时候会逃逸到堆上，GC确实多了一些扫描负担。对于普通业务系统，这个开销影响很小，远不如一条慢SQL来得致命。

但如果你在写高频小对象循环，比如消息推送的批量组装、高频埋点上报，那就不建议滥用指针。大量小对象加指针，分配次数翻倍，GC压力确实会上去。这种场景优先值类型，实在需要可空语义，可以在业务层单独约定一个"默认值代表空"的规则，比如用-1表示未设置。

一句话总结：架构层面的正确性大于微小的内存开销。先用指针把语义表达正确，等性能画像证明这里有瓶颈，再考虑优化。

4.3 条件查询里nil的用法：查NULL字段别踩坑

指针也带来了查询上的便利：

db.Where("phone IS NULL").Find(&users) // 硬编码SQL db.Where("phone = ?", nil).Find(&users) // GORM会把nil转成IS NULL db.Where("phone = ?", "").Find(&users) // 查显式为空的字符串

这里GORM对nil参数有特殊处理，会生成IS NULL，而""会生成= ""，两种条件查出来的结果完全不同。很多踩坑案例就是：模型字段是值类型，查询时拿""当"空"去拼条件，结果把NULL的行全漏掉了。一旦模型改成指针类型，"没设置"和"填了空"这两类行就能精确命中。

不过也要注意：对可空列做等值查询时，如果列值本身有NULL，逻辑上仍然要处理三态：NULL、空串、有值。这和SQL的三值逻辑一样，不是简单的"非空即非null"。

5. 不止有指针：可空字段的替代方案与对比

5.1 sql.NullString等官方可空类型的局限

Go标准库提供了一组可空类型：sql.NullString、sql.NullInt64、sql.NullBool、sql.NullTime。GORM对它们的支持也算到位，会自动识别。

type User struct { Phone sql.NullString }

问题在于用起来很啰嗦。每次读写都要经手.Valid：

if u.Phone.Valid { fmt.Println(u.Phone.String) }

更麻烦的是JSON序列化。sql.NullString默认序列化的格式是{"String":"...","Valid":true}这种结构，前端根本没法直接当字符串用，往往还要自写类型。相比之下，指针类型本身就是原生Go类型，序列化结果是null或普通值，和前端约定起来自然得多。

5.2 用map[string]interface{}更新零值的经典方案

指针不是处理"更新零值"的唯一手段，GORM的map[string]interface{}也可以：

db.Model(&user).Updates(map[string]interface{}{ "count": 0, "note": "", })

这种方式完全不依赖字段类型，零值也能更新。问题是map写法丢失了结构体更新的类型安全和字段约束，字段名写错了GORM只会在执行时报错，编译期查不出来。而且map里传的值最终还是会进数据库，如果你想让某列变NULL，map里也得填nil，这时候又回到了"最终写入值"的类型问题。

所以我的习惯是：

• 偶尔一次零值更新，用map + Select解决；
• 模型里可空字段长期要表达NULL语义，直接上指针，从根上解决，不靠每次写代码时绕。

5.3 指针 vs 替代方案：一个综合对比表

表格之外我想强调一点：方案选型不是越复杂越好。80%的字段用值类型就够了，20%真正需要NULL语义的字段再上指针。如果一整个struct全是指针，代码里到处都是*u.Name的解引用和判空，那说明建模本身偷懒了。

6. 一份可以直接用的struct字段设计规范

6.1 我目前的统一规则（附完整示例）

经过几次重构之后，我给自己定了一套规则，现在在多个项目里都这么用：

1. 主键、外键（非空）一律值类型；
2. 必填业务字段一律值类型；
3. 业务允许"未设置"的字段，且需要和零值区分的，一律指针；
4. 创建时间、更新时间一律值类型time.Time，可选的"最后操作时间"用*time.Time；
5. 枚举字段能不用指针就不用，用值类型+常量约定，除非真的要区分"未知/未设置"；
6. 状态字段（如启用/禁用）用值类型bool或int，0/1足够表达。

套到一个用户模型里大概是这样的：

type User struct { ID uint `gorm:"primaryKey"` Account string `gorm:"size:50;not null;uniqueIndex"` Nickname string `gorm:"size:50;not null"` Phone *string `gorm:"size:20"` Email *string `gorm:"size:100"` Gender *int // nil=未知, 1=男, 2=女 Age *int // nil=未填写 AvatarURL *string `gorm:"size:255"` LastLoginAt *time.Time CreatedAt time.Time UpdatedAt time.Time }

这套规则背后就是一句设计准则：字段的可空性就是业务语义的一部分，用类型把它显式表达出来，不要写在注释里靠人记。

6.2 可空字段的tag怎么写才算规范

指针类型只解决Go层面的NULL表达，数据库层面还涉及DEFAULT、索引这些。踩过坑之后我总结出几个tag写法要点：

• 可空字段不要额外加not null，否则矛盾：Go层能传nil，数据库却拒绝NULL；
• 字符串指针建议显式size，不然不同数据库方言默认类型可能不一致；
• 可空字段如果需要参与查询，别把索引建在容易产生大量NULL的列上，或者要考虑NULL与索引的兼容性；
• 更新操作里想置NULL，一定要配合Select或者用map，默认结构体更新不会把nil写进去。

一个常见组合：

Phone *string `gorm:"type:varchar(20);default:null;comment:'手机号'"`

6.3 复盘：哪些地方我改过、为什么改

最后想分享几个我改过字段类型的真实案例。

第一次，把订单表里所有数值字段全改成指针，包括金额、数量。结果代码写起来到处解引用，每次比较都要判nil，后来发现金额这类字段业务上根本不存在"未设置"，0就是0，全改回了值类型。教训是：不要为了"统一风格"而滥用指针，指针要跟着业务语义走。

第二次，用户表的性别字段。起初用int，0代表未知、1男、2女。后来前端统计报表要区分"用户没选性别"和"选了性别但计为0"（实际上不可能选0），总出歧义，最后改成*int，nil代表未选。这次经历让我明白：指针不是给数据库用的，是给产品语义用的。

第三次是软删除。早期自己写了一个*time.Time的deletedAt，后来GORM升级到v2，发现内置的gorm.Model已经带了DeletedAt，不用自己再造轮子。想表达可空语义时，第一反应应该看看框架有没有现成方案。

每次改字段类型，牵一发而动全身：JSON输出变了、前端判空逻辑要改、查询条件要同步、甚至历史数据要订正。所以这个决策最好放在项目建模阶段做，比上线后补救成本低得多。