Revel中需在调用Render类方法前显式设置c.Response.Status，否则无效；RenderError默认500、RenderJSON默认200，业务错误须手动设400/403等状态码，重定向应直接传状态码参数而非修改Status。
Revel 中直接修改 c.Response.Status 就生效
Revel 没有类似 return c.RenderJSON(data).Status(400) 这样的链式调用，状态码必须在返回结果前显式赋值。只要在调用 c.Render()、c.RenderJSON() 或其他结果函数之前设置 c.Response.Status，后续响应就会使用该值。它不依赖中间件或过滤器介入，也不受 results.compressed 等配置影响。
状态码必须早于任何结果函数调用
常见错误是先调用 c.RenderJSON(data)，再试图改 Status——此时响应头已写入缓冲区，再改无效，甚至可能触发 panic（尤其在调试模式下）。正确顺序只能是：
- 解析请求、校验逻辑
- 出错时立即设
c.Response.Status = http.StatusBadRequest - 然后调用
c.RenderError(...)或c.RenderJSON(...)
例如处理 JSON 解析失败时：
decoder := json.NewDecoder(c.Request.Body)
err := decoder.Decode(&data)
if err != nil {
c.Response.Status = http.StatusBadRequest // 必须放在这里
return c.RenderError("Invalid JSON: " + err.Error())
}
注意 RenderError 和 RenderJSON 的默认状态码差异
不同结果类型自带默认状态码：c.RenderError(...) 默认是 500，c.RenderJSON(...) 默认是 200，c.Redirect(...) 默认是 302。如果你没手动覆盖，就按这个走。但别依赖“默认”，尤其是业务错误场景——比如参数校验失败应为 400，权限不足应为 403，这些都得自己写。
容易被忽略的一点是：Revel 的 RenderError 不会自动记录日志或上报监控，如果要用它返回客户端错误，建议额外加一行 revel.WARN.Printf(...)，否则线上排查时可能找不到调用痕迹。
重定向时不要手动设 Status
c.Redirect(...) 内部已固定使用 302（或你传的其他重定向码如 301、307），此时再写 c.Response.Status = 400 不仅无效，还可能干扰 Location 头生成。Revel 会忽略你的赋值，按重定向逻辑走。需要自定义重定向状态码，直接把数字传给 Redirect 即可：
return c.Redirect("/login", http.StatusFound) // 显式指定，而非设 Status 后再 Redirect
真正复杂的是带条件的状态码决策——比如同一个接口，成功时 200，无数据时 204，校验失败时 400，服务不可用时 503。这种分支里每条路径都得独立确认 Status 赋值，漏掉任意一条，就可能让前端收到意外的 200 响应体为空，或者 500 却没日志。
