Fiber 的 app.Get() 会自动隐式注册同路径 HEAD 路由并复用同一 handler，仅跳过响应体写入；HEAD 请求仍执行完整中间件链和 handler 逻辑，包括参数、查询、头信息解析及副作用操作。
app.Get() 会自动注册 HEAD 路由，无需额外配置；这是 Fiber 的默认行为，不是 bug，也不是可开关选项。
为什么 HEAD 请求没 404，但你没写 app.Head()？
Fiber 的 app.Get("/path", h) 在底层调用 app.Add("GET", "/path", h) 的同时，**隐式注册同路径的 HEAD 方法**，并复用同一 handler。这意味着：
- 你只写一行
app.Get("/users", usersHandler)，HEAD /users就能正常响应（状态码 200，空 body） - handler 内部不会执行
c.SendString()或c.JSON()—— Fiber 自动跳过 body 写入，只返回 headers - 若 handler 中有副作用（如数据库查询、日志打点），它仍会在
HEAD请求中执行 —— 这不是框架拦截，而是 handler 照常运行
手动注册 app.Head() 有必要吗？
绝大多数场景下没必要。只有当你需要 区分 GET 和 HEAD 的逻辑 时才需显式注册：
- 比如
GET /metrics返回完整指标，而HEAD /metrics只校验服务健康（查 DB 连接池 + 快速 return） - 又如某些 API 规范要求
HEAD必须返回精确的Content-Length，而GET是流式响应 - 注意：
app.Head()不会覆盖app.Get()隐式注册的路由；两者共存时，HEAD请求匹配到的是你手动写的app.Head()
HEAD 请求里 c.Params()、c.QueryParam() 正常吗？
完全正常。Fiber 对 HEAD 的处理仅限于 **不写响应体**，其余全部与 GET 一致：
-
c.Params("id")能取到路径参数（如/user/:id匹配/user/123） -
c.QueryParam("format")能读?format=json -
c.Get("Authorization")能取 header - 中间件链（
app.Use()、分组.Use()）全部生效
唯一区别：即使你在 handler 里写了 c.JSON(map[string]string{"ok": "true"})，HEAD 请求也不会发送这个 JSON。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
别踩坑：HEAD 不是“只检查路由是否存在”
有人误以为 HEAD 是框架级轻量探测，实际它和 GET 共享整条中间件+handler 执行链。容易出问题的地方：
- 权限中间件里写了
c.Status(401).SendString("unauthorized")却没return→ 后续 handler 仍执行，可能 panic 或重复写 header - 用了
c.BodyParser(&v)解析 JSON body →HEAD请求没有 body，err是io.EOF，必须显式判断 - 前端用
fetch("/api/x", { method: "HEAD" })但后端 handler 里调了c.FormValue("name")→ 永远为空，因为HEAD不带 form data
真正该省资源的地方在 handler 内部：对 HEAD 提前 return nil，跳过耗时操作，而不是指望框架帮你跳过逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
