为何Gin的*Context.Render方法要优先设置HTTP响应状态码？

为什么先调用c.Status(code)后设置Content-Type仍然生效 #

核心是Gin对标准库http.ResponseWriter做了封装缓存，c.Status(code)没有立刻触发响应头的发送：
Gin自定义了响应写入器实现，内部有status字段专门缓存待写入的HTTP状态码，调用c.Status(code)时仅会把状态码写入该缓存字段，不会调用标准库的WriteHeader方法把响应刷给客户端，此时响应头仍然处于可修改状态。
只有当触发以下任意一个操作时，Gin才会把缓存的状态码和所有已设置的响应头一起发送给客户端，之后修改普通响应头才会失效：

• 主动调用c.Writer.WriteHeaderNow()
• 第一次调用c.Writer.Write()写入响应体
  你看到的writeContentType逻辑是在响应头刷出前执行的，所以可以正常生效，和标准库的注释规则并不冲突。

Render方法优先设置状态码的设计逻辑 #

主要有三点设计考量：

1. 提前做协议合规分支判断
   HTTP协议规定部分状态码不允许携带响应体，比如204（无内容）、304（内容未修改）、所有1xx类状态码。先拿到状态码就能执行bodyAllowedForStatus的分支校验，不需要做多余的响应体序列化操作，也避免写出不符合协议规范的响应。
2. 保证业务状态码优先级
   优先把用户传入的状态码写入缓存，避免后续渲染器的逻辑意外覆盖状态码，符合用户调用JSON(code, obj)、String(code, format)这类方法时「指定的状态码必须生效」的预期。
3. 职责拆分更清晰
   不同的渲染器（JSON/HTML/XML/文件等）只需要关注响应体的序列化和自己需要设置的响应头即可，不需要关心状态码的处理逻辑，职责边界更清晰。

内容的提问来源于stack exchange，提问作者syang