c.Bind仅处理application/x-www-form-urlencoded和multipart/form-data两种Content-Type，遇其他类型（如application/json）静默失败，字段保持零值。
c.Bind 只处理两种 Content-Type，其他会静默失败
Buffalo 的 c.Bind 不是万能解析器，它只响应 application/x-www-form-urlencoded 和 multipart/form-data 这两种请求头。如果前端用 fetch 发的是 application/json，c.Bind(&u) 会一声不响地跳过，结构体字段全保持零值——连错误都不报。
常见错误现象：u.Name 始终为空字符串，但 c.Request().FormValue("name") 能取到值，说明数据其实到了服务端，只是没被绑定。
- 确保 HTML 表单没写错
enctype：上传文件时必须显式设为enctype="multipart/form-data"；纯文本字段默认就是application/x-www-form-urlencoded，不用写 - 前端 JS 提交时，别手动设
Content-Type: application/json，否则c.Bind直接放弃 - 用
c.Request().Header.Get("Content-Type")打印确认实际类型，比猜靠谱
结构体字段必须大写 + form 标签 + name 完全匹配
Go 的反射要求导出字段（首字母大写），而 Buffalo 的绑定还额外依赖 form 标签。漏掉任意一环，绑定就失效。
例如这个结构体：
立即学习“前端免费学习笔记（深入）”；
type User struct {
Name string `form:"name"`
Email string `form:"email"`
}
对应 HTML 必须是：
<input name="name" value="alice"> <input name="email" value="a@example.com">
-
name属性值和form:"xxx"中的xxx必须完全一致，区分大小写 - 字段名本身（如
Name）可以和表单 name 不同，但标签值不能错 - 如果用了嵌套结构体或指针字段，
c.Bind不递归解析，只处理一级字段
查询参数和表单数据要分开解，不能混在一个结构体里
Buffalo 没有自动合并 URL 查询参数（?page=2&q=go）和 POST body 的机制。c.Bind 只看请求体，gorilla/schema（Buffalo 默认集成）只看 URL.Query()，两者互不识别对方的标签。
典型场景：搜索页带分页和关键词输入，需同时读 query 和 form。
- 定义两个结构体：一个带
form:"xxx"，供c.Bind用；另一个带schema:"xxx"，供schema.NewDecoder().Decode()用 - 字段名建议统一用小写（如
Q string `schema:"q"`），避免大小写混淆 - 别给同一字段同时加
form和schema标签——c.Bind忽略后者，schema.Decode忽略前者，结果就是一半字段永远空
验证失败后重渲染表单，原始输入不会自动保留
Buffalo 的 c.Render(200, r.HTML("form.html")) 是全新上下文，不携带任何 POST 数据。用户填了一半点提交，校验失败后看到的是一张空表单，体验极差。
正确做法是手动把已绑定的结构体挂进 context：
if err := c.Bind(&u); err != nil {
return c.Error(400, err)
}
if !valid(u) {
c.Set("user", &u) // 关键：把填充好的结构体塞进去
return c.Render(422, r.HTML("form.html"))
}
模板里用 {{.user.Name}} 回显，而不是 {{request.FormValue "name"}}。
- 忘记
c.Set()是最常被忽略的环节，没有 warning，也没有 error，只有用户反复填写的挫败感 -
.FormErrors.name这类 Buffalo 自动注入的变量，只在c.Render且校验失败时存在，别指望在其他 context 里拿到 - 如果结构体字段是指针类型（如
*string），c.Set后模板里要判空再取值，否则可能 panic
