c.Status(404)有时无效是因为它仅设置状态码而不终止执行，若后续调用c.JSON()等会覆盖状态码；需显式return或链式调用确保生效。
为什么 c.Status(404) 有时没效果
因为 c.Status() 只设置状态码，不终止后续执行。如果后面还调了 c.JSON() 或 c.SendString()，它们会写响应体，但状态码**不会被覆盖**；可一旦再调一次 c.Status(200)，前面的 404 就真被替换了。
常见错误是写成这样：
if user == nil {
c.Status(404).SendString("not found")
}
c.JSON(200, user) // 这行仍会执行，状态码变回 200
必须加 return 或用链式调用一次性完成：
- 显式
return c.Status(404).SendString("not found") - 或直接
return c.JSON(404, map[string]string{"error": "user not found"})——c.JSON()内部会自动设状态码 - 调试时可用
fmt.Println(c.Response().StatusCode())确认最终值
c.SendStatus() 和 c.Status() 的区别
c.SendStatus() 是快捷写法：只写状态码 + 默认文本（如 404 → "Not Found"），不设 Content-Type，也不写响应体；c.Status() 是纯状态码设置，必须搭配 c.SendString()、c.JSON() 等才能发出完整响应。
二者都不自动终止 handler，都需手动 return。选哪个取决于你是否需要自定义响应内容：
- 只需返回空响应和标准提示？用
c.SendStatus(404) - 要返回 JSON 或 HTML？用
c.Status(404).JSON(...)或c.Status(404).SendString(...) - 别混用：
c.Status(404); c.SendStatus(200)最终是 200
中间件里怎么提前返回 401 或 403
中间件不靠 return 终止流程，而靠是否调用 next(c)。想拒绝请求，就别调它，并直接写响应：
app.Use(func(c *fiber.Ctx) error {
token := c.Get("Authorization")
if token == "" {
c.Status(401).SendString("missing token")
return nil // 注意：这里 return nil 表示中间件结束，不往下走
}
return c.Next() // 允许进入后续 handler
})
关键点：
- 必须调
c.Status()+ 响应方法，否则客户端收不到状态码 - 返回
nil是合法的，Fiber 视为“处理完成”，不会报错 - 返回
err（非 nil）会被全局ErrorHandler捕获，可能转成 500
自定义错误处理器中状态码被忽略怎么办
在 ErrorHandler 函数里，c.Status() 必须在 c.SendString() 或 c.JSON() 之前调用，且不能被后续逻辑覆盖。更稳妥的做法是手动检查错误类型：
ErrorHandler: func(c *fiber.Ctx, err error) error {
var e *fiber.Error
if errors.As(err, &e) {
c.Status(e.Code)
} else {
c.Status(500)
}
return c.SendString("Oops")
}
注意：
-
fiber.Error是 Fiber 自己封装的错误类型，含Code字段；普通errors.New()不带状态码 - 别在
ErrorHandler里调c.Next()，它不是中间件 - 若用了
middleware.Recover()，panic 会被转成*fiber.Error，此时e.Code默认是 500，可按需重写
状态码真正生效的前提，是响应还没被写出。Fiber 的响应写入是惰性的，直到 handler 返回或显式调用写方法才触发。任何对 c.Status() 的修改，只要发生在写响应前，都有效；但一旦 c.Send() 类方法执行，再改状态码就晚了。
