beego中parseform必须在controller方法内、响应写入前调用，仅对post/put/patch有效，且只解析一次；需注意csrf校验、字段类型安全及结构体绑定时机。
Beego 中 ParseForm 的正确调用时机
必须在 Controller 方法内、且在任何 this.Ctx.Output 写入响应前调用 this.ParseForm()，否则会返回空值或 panic。Beego 不会自动解析表单，它依赖显式调用，且只解析一次 —— 多次调用第二次起直接返回 nil。
常见错误现象：this.Input().Get("username") 能取到值，但 this.GetString("username") 返回空，说明没调用 ParseForm；或者调用后所有字段都是零值，大概率是已提前触发了输出（比如写了 this.Data["json"] = ...; this.ServeJSON()）。
- 仅对
POST、PUT、PATCH请求有效（GET用this.Input().Get()） - 默认只解析
application/x-www-form-urlencoded和multipart/form-data，不支持application/json提交的表单字段 - 如果表单含文件上传，必须确保 HTML 中
<form></form>设置了enctype="multipart/form-data"
GetString 和 GetInt 的类型安全陷阱
this.GetString("name") 返回 string 和 error，但错误只在字段不存在时触发；若字段存在但为空字符串，它仍返回 "" 和 nil —— 这容易掩盖业务校验逻辑。同理，this.GetInt("age") 对非数字字符串（如 "abc" 或空值）会返回 0 和具体错误，但若你忽略错误直接用返回值，就可能把非法输入当成了 0。
使用场景：适合快速获取简单字段，但生产环境务必检查错误，并额外判断空值：
name := this.GetString("name")
if name == "" {
this.Abort("400")
}
age, err := this.GetInt("age")
if err != nil || age 150 {
this.Abort("400")
}
结构体绑定：ParseForm vs ParseFormInto
this.ParseForm(&user) 是最常用方式，要求结构体字段有 form tag（如 Username string `form:"username"`），且字段必须为导出（首字母大写）。它底层调用的是 ParseForm，所以同样受调用时机限制。
this.ParseFormInto(&user) 是 Beego 2.0+ 新增方法，行为更接近标准库 url.Values.Decode，能更好处理嵌套字段和切片（例如 hobbies[]），但目前文档覆盖不足，实际兼容性不如 ParseForm 稳定。
- 字段名不匹配时，
ParseForm静默跳过，不会报错 - 布尔字段（
bool）只识别"on"、"1"、"true"（忽略大小写），其他值都转为false - 时间字段需手动解析，
ParseForm不支持time.Time自动转换
CSRF 与表单提交的隐性冲突
启用 CSRF 后（EnableCsrf = true），Beego 会在模板中通过 {{.xsrf_token}} 注入 token，并要求所有 POST/PUT/PATCH 请求携带 _xsrf 字段。如果前端表单漏传该字段，ParseForm 仍会成功执行，但请求会在中间件层被拦截并返回 403 —— 此时后端日志里看不到任何表单解析失败提示，容易误判为路由或参数问题。
验证方法：提交前检查表单 HTML 是否包含：
<input type="hidden" name="_xsrf" value="{{.xsrf_token}}">
或者用 JS 动态注入（注意模板渲染时机）；后端可通过 this.CruSession.Get("xsrfkey") 手动比对，但一般不建议绕过内置 CSRF 校验。
复杂点在于，AJAX 提交时需从响应头（X-Xsrftoken）或页面 meta 标签读取 token，并设为请求 header 或 form 字段 —— 这个环节最容易被忽略，导致本地调试通、线上 403。
