c.Status(404).SendString("not found")有时不生效，是因为Fiber中c.Status()仅设置状态码但不立即写入响应，若后续调用c.JSON()等方法或中间件提前写入响应（如c.SendStatus(200)），则状态码会被覆盖；正确做法是确保c.Status()为首个响应操作并显式return，或统一用c.Status(404).JSON()。
为什么直接写 c.Status(404).SendString("not found") 有时不生效
因为 c.Status() 只是设置状态码，但 Fiber 的响应写入是惰性的——它会在你调用 SendString、JSON 等方法时才真正触发 HTTP 写入。问题出在中间件或 panic 恢复逻辑里：如果某个中间件（比如日志中间件）提前调用了 c.SendStatus(200) 或 c.JSON(200, ...)，后续再调 c.Status(404) 就完全无效——ResponseWriter 头已发出，状态码锁死为第一次写的值。
常见错误现象：
- 路由里写了
c.Status(404).SendString("x")，但返回却是 200 - 使用了
app.Use(recover.New())，结果所有 500 都变成 200 + 空体 -
defer里调c.Status()，但 body 已经被前面的c.JSON()写过了
实操建议：
- 确保
c.Status()是响应链中第一个写操作；检查所有中间件是否偷偷调用了任何Send*方法 - 避免在
defer中设状态码，除非你能 100% 确保没写过 body（比如只在 error 分支里用） - 测试时用
httptest.NewRecorder()检查recorder.Code，别只看响应体内容
c.Status() 和 c.SendStatus() 的关键区别
c.Status() 不发送响应，只记下状态码供后续写操作使用；c.SendStatus() 立即写入空响应体并带上该状态码。两者语义完全不同，混用会出问题。
立即学习“go语言免费学习笔记（深入）”；
使用场景：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 想返回带 JSON 的 400 错误？用
c.Status(400).JSON(map[string]string{"error": "bad request"}) - 只想发个纯状态码（比如重定向后不需要 body）？用
c.SendStatus(302) - 要返回 HTML 错误页？用
c.Status(500).SendFile("templates/500.html")
参数差异：
-
c.Status(code int)返回的是*Ctx，支持链式调用，但不触发写入 -
c.SendStatus(code int)是终结方法，无返回值，且会立即提交响应头+空体 - 若你在
c.Status(404)后忘了接.JSON()或.SendString()，客户端将收不到任何 body（curl 显示 empty response）
Fiber 中如何统一处理业务错误并透传 HTTP 状态码
别在每个 handler 里手动判断 if err != nil { c.Status(...).JSON(...) }——状态码散落、易漏、难维护。Fiber 没内置 HTTPError 接口，但你可以自己建一套轻量约定。
实操建议：
- 定义接口：
type StatusError interface { error; StatusCode() int } - 业务错误实现它，例如：
type UserNotFound struct{}+func (e UserNotFound) StatusCode() int { return http.StatusNotFound } - 在顶层中间件里统一拦截：
app.Use(func(c *fiber.Ctx) error { if err := c.Next(); err != nil { if se, ok := err.(StatusError); ok { return c.Status(se.StatusCode()).JSON(fiber.Map{"error": err.Error()}) } return c.Status(http.StatusInternalServerError).JSON(fiber.Map{"error": "internal error"}) } return nil }) - 注意：Fiber 的
c.Next()返回error，所以 handler 必须以return err结尾才能被中间件捕获
WebSocket 连接关闭时怎么正确传自定义 code 和 reason
Fiber 的 websocket.Conn 不走 HTTP 响应流程，c.Status() 完全无效。WebSocket 关闭帧的 code 和 reason 必须通过 conn.CloseWithCode() 或 conn.Close() 的第二个参数传入。
常见错误现象：
- 前端
event.code总是 1006（abnormal closure），event.reason为空 - 后端调了
c.Close()却没传参数，或传了非法 code（必须是 1000–4999，且不能是 1004/1005/1006 等保留值）
实操建议：
- 用
c.CloseWithCode(4001, "room not found")—— code 必须是int，reason 是string - code 推荐用标准值：
4000（client error）、4001（custom app error）、4999（max allowed） - 前端监听：
socket.onclose = (e) => { console.log(e.code, e.reason) }，注意不是e.detail或e.data - 别在 goroutine 里调
c.Close()后还继续读写 conn —— 连接已关，会 panic
