Revel中解析JSON请求体应直接用json.NewDecoder(c.Request.Body)并defer关闭Body，避免ioutil.ReadAll读空；异步操作须用channel同步确保c上下文有效；Content-Type必须显式设置为application/json，否则Body被误解析；i18n批量翻译需自行解析INI文件而非访问未导出变量。
Revel里直接用json.NewDecoder解析POST请求体
别碰ioutil.ReadAll，它会把c.Request.Body读空，后续Decode()就只能拿到空数据或报错。Revel的请求体是io.ReadCloser，正好匹配json.NewDecoder的输入要求，流式解码既安全又省内存。
常见错误现象：返回一串Base64字符串（如"WyJvbmUiLCJ0d28iLCJ0aHJlZSJd"），本质是原始字节被RenderJSON二次编码了——说明你没解码，只是把未处理的[]byte直接塞给了响应函数。
- 目标类型必须和JSON结构严格一致：发
["a","b"]就用[]string；发{"id":1,"name":"x"}就得定义对应struct或map[string]interface{} - 记得
defer c.Request.Body.Close()，不关可能影响HTTP/1.1连接复用 - 必须检查
err并返回400 Bad Request，生产环境不能忽略解析失败
Revel控制器里做异步调用，别用go裸奔
在func(c Ctrl) Action()里直接写go api.Call()，结果往往不是“快”，而是“丢数据”或“panic”。因为主线程返回响应后，goroutine可能还在跑，而Revel的c上下文对象已经失效，c.RenderJSON或c.Params访问会出问题。
正确做法是用带同步机制的封装，比如AsyncTask：开goroutine干活，用channel传结果，主线程select等回传或超时，再统一渲染。这样既释放了阻塞，又保住了请求生命周期内的数据安全。
- 第三方API、数据库慢查询、文件IO这类耗时操作，必须移出主goroutine
- 不要在异步goroutine里直接调用
c.Render*或修改c.ViewArgs - 超时控制要显式做，避免一个卡死拖垮整条请求链
前端发JSON，Content-Type和数据格式必须配对
curl测试时漏掉-H "Content-Type: application/json"，Revel默认当application/x-www-form-urlencoded处理，c.Params.Get("key")拿不到东西，c.Request.Body也读不出有效JSON——因为框架底层会尝试按表单格式解析，提前消费了Body流。
同样，如果前端用fetch但忘了设headers: {"Content-Type": "application/json"}，或者用JSON.stringify(obj)但没把结果传给body字段，后端收到的就是空或乱码。
- Revel不会自动根据内容猜类型，
Content-Type是唯一判断依据 - 发送数组
["x","y"]时，确保前端没多包一层{data: [...]}而服务端还按map[string]interface{}去接 - 用
curl -v或浏览器DevTools Network面板确认请求头和payload是否符合预期
批量返回翻译字符串？别碰Revel内部messages映射
Revel的i18n数据存在未导出的messages变量里，没法直接遍历。想从/messages/home.en一次性拉出所有key:value对给API用，得绕过框架，自己用robfig/config库重读INI文件。
路径拼接要小心：revel.AppPath + "/messages/" + module + "." + lang，注意斜杠和扩展名；INI解析后得到*config.Config，再用cfg.StringMap("")转成map[string]string。
- 别试图反射或改源码去导出内部变量，升级Revel版本后大概率崩
- 自定义加载函数要加错误处理，文件不存在或格式错误时返回空map+日志，别让整个API挂掉
- 如果模块多、语言多，建议加缓存层，避免每次请求都打开文件
实际项目里最常被忽略的，是Content-Type校验和Body流的不可重复读特性——这两点一旦出错，现象诡异，排查路径却很窄。宁可多加一行header检查，也不要靠“应该没问题”跳过。
