Gin框架中router.HEAD和router.OPTIONS不会自动fallback到GET，因其路由树按method+path双维度匹配，HEAD和OPTIONS与GET是独立节点，必须显式注册；router.Any()仅为批量注册语法糖，不支持method语义区分。
为什么 router.HEAD 和 router.OPTIONS 不会自动 fallback 到 GET
Gin 默认不为 HEAD 或 OPTIONS 方法提供隐式 fallback。比如你只注册了 r.GET("/api/users")，当客户端发来 HEAD /api/users 请求时，Gin 不会复用那个 GET handler，而是直接返回 404。这和 net/http 的默认行为一致——每个方法必须显式注册。
原因在于 Gin 的路由树（基于 radix tree）按 method + path 双维度匹配，GET 和 HEAD 是完全独立的节点。它不像某些框架（如 Express）默认把 HEAD 映射到同路径 GET 并忽略响应体。
- 如果你依赖浏览器或 curl 自动发送 HEAD 探活，必须手动注册
r.HEAD -
OPTIONS同理：CORS 预检请求失败，往往是因为没写r.OPTIONS或没配Allow-Origin头 - 别指望
router.Any()覆盖所有方法——它只是批量注册，仍需你明确列出要支持的方法
router.Any() 的实际行为与陷阱
router.Any() 看似“支持任意方法”，但它只是语法糖：内部遍历 []string{"GET", "POST", "PUT", "PATCH", "DELETE", "HEAD", "OPTIONS"} 并为每个方法调用对应注册函数。它不包含 CONNECT、TRACE 或自定义方法（如 REPORT）。
更关键的是：所有注册的 handler 都是**同一份函数副本**，无法区分原始 method。这意味着你不能在 handler 里靠 c.Request.Method 做分支逻辑——因为所有方法都走同一个入口，容易掩盖语义差异。
立即学习“go语言免费学习笔记（深入）”；
- 适合场景：健康检查端点（
/health），所有方法都返回 200 OK - 不适合场景：需要按 method 执行不同业务逻辑的端点（比如
PUT更新 vsPATCH局部更新） - 若真要泛支持，建议用
r.Handle("METHOD", path, handler)显式传入 method 字符串
如何安全支持自定义 HTTP 方法（如 REPORT、SEARCH）
Gin 允许通过 r.Handle("REPORT", "/search", handler) 注册任意 method 字符串，但要注意两点：标准库 net/http 本身接受任何 method 名，但部分代理、网关或客户端库可能静默丢弃非标准 method。
真正的问题不在 Gin，而在整个 HTTP 生态链路是否认可该 method。例如：SEARCH 是 RFC 5323 定义的，但多数反向代理（Nginx、Traefik）默认不放行，会直接 405；REPORT 在 WebDAV 场景中存在，但浏览器 fetch API 不支持。
- 注册前先确认基础设施（LB、CDN、客户端 SDK）是否透传该 method
- 避免在公开 API 中使用非标准 method，除非上下游已约定好
- 如果只是想统一处理多个 method 的共性逻辑，优先用中间件 +
c.Request.Method分支，而非注册新 method
调试非标准 method 请求失败的典型路径
当你发现 REPORT /foo 返回 404 或 405，排查顺序应该是：客户端 → Gin 路由 → 中间件 → 反向代理 → 防火墙。
最常被忽略的是中间件提前 abort：比如 gin.Recovery() 不捕获 panic，但某些鉴权中间件在未识别 method 时直接 c.AbortWithStatus(405)，而你没在日志里打 c.Request.Method。
- 在第一个中间件里加
log.Printf("method=%s path=%s", c.Request.Method, c.Request.URL.Path) - 用
c.FullPath()确认路由是否匹配（注意：未注册 method 时FullPath为空字符串） - 检查
c.Writer.Status()是否已被设为 405 —— 这说明某个中间件已拒绝，而非路由未找到
