c.Abort("404")返回200是因为该方法仅中断执行流并跳转至错误处理逻辑，不自动设置HTTP状态码；必须在Error404方法或ErrorHandler函数中显式调用WriteHeader(404)才能生效。
Beego 默认的 404、500 等错误页会暴露框架版本，且无法控制 HTTP 状态码——直接调用 c.Abort("404") 返回的是 200，必须显式设置状态码才能生效。
为什么 c.Abort("404") 返回的是 200？
Beego 的 Abort 方法只负责跳转到对应错误控制器或回调函数，**不自动设置 HTTP 状态码**。它内部只是中断当前执行流，并触发错误处理逻辑，响应头仍保持默认的 200 OK。这是最容易被忽略的坑。
常见错误现象：前端看到“页面未找到”文字，但浏览器开发者工具 Network 面板里状态码是 200，SEO 和 API 客户端会误判。
- 必须在错误控制器中手动调用
c.Ctx.ResponseWriter.WriteHeader(404) - 不能依赖
c.Abort("404")自动带出正确状态码 - 若使用函数式错误处理器（
beego.ErrorHandler），也要在函数内第一行写w.WriteHeader(404)
Controller 方式自定义 Error404 页面（推荐）
从 Beego 1.4.3 起支持 Controller 写法，能复用模板渲染、c.Data、中间件等能力，比纯函数方式更可控。
立即学习“go语言免费学习笔记（深入）”；
实操要点：
- 在
main.go中注册：beego.ErrorController(&controllers.ErrController{}) - 控制器方法名必须是
Error404、Error500、ErrorDb这类格式，大小写敏感 - 方法体内第一行必须设状态码：
c.Ctx.ResponseWriter.WriteHeader(404) - 后续再设置模板：
c.TplName = "404.html"，否则可能返回空响应
示例片段：
func (c *ErrController) Error404() {
c.Ctx.ResponseWriter.WriteHeader(404)
c.Data["Message"] = "你访问的页面消失了"
c.TplName = "404.html"
}
函数式 beego.ErrorHandler 的注意事项
适合轻量级错误页或需要完全绕过 Beego 模板系统的场景，但容易漏掉关键步骤。
典型问题：
- 忘记调用
w.WriteHeader(statusCode)→ 响应始终是200 - 在
w.WriteHeader()后又调用http.ServeFile→ 状态码被覆盖（ServeFile自动写200） - 错误页文件路径拼错，又没加 fallback → 返回空白或 panic
安全写法示例：
func custom404(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusNotFound)
w.Header().Set("Content-Type", "text/html; charset=utf-8")
http.ServeFile(w, r, beego.BConfig.WebConfig.ViewsPath+"/404.html")
}
然后注册：beego.ErrorHandler("404", custom404)
自定义非标准错误类型（如 "dbError"）
Beego 允许注册任意字符串错误类型，用于业务异常（如数据库不可用、第三方服务超时），比硬编码状态码更语义化。
使用条件：
- 必须先注册：
beego.ErrorHandler("dbError", dbErrorHandler) - 控制器中调用：
c.Abort("dbError")（注意引号里是字符串，不是数字） - 该字符串需与注册时完全一致，区分大小写
- 若同时存在
ErrorDb控制器方法和beego.ErrorHandler("dbError")，优先走 Controller 方式
关键点：这类自定义错误不会自动映射到 HTTP 状态码，你需要在处理器里自己决定返回 503 还是 500，并手动 w.WriteHeader(503)。
真正麻烦的不是怎么写模板，而是状态码那一行要不要写、什么时候写、写在哪——所有自定义错误页都绕不开这个细节。漏掉 WriteHeader，前端永远收不到正确的状态码。
