GORM 不提供字段级业务校验，必须在入库前由应用层完成预校验；struct tag 仅影响建表和 SQL 生成，不参与运行时校验；推荐用 go-playground/validator v10 在 service 层统一校验，复杂规则须抽离为独立函数，数据库约束仅作兜底。
GORM 本身不提供字段级业务校验能力，所有 validation 必须在入库前由应用层完成——依赖 Save 或 Create 的返回值判断失败，等于把数据一致性交给了数据库约束，这是生产事故的常见起点。
为什么不能只靠 GORM 的 struct tag 校验
GORM 的 gorm:"not null"、gorm:"size:255" 等标签只影响建表和 SQL 生成，不参与运行时校验。哪怕你写了 gorm:"unique"，插入重复值时也只会收到一个 ErrDuplicatedKey 错误，无法提前告知用户“邮箱已被注册”。
- struct tag 不触发任何 Go 层面的校验逻辑，连空字符串、零值都放行
- 数据库唯一约束报错信息不可读（如 MySQL 的
ERROR 1062 (23000): Duplicate entry 'xxx' for key 'users.email'） - 前端无法区分是格式错误、长度超限，还是业务冲突，只能统一提示“提交失败”
推荐用 go-playground/validator v10 做结构体预校验
它与 GORM 模型天然兼容，支持嵌套、自定义规则、翻译提示，且性能开销极低（微秒级）。关键是要在调用 db.Create() 前完成校验，而非事后补救。
- 安装：
go get github.com/go-playground/validator/v10 - 在模型中添加校验 tag，例如：
type User struct { Email string `validate:"required,email,max=254"` Password string `validate:"required,min=8"` } - 校验入口统一放在 service 层或 handler 入口：
if err := validate.Struct(user); err != nil { return err } // 再 db.Create(&user) - 避免在 model 层做校验逻辑（违反单一职责），也别在 DAO 层加 validator 实例（破坏数据访问层纯粹性）
复杂业务规则必须抽离为独立校验函数
validator 只解决“格式+长度+非空”等通用问题；像“密码不能与用户名相同”“新邮箱不能等于旧邮箱”“VIP 用户可跳过实名认证”这类规则，必须写成显式函数，并在事务外执行。
- 不要试图用 validator 的
functag 注入业务逻辑，会导致测试困难、耦合度高 - 把校验函数命名为
ValidateUserForCreation而不是CheckUser，语义清晰且便于单元测试 - 若校验需查库（如检查手机号是否已存在），务必使用
db.WithContext(ctx).First()并设置超时，防止阻塞主流程 - 错误返回统一用自定义 error 类型（如
ErrPhoneAlreadyExists），方便中间件统一映射 HTTP 状态码和错误文案
数据库约束仍是最后一道防线，但不能替代应用层校验
MySQL 的 UNIQUE、CHECK（8.0.16+）、PostgreSQL 的 EXCLUDE 约束，应该作为兜底，而非主力校验手段。它们的价值在于防止并发写入导致的数据不一致，而不是用户体验。
- 建表时仍要加
unique_index和not null，但别指望靠它们做用户反馈 - 捕获
sql.ErrNoRows和gorm.ErrRecordNotFound是安全的；捕获mysql.MySQLError或pgconn.PgError则需按错误码精细解析（如 MySQL 1062、PostgreSQL 23505） - 不要在
defer里统一 recover 数据库错误——GORM 的错误是明确的 error 接口，应直接判断并处理
真正容易被忽略的是：校验顺序。比如先验格式再验唯一性，否则可能因格式错误提前退出，导致唯一性检查根本没执行；而并发场景下，即使格式和唯一性都过了，INSERT 仍可能失败——所以最终状态必须以数据库写入结果为准，校验只是降低失败率的前置过滤器。
