gin.default() 的 404/500 页面不可用于生产，因其硬编码 html、状态码与响应体耦合、不记录日志、覆盖自定义 json 响应；需用 r.noroute()/r.nomethod() 拦截并手动设状态码与响应体。
为什么 gin.Default() 的 404/500 页面不能直接用于生产
因为 gin.Default() 自动注册的 gin.Recovery() 和默认 404 处理器返回的是 HTML 页面，且状态码与响应体耦合严重：404 响应里硬编码了 HTML 字符串，500 响应不带堆栈、不记录日志、无法统一 JSON 格式。更关键的是，它会覆盖你手动写的 c.AbortWithStatusJSON()，尤其在 r.NoRoute() 之后注册的 handler 里完全失效。
如何用 r.NoRoute() 和 r.NoMethod() 拦截 404
必须把它们放在所有路由注册之后、启动前，且优先级高于其他中间件：
-
r.NoRoute()拦截所有未匹配路径（包括 POST /unknown） -
r.NoMethod()拦截路径存在但方法不支持（如 GET /api/user 而只注册了 POST） - 两者都必须调用
c.AbortWithStatusJSON(404, ...)或c.AbortWithStatus(404)，否则可能 fallback 到默认 HTML - 若需返回静态 HTML 页面，用
c.Data(404, "text/html; charset=utf-8", data)，别用c.File()—— 它会触发额外的文件读取和 header 设置，容易出错
怎样让自定义错误页带正确状态码且不暴露路径
Go 标准库的 http.Error() 不适合 Gin 场景，它绕过中间件链、无法注入日志字段、也不兼容 c.JSON() 流程。正确做法是封装一个复用函数：
func renderErrorPage(c *gin.Context, statusCode int, templateName string) {
c.Status(statusCode)
c.Header("Content-Type", "text/html; charset=utf-8")
data, _ := os.ReadFile(fmt.Sprintf("./templates/%s.html", templateName))
c.Data(statusCode, "text/html; charset=utf-8", data)
}
- 务必提前预加载或缓存
data，避免每次请求都os.ReadFile—— 生产环境 I/O 延迟不可控 - 模板中禁止拼接用户输入（如
{{.Path}}），防止 XSS；错误页内容应静态、脱敏 - 不要在
renderErrorPage里调用c.Abort()——c.Status()已设置状态码，后续c.Next()不会执行，但中间件链已终止
panic 和业务 error 必须分开处理，且顺序不能错
真实线上问题往往来自两类错误：handler 显式返回的 error（如参数校验失败），以及未被捕获的 goroutine panic（如空指针解引用）。这两者必须由不同中间件处理，且顺序严格：
- 最前面放自定义
PanicRecovery()中间件（调用debug.Stack()记录堆栈，用c.AbortWithStatusJSON(500, ...)终止） - 中间放业务逻辑和
c.Error()注入 - 最后放
UnifiedErrorMiddleware()，检查c.Errors并映射状态码 —— 放太前会被 panic 中间件覆盖，放太晚则c.Next()已执行完，无法 abort -
c.AbortWithError(401, err)可以替代c.Error()+ 后续中间件判断，但仅限你确定要立刻中断；它要求第二个参数必须是error类型，传字符串会 panic
最容易被忽略的一点：r.NoRoute() 和 r.NoMethod() 注册后，Gin 就不再走常规路由匹配逻辑，所以你的统一错误中间件对它们无效 —— 必须在 NoRoute 函数体内手动做状态码+响应体控制。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
