revel 中 response.status 赋值后未生效是因为状态码仅在首次调用 c.renderjson()、c.rendertext() 或 c.result 时才真正写入响应；若此前已调用渲染方法，再改 status 会抛 illegalstateexception。
Revel 中 response.Status 赋值后为什么没生效？
直接写 c.Response.Status = 401 不会立即发给客户端，它只是设置响应状态码字段；真正触发 HTTP 状态行写入的是后续第一次调用 c.RenderJSON()、c.RenderText() 或 c.Result 赋值。如果在赋值前已调用过 c.RenderJSON()，再改 Status 就会抛 IllegalStateException: status already committed。
常见错误场景：
- 在中间件里设了
c.Response.Status = 403，但没中断链路，后续 Controller 又调了c.RenderJSON()→ 状态被覆盖为 200 - 用
c.RenderError("msg")后再手动改Status→ 已提交，改不动 - 忘记
return，导致状态设完继续执行后续渲染逻辑
正确做法是：状态设置和结果返回必须成对出现，且中间不能有其他输出操作。
如何封装统一的 Result 结构并控制状态码？
Revel 没有内置的全局响应体封装机制，必须靠自定义 Result 实现类 + 显式返回。不要依赖框架自动包装，否则状态码、Content-Type、Header 都不可控。
推荐结构（Go 语言）：
type JSONResult struct {
Data interface{}
Code int
Msg string
}
func (r JSONResult) Apply(c *revel.Controller) revel.Result {
c.Response.Status = r.Code
c.Response.ContentType = "application/json; charset=utf-8"
return revel.JSON(r.Data).Apply(c)
}
使用时：return JSONResult{Code: 400, Msg: "bad request", Data: nil}。
关键点：
- 必须实现
Apply(c *revel.Controller) revel.Result方法，这是 Revel 的约定接口 -
c.Response.Status必须在Apply内设置，不能提前设 - 不要在
Apply外部调用c.RenderJSON()，否则冲突 - 若需带 Header（如
X-Request-ID），也在Apply里用c.Response.Out.Header().Set()
CompressFilter 和自定义状态码冲突怎么办？
Revel 的 CompressFilter 默认跳过状态码为 204、304 的响应，但如果你封装了 204 No Content 类型的 JSONResult，压缩会被静默跳过——body 是空的，但你可能期望它仍走 gzip 流程（比如返回 {} 而非纯空）。
解决路径：
- 确认
conf/app.conf中同时开启：results.compressed = true和results.compression.filter = true - 避免用
204表达“空 JSON”，改用200+{"code":204,"msg":"no content"} - 若必须用
204，需绕过CompressFilter：在 Filter 链中把它移到自定义 Result 之后，或重写CompressFilter的shouldCompress判断逻辑 - 检查响应 MIME 类型是否在白名单内（默认只压
text/、application/json、application/javascript）
为什么 Nginx 反向代理后状态码变成 502？
不是 Revel 的问题，而是 Nginx 在 upstream 响应异常时兜底返回 502。典型诱因：
- Revel 进程崩溃或未启动，Nginx 连不上
127.0.0.1:8089 - Revel 返回了非法状态码（如负数、大于 999），Tomcat 兼容层不处理，但 Revel 的 net/http 底层会 panic，导致连接中断
- 客户端请求头含
Connection: close，而 Revel 未正确处理连接关闭信号，Nginx 认为 upstream 异常断连 - proxy_pass 地址与
revel run -addr绑定地址不一致（如 Nginx 代理到localhost:8089，但 Revel 绑的是127.0.0.1:8089，某些系统 DNS 解析差异会导致失败）
验证方式：curl 直连 Revel 端口（curl -v http://127.0.0.1:8089/api/test），看原始响应状态是否正常。不经过 Nginx 能跑通，基本就是代理配置或超时参数问题。
状态码不是字符串标签，它是响应生命周期里的一个不可逆标记点；所有封装都得围着“何时设、谁来设、设完能否改”这三件事转。最容易被忽略的是：Revel 的 Result 是惰性执行的，return 语句本身不发数据，真正写入网络是在 Controller 方法退出后的框架回调阶段——这个延迟窗口，就是状态码被覆盖或 Header 被忽略的高发区。
