Revel 不自动填充 c.Params.Form 是设计行为而非 Bug；它仅对 GET 请求的 query string 自动填充，POST/PUT 的表单数据需手动调用 ParseForm 或 ParseMultipartForm，或使用控制器参数绑定。
Revel 不会自动填充 c.Params.Form，这是设计行为不是 Bug
很多人在 POST 或 PUT 请求里用 FormData 发送数据，然后直接查 c.Params.Form，结果得到 nil 或空 map。这不是框架出错，而是 Revel 明确不自动解析 application/x-www-form-urlencoded 和 multipart/form-data 请求体到 c.Params.Form ——尤其对 PUT 请求，这个限制常被误判为 Bug。
根本原因在于：Revel 的 c.Params 是统一入口，但各子字段（Query、Form、Values）的填充依赖 HTTP 方法 + Content-Type 的显式匹配逻辑，而它默认只对 GET 查询参数做自动填充。
-
c.Params.Form仅在 GET 请求中由 query string 自动填充；POST/PUT 的表单数据不会“自动落进”这里 - 即使你发的是
application/x-www-form-urlencoded，c.Params.Form仍为空，必须手动触发解析 - 若用
multipart/form-data（比如带文件），更得先调用c.Request.ParseMultipartForm()，否则c.Request.MultipartForm也是 nil
用控制器方法参数绑定是最简单可靠的方案
Revel 支持基于字段名的自动绑定，只要前端 FormData 的 key 名和控制器方法参数名一致，就能直接拿到值，无需手动解析。
例如前端这样发：
立即学习“前端免费学习笔记（深入）”；
const fd = new FormData();
fd.append("id", "123");
fd.append("nickname", "alice");
fd.append("is_active", "true");
后端控制器可直接写：
func (c UserController) SaveUser(id string, nickname string, is_active bool) revel.Result {
// id="123", nickname="alice", is_active=true（字符串"true"被自动转为bool）
user := &models.User{ID: id, Nickname: nickname, IsActive: is_active}
return c.RenderJSON(user)
}
- 参数名必须严格匹配（大小写敏感），且只支持
string、int、bool等基础类型及其指针 - 缺失字段会取零值（
""、0、false），不会 panic，但需自行校验有效性 - 不支持嵌套结构体或 map 类型参数，如需复杂结构，改用 JSON 或手动解析
手动解析 FormData：ParseForm vs ParseMultipartForm
当字段名不确定、需读取原始多值（如 hobby[]=reading&hobby[]=swimming）、或要处理文件时，必须手动解析请求体。
关键区别：
- 发的是纯键值对（无文件），
Content-Type: application/x-www-form-urlencoded→ 调用c.Request.ParseForm() - 发的是带文件的
FormData（含<input type="file">），Content-Type: multipart/form-data→ 必须调用c.Request.ParseMultipartForm(32 （32MB 内存上限） - 二者都必须在首次访问
c.Request.PostForm或c.Request.MultipartForm前调用，否则返回空或 panic
解析后，用 c.Params.Get("key") 或 c.Params.All() 读取：
func (c UserController) UploadAvatar() revel.Result {
err := c.Request.ParseMultipartForm(32 << 20)
if err != nil {
return c.RenderError("parse failed: " + err.Error())
}
nickname := c.Params.Get("nickname") // 从 form 字段取
file, header, _ := c.Request.FormFile("avatar") // 从文件字段取
defer file.Close()
// ...保存文件逻辑
return c.RenderText("ok")
}
常见错误：Content-Type 不匹配导致解析失败
浏览器发 FormData 时，会自动设置正确的 Content-Type（含 boundary），但如果你用 axios 或 fetch 手动构造请求体又覆盖了 header，就容易出问题。
- 用
axios.post(url, fd)时，**不要**手动设Content-Type，让浏览器自动生成；否则 boundary 缺失，后端无法分块解析 - 用
fetch时同理：fetch(url, { method: 'POST', body: fd })即可，切勿加headers: {'Content-Type': '...'} - 若后端收到空表单，先看 Network 面板的 Request Headers —— 如果
Content-Type是application/json或没设，那根本就不是FormData请求
最稳妥的验证方式：在控制器开头加一行日志 revel.INFO.Printf("CT: %s, Body: %+v", c.Request.Header.Get("Content-Type"), c.Request.Body)，确认实际收到的格式。
真正容易被忽略的点是：Revel 对表单解析没有“兜底逻辑”，它不做隐式转换，也不报友好错误——你忘了调 ParseForm，它就安静地返回空值；你传了文件却只调 ParseForm，它就安静地忽略文件字段。这种静默失败比报错更难定位。
