buffalo 中使用 c.validate() 进行参数校验，需在请求结构体中实现 validate() *validate.errors 方法，调用 errors.add() 收集字段错误；校验失败自动返回 422 状态码及结构化 json 错误（如 {"name": ["不能为空"]}），前端据此解析；校验逻辑应置于 actions/ 或独立 requests/ 目录，避免污染 model 层。
Buffalo 里用 Validate 方法做参数校验
Buffalo 自带的校验能力基于 github.com/gobuffalo/validate，不是靠中间件或手动 if 判断，而是把校验逻辑绑定在 struct 上，再调用 c.Validate() 触发。它不依赖反射扫描字段，而是显式调用 Validate 方法，所以行为可预测、调试方便。
常见错误是直接在 handler 里写 if req.Name == "" —— 这样既难复用，又绕过了 Buffalo 的错误收集机制，导致 c.Error() 不生效、前端拿不到结构化错误信息。
- 定义请求结构体时嵌入
validate.Validator接口 - 实现
Validate方法，调用errors.Add()收集问题 - 在 handler 中用
c.Bind()解析请求体后，立刻调用c.Validate() - 校验失败会自动返回
422 Unprocessable Entity和 JSON 错误详情（含字段名和消息）
type UserCreateRequest struct {
Name string `json:"name"`
Email string `json:"email"`
}
func (u *UserCreateRequest) Validate() *validate.Errors {
errors := validate.NewErrors()
if u.Name == "" {
errors.Add("name", "不能为空")
}
if !strings.Contains(u.Email, "@") {
errors.Add("email", "邮箱格式不正确")
}
return errors
}
func UsersCreate(c buffalo.Context) error {
var req UserCreateRequest
if err := c.Bind(&req); err != nil {
return err
}
if errors := c.Validate(&req); errors != nil {
return errors
}
// ... 创建用户逻辑
return c.Render(201, r.JSON(map[string]string{"status": "ok"}))
}
校验规则写在哪？别混进 model 层
Buffalo 的 models/ 目录默认放数据库实体，而请求参数校验应放在 actions/ 或单独的 requests/ 目录下。把校验逻辑塞进 User model 会导致两个问题：一是 model 被迫承担非持久化职责，二是 POST /users 和 PUT /users/:id 的校验规则往往不同（比如 ID 是否允许传、密码是否必填），共用一个 struct 容易冲突。
推荐做法是每个 endpoint 对应一个 request struct，哪怕字段名一样也单独定义。这样改一个接口的校验不会影响其他接口，测试也容易 mock。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 不要复用
models.User做绑定目标 - 避免在
Validate()里查数据库（如“邮箱是否已存在”）——那是业务逻辑，应放在 handler 后半段，失败时手动调用c.Error() - 如果多个 endpoint 共享部分字段校验，可提取为辅助函数，但不要强行抽象成通用 validator struct
c.Validate() 返回的错误怎么被前端拿到
Buffalo 默认把 *validate.Errors 渲染成 JSON，格式固定：{"name": ["不能为空"], "email": ["邮箱格式不正确"]}。状态码是 422，不是 400 —— 这点要注意，前端拦截错误时得匹配对状态码，否则可能当成网络错误处理。
如果你用的是 HTML 模板（比如 r.HTML("new.html")），c.Validate() 失败时会自动把 errors 注入 context，模板里可直接用 取单个字段错误，或遍历全部。
- API 场景下，前端 fetch 的
response.json()就是那个键值对对象 - 不要在 handler 里 catch
*validate.Errors后再包装成自定义结构 —— 会丢失 Buffalo 的自动渲染逻辑 - 如果需要添加额外上下文（如 trace id），应在 middleware 中设置，而不是篡改 validate 错误结构
为什么不用第三方校验库（比如 go-playground/validator）
Buffalo 原生集成的是 gobuffalo/validate，它轻量、无 tag 侵入、错误类型明确。而 go-playground/validator 需要大量 struct tag（validate:"required,email"），在 Buffalo 项目里强行接入会带来三个实际麻烦：
- tag 冗余：同一个字段在 API 请求、数据库模型、序列化输出中可能有不同校验需求，全塞一个 tag 无法区分场景
- 错误信息不统一：第三方库默认英文，要国际化得重写全部 message，而
gobuffalo/validate的errors.Add()直接写中文更自然 - 与 Buffalo 的
c.Error()流程不兼容：它返回的是error类型，不是*validate.Errors，无法触发自动 422 响应
真正卡住人的地方，往往不是“怎么加校验”，而是“校验失败后错误怎么流到前端、怎么保持可读性、怎么不让 model 层变重”。Buffalo 的方案看似简单，但把这几件事串起来了 —— 关键是别跳过 c.Validate() 这一步，也别把它当成可选动作。
