Pop ORM 的 Validate 方法不自动检查数据库唯一性，仅做内存级校验；需手动添加 validate.Uniqueness 才触发 SQL 查询，且必须配合数据库唯一索引与事务内执行，并在 Create 后用 pop.IsUniqueError 捕获并处理冲突。
Pop ORM 的 Validate 方法不自动检查数据库唯一性
Buffalo 默认用 pop 作为 ORM，它的 Validate 方法只做内存级校验（如非空、长度），不会发起 SQL 查询检查字段是否已存在。你写 validate.Length("email", {Min: 1, Max: 255})，哪怕数据库里已有相同 email，Validate 仍会返回 nil 错误。
常见错误现象：用户注册时重复提交同一邮箱，Create 成功插入两条记录，没报错也没拦截。
- 必须手动加
validate.Uniqueness("email")才触发数据库查重 - 该验证依赖
pop.Connection已初始化且能连上 DB，否则 panic 或静默失败 -
validate.Uniqueness默认查整个表，若需限定范围（如“同 tenant 下 email 唯一”），得配合validate.Uniqueness("email", {Scope: "tenant_id"})
validate.Uniqueness 的实际行为与陷阱
它生成的 SQL 是 SELECT COUNT(*) FROM users WHERE email = ?，不是 INSERT ... ON CONFLICT。这意味着在高并发下仍可能产生竞态：两个请求同时通过 Validate，再同时 Create，最终 DB 层违反唯一索引约束。
所以不能只靠它防重——它只是前置提示，不是强一致性保障。
- 数据库表必须显式建唯一索引：
CREATE UNIQUE INDEX idx_users_email ON users(email)，否则validate.Uniqueness查不到，Create也可能成功插入重复 - 如果
Create因唯一索引失败抛出pop.Error，其Error() string里含 PostgreSQL 的unique_violation或 MySQL 的1062 Duplicate entry，需主动匹配错误码处理，不能只看err != nil - 别在事务外调用
validate.Uniqueness后再进事务——中间可能被其他请求插入，应把校验和创建放在同一事务中
如何在 action 层统一捕获并返回友好错误
Buffalo 的 c.Validate() 不会自动合并 validate.Uniqueness 的 DB 错误，它只跑内存规则。DB 层唯一冲突必须在 model.Create() 后单独判断。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
推荐写法：
func (a UsersResource) Create(c buffalo.Context) error {
u := &models.User{}
if err := c.Bind(u); err != nil {
return err
}
tx := a.DB()
// 先跑内存校验（含 validate.Uniqueness 的预查）
verrs := u.Validate(tx)
if verrs.HasAny() {
return c.Error(400, verrs)
}
// 再尝试创建，捕获唯一索引错误
if err := tx.Create(u); err != nil {
if pop.IsUniqueError(err) {
verrs.Add("email", "已被注册")
return c.Error(400, verrs)
}
return err
}
return c.Render(201, r.JSON(u))
}
-
pop.IsUniqueError(err)是pop提供的专用判断函数，比字符串匹配更可靠 - 不要把
verrs.Add()放在Validate()之前——它需要 DB 连接才能执行Uniqueness查询 - 如果模型有多个唯一字段（如
email和phone），IsUniqueError只能告诉你“有唯一冲突”，但不知道是哪个字段；需结合err.Error()解析具体列名
为什么不用数据库原生 ON CONFLICT？
pop 当前版本（v5.x）不支持 PostgreSQL 的 ON CONFLICT DO NOTHING/UPDATE 语法。它只提供基础 CRUD，所有冲突逻辑必须由上层代码兜底。
这意味着：即使你建了唯一索引，也得在 Go 层写重复判断 + 错误映射，没法靠一条 SQL 完成“存在则忽略/更新”。
- 若真需要 UPSERT 行为，得绕过
tx.Create()，改用tx.Raw(...).All()手写 SQL - 这种写法会丢失
pop的 model hook（如BeforeCreate），需手动补全 - Buffalo 项目越往后演进，越容易发现
pop的抽象层级太低——它不帮你屏蔽 SQL 差异，也不提供事务内重试机制
真正难处理的不是怎么写校验，而是当业务要求“邮箱唯一但允许空值”或“用户名唯一但大小写不敏感”时，validate.Uniqueness 默认行为完全不够用，必须退到 raw SQL 或自定义验证器。这些细节在原型阶段不暴露，上线后才集中爆发。
