c.Status()仅设状态码不发响应，需搭配c.JSON()等；c.NoContent()专用于无体状态；自定义错误应封装SendError；中间件中设码需通过标记+ErrorHandler统一处理。
Context.Status() 直接设置状态码
Echo 框架里最常用、最直接的方式就是调用 c.Status()，它只改响应状态码，不写响应体、不结束请求。适合需要先计算逻辑再统一返回的场景。
常见错误是误以为 c.Status() 会自动发送响应——它不会。如果后面没跟 c.String()、c.JSON() 或 c.NoContent() 等，客户端可能收不到完整响应（尤其是 HTTP/2 下更易出问题）。
-
c.Status(http.StatusNotFound)设置 404，但响应体为空，需手动补内容或调用c.NoContent() - 搭配
c.JSON()时注意顺序：c.Status(http.StatusCreated).JSON(201, data)是链式调用，等价于先设码再发 JSON - 若已调用过
c.JSON()再调c.Status()，状态码不会生效（header 已写入）
用 c.NoContent() 发送无 body 的成功状态
当你要返回 204、201 等标准无响应体状态时，c.NoContent() 是语义最清晰的选择。它内部自动调用 Status() 并设置 Content-Length: 0，避免手动处理 header。
容易踩的坑是拿它返回带 body 的状态（比如 200 + JSON），这会导致冲突或静默失败。
-
c.NoContent(http.StatusNoContent)→ 204 -
c.NoContent(http.StatusCreated)→ 201，且确保响应体为空 - 不能和
c.JSON()混用；如果需要 201 + body，必须用c.Status(http.StatusCreated).JSON(...)
自定义 Status 响应（含 message 和 body）
真正需要“自定义 Status”的典型场景，其实是返回结构化错误（如 {"code": 4001, "message": "xxx"}）并配合非 2xx 状态码。Echo 不提供内置的“自定义 status 类”，得自己封装。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
关键点在于：状态码必须在写 body 前设置，否则会被忽略；同时要避免多次写 header。
- 推荐封装一个 helper 函数：
func SendError(c echo.Context, code int, msg string) error { return c.JSON(code, map[string]string{"error": msg}) } - 若需复用状态码逻辑，可提前定义常量：
const ErrInvalidParam = 4001，但注意 HTTP 状态码仍是http.StatusBadRequest（400），业务码放 body 里 - 别在中间件里反复调
c.Status()—— 一旦 response writer 已 flush，再设状态码无效
中间件中修改状态码的风险点
中间件里调 c.Status() 很危险，因为此时 handler 可能还没执行，真实状态码尚未确定。强行覆盖容易掩盖业务逻辑的真实意图。
更安全的做法是：中间件只做标记（比如往 c.Set("status_code", 429)），然后在全局 HTTPErrorHandler 中统一读取并设置。
- Echo 默认错误处理器会在 panic 或
return err时触发，此时你有机会检查c.Get("status_code")并覆盖状态码 - 不要依赖
defer在 handler 结尾设状态码——panic 会跳过 defer - 日志记录状态码时，务必用
c.Response().Status（实际写出的值），而不是某个变量，因为可能被多次修改
实际项目里，状态码不是孤立设置的，它和响应体、错误分类、中间件生命周期强耦合。最容易被忽略的是：你以为设了状态码就完事了，但 Echo 的 writer 机制决定了——时机不对，等于没设。
