<p>c.String() 传入动态状态码时必须确保变量为 int 类型且在 100–599 范围内，推荐使用 http.Status* 常量；不可混用 c.Status() 和 c.String()，因后者会覆盖前者；c.HTML() 不支持动态状态码参数，需用 if/switch 分支调用；中间件无法修改已写出的状态码，建议通过 c.Set() 预设并在中间件统一处理。</p>
c.String() 传入动态状态码的正确写法
直接把变量塞进 c.String() 第一个参数是安全的，Gin 不校验状态码合法性，但 HTTP 协议和客户端行为会出问题。比如传 -1 或 999，底层 net/http 会写入无效状态行，某些代理或浏览器可能截断响应甚至报错。
- 必须确保变量是
int类型且在标准范围内（100–599），推荐用http.Status*常量做兜底 - 别用字符串拼接再转 int，容易 panic；更别用 map 查表映射字符串到数字——既慢又易漏
- 常见误写：
c.String(statusCode, "ok")中statusCode来自用户输入或 DB 字段，没校验就直传
为什么不能用 c.Status() + c.String() 组合设状态码
c.Status() 只写响应头的状态码，不写 body；c.String() 会覆盖已写的状态码并重写整个响应。两者混用会导致状态码被 c.String() 的第一个参数强制覆盖，前面的 c.Status() 白调了。
- 错误示例：
c.Status(http.StatusNotFound); c.String(200, "fallback")→ 实际返回 200，不是 404 -
c.String()内部调用了c.writer.WriteHeader()，它一旦触发，后续再调c.Status()就无效 - 真正需要分离头/体时，应改用
c.Writer.WriteHeader()+c.Writer.WriteString()，但失去 Gin 的 Content-Type 自动设置
动态状态码配合模板渲染的坑
c.HTML() 不接受状态码变量作为参数，它的第一个参数必须是字面量 int —— 这是 Go 函数签名硬编码决定的，没法绕过。所以想根据业务逻辑返回不同状态码的 HTML 页面，不能靠“传参”，得靠提前判断分支。
- 不能写：
c.HTML(statusCode, "page.html", data)→ 编译失败 - 正确做法：用 if/switch 判断后，分别调
c.HTML(404, ...)或c.HTML(200, ...) - 如果分支多，建议封装成函数，例如
renderWithStatus(c, statusCode, templateName, data)，内部 switch 分发 - 注意：HTML 渲染默认设
Content-Type: text/html; charset=utf-8，状态码错配（如 404 返回 200）会让前端 SEO 和调试工具困惑
中间件里统一处理动态状态码的边界
中间件能拦截 c.Next() 后的响应，但无法修改已写出的状态码。也就是说，如果 handler 里已经调了 c.String(500, ...)，中间件里再调 c.Status(200) 是无效的。
- 真正可干预的时机，是在 handler 执行前预设状态码（比如鉴权失败提前设 401），或通过自定义 ResponseWriter 包装器劫持 WriteHeader 调用
- 更实用的做法：约定 handler 不直接写状态码，而是往
c.Set("status_code", 403)存，中间件最后统一读取并调c.Status() - 但要注意：若 handler 已调
c.JSON()或c.String()，WriteHeader 已触发，c.Set()就来不及了
