gorm字段级加密需严格使用指针接收者、*gorm.db参数、error返回值的beforecreate/beforeupdate钩子，并用tx.statement.setcolumn写入密文；避免afterfind解密导致数据污染，密钥应由模型实例持有而非硬编码。
直接在 GORM 模型上加 BeforeCreate 和 BeforeUpdate 钩子就能实现字段级加密，但必须严格匹配签名、用 tx.Statement.SetColumn 写入密文，否则加密逻辑会被绕过或覆盖。
钩子函数签名不匹配导致加密失效
常见错误是定义了 func (u Model) BeforeCreate(tx *gorm.DB) error（值接收者）或返回类型不是 error，GORM 就完全不调用该方法。它只认 (*YourModel) BeforeCreate(tx *gorm.DB) error 这一种签名。
- 必须用指针接收者：
(*User)，不能是User -
tx参数类型必须是*gorm.DB，不是gorm.Session或其他包装类型 - 返回值只能是
error，不能是bool或多返回值 - 方法名大小写和拼写必须完全一致，GORM 不做容错修正
加密后写入方式错误导致明文被覆盖
很多人在钩子里直接改结构体字段，比如 u.Email = encrypted，结果 GORM 后续仍会把原始字段值（或零值）映射进 SQL，加密白做了。
- 正确做法是调用
tx.Statement.SetColumn("email", encryptedValue) - 它绕过结构体反射映射，直接将值注入 SQL 参数列表
- 对
sql.NullString或*string类型，需先判空：if u.Email.Valid { ... }，否则可能 panic - 避免在钩子里调用
tx.Save()或任何会触发新查询的操作，会引发递归或死锁
数据库字段长度不足引发 data too long 错误
AES-256-CBC + base64 编码后，100 字节原文会膨胀到约 136 字节；若还带 IV、salt 或额外元数据，实际需要更多空间。VARCHAR(255) 经常不够用。
- 敏感字段如 email、phone、id_card 建议设为
VARCHAR(1024) - 不要依赖
TEXT类型——某些 ORM 或迁移工具对 TEXT 的索引、排序、WHERE 条件支持不一致 - 如果字段原为
INT或UUID，加密后必须改为字符串类型，否则插入失败 - GORM 不会自动修改数据库 schema，字段扩容需手动执行
ALTER TABLE
解密不该放在 AfterFind 钩子里
AfterFind 在每次 SELECT 后无差别触发，且它修改的是结构体字段本身。一旦解密赋值，后续 Save() 可能误把明文当新值写回库，造成数据污染。
- 推荐方案：封装访问器方法，例如
func (u *User) GetEmail() (string, error)，内部按需解密并缓存 - 更底层的方案：实现
driver.Valuer和sql.Scanner接口，让 GORM 在序列化/反序列化时自动处理 - 若必须用钩子，可通过
tx.Statement.Context传入开关，例如context.WithValue(ctx, decryptKey, true)，再在AfterFind中判断，但增加调用链复杂度 - 永远不要在钩子里硬编码密钥，应从
tx.Statement.Context或初始化时注入的加密器实例获取
最易被忽略的一点：加密密钥的生命周期管理。钩子函数本身没有“初始化”阶段，密钥若靠 os.Getenv 每次读取，既慢又无法热更新；若存在全局变量里，又难做租户隔离。真正健壮的方案，是让模型实例持有加密器（如 user.Encryptor = aescbc.New(key)），由上层业务控制创建和销毁时机。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
