GORM将空字符串视为零值而跳过写入，导致数据库填充默认值；解决方法是改用指针类型（如*string）或添加gorm:"create;update"标签强制写入。
空字符串写入时触发数据库默认值（如 current_timestamp 或 uuid_generate_v4()），本质是 GORM 没有区分“零值”和“显式未设置”，导致字段被当作 nil/zero 处理，从而让数据库填充默认值——这不是 bug，是设计行为，但必须主动干预。
为什么空字符串会被当成未设置？
GORM 对结构体字段的零值（""、0、false、nil）默认跳过写入，除非显式标记为非零或使用指针。字符串类型字段若声明为 string，其零值就是 ""，GORM 会认为“用户没填”，于是不包含该字段进 INSERT 语句，数据库就回退到 DEFAULT 行为。
- 常见现象：
email string字段设了DEFAULT 'unknown@example.com'，但插入User{Name: "Alice", Email: ""}后查库发现 email 是unknown@example.com，而非预期的空字符串 - 根本原因：GORM 的零值忽略策略（
omitempty类似逻辑）作用于所有基础类型，且不可全局关闭 - 影响范围：不仅限于
string，int、bool同样适用；但*string、*int等指针类型可明确表达“未设置” vs “设为空”
用指针类型显式控制字段写入
把可能需要写入空字符串的字段改为指针类型，是最直接、最可控的解法。GORM 只在指针非 nil 时才写入字段值，nil 才触发数据库默认值。
- 定义模型时：把
Email string改成Email *string - 赋值时：想写空字符串就分配内存：
email := ""；user.Email = &email；想跳过就留user.Email = nil - 注意：JSON 序列化时需加
omitempty标签避免输出"email":null，例如：Email *string `json:"email,omitempty"` - 缺点：业务层需多一层解引用（
*user.Email），且迁移旧模型需改结构体和所有调用点
用 GORM 标签强制写入零值
对非指针字段，可用 gorm:"default:..." 配合 gorm:"not null" + 显式赋值，但更关键的是启用 create 或 update 专用标签来覆盖零值跳过逻辑：
- 添加
gorm:"default:'';not null"只能确保数据库层面允许空字符串，不能阻止 GORM 跳过写入 - 真正起效的是
gorm:"create;update"—— 它告诉 GORM：无论值是否为零，CREATE 和 UPDATE 时都必须包含该字段 - 示例：
Email string `gorm:"default:'';not null;create;update"`，此时User{Email: ""}会生成INSERT ... email = '' - 风险：若字段有数据库级
NOT NULL但无DEFAULT，而代码中又传了零值，会直接报错，需前后端约定好空字符串的语义
批量插入时的空字符串陷阱
db.Create(&users) 批量插入时，GORM 仍按单条逻辑处理每个字段。但若混用指针与非指针字段，或部分结构体字段未初始化，容易出现部分记录走默认值、部分写入空字符串的不一致。
- 统一策略：整个模型要么全用指针字段（推荐），要么全用带
create;update标签的非指针字段 - 避免混合：比如
Name string加了create;update，但Email *string没赋值为nil，会导致 Name 写""，Email 却触发数据库默认值 - 调试技巧：开启 GORM 日志（
logger.Default.LogMode(logger.Info)），观察实际生成的 SQL 是否含目标字段及值
最易被忽略的一点：GORM 的零值行为在 Create 和 Save 中一致，但在 Update 时若用 db.Model(&u).Updates(map[string]interface{}{"email": ""})，空字符串会被正常写入——因为 map 方式绕过了结构体零值判断。这意味着读-改-写流程中，如果先 Find 出结构体再改字段，零值陷阱依然存在；但直接用 map 更新，反而更安全。要不要切到 map 模式，得看你的更新逻辑是否依赖结构体字段的完整性。
