必须用 app.use 中间件通过 ctx.method() 检查 http 方法，对非法方法立即调用 ctx.status(405).sendstring() 并 return 终止链；不可依赖路由未注册，因泛匹配或前置中间件仍会执行。
怎么用 Fiber 的 Use 中间件拦截非预期方法
直接禁用某个 HTTP 方法（比如禁止 PUT 或 DELETE）不是靠“开关”，而是靠中间件提前响应并终止请求链。Fiber 没有内置的 disableMethod 配置，必须手动拦截。
常见错误是只在路由定义里漏写某方法，但这样无法阻止恶意请求——只要路径匹配、方法存在，Fiber 仍会尝试匹配，甚至可能 fallback 到其他 handler。
- 在
app.Use中统一检查：ctx.Method()，对非法方法立即ctx.Status(405).SendString("Method Not Allowed") - 务必调用
return或ctx.Next()控制流程；不 return 会导致后续 handler 仍被执行 - 若只针对某组路由（如
/api/v1/），把该中间件挂到对应app.Group()下，避免全局误杀
为什么不能只靠路由注册来“禁用”方法
Fiber 的路由匹配是松耦合的：即使你没为某个路径注册 PUT handler，只要请求到达，且没有更精确的匹配，它可能被泛匹配路由（如 app.All("*", ...) 或未限定 method 的 app.Get）捕获，或触发 404 前被中间件处理。
更危险的是，某些中间件（如 JWT 验证、日志记录）会在路由匹配前执行，它们并不关心方法是否合法——这意味着敏感逻辑可能被意外触发。
-
app.Delete("/user", handler)缺失 ≠DELETE /user被拒绝 - 如果存在
app.All("/user", ...)，该路由会响应所有方法，包括TRACE、CONNECT等非常规方法 - 真实攻击中，
OPTIONS或PROPFIND可能绕过前端限制，直接探测后端行为
如何精准放行只读方法、拦截写操作
生产环境常见需求是：允许 GET、HEAD、OPTIONS，但禁止所有带副作用的方法（POST、PUT、DELETE、PATCH）。这时应基于语义而非黑名单枚举。
- 定义只读方法集合：
readOnly := map[string]bool{"GET": true, "HEAD": true, "OPTIONS": true} - 中间件中检查：
if !readOnly[ctx.Method()] { ctx.Status(405).SendString("Method Not Allowed"); return } - 注意
HEAD必须显式放行——它虽无响应体，但语义等价于GET，且常被健康检查、CDN 预检使用 - 不要依赖
ctx.Request().Header.Method，ctx.Method()更稳定（已归一化）
禁用方法时容易忽略的兼容性点
禁用方法不是孤立动作，它会影响 CORS、调试工具和客户端行为。几个关键细节必须同步处理：
- CORS 预检（
OPTIONS）必须始终放行，否则浏览器发不出POST请求——哪怕你本意就是禁用POST，也得让预检通过再返回 405 - 禁用
TRACE是安全刚需，但某些老版代理或监控工具依赖它；若需兼容，至少返回空响应而非 405 - 用
curl -X METHOD测试时，注意默认携带User-Agent和Accept头，确保你的中间件没因这些头误判 - 如果用了
fiber.New(fiber.Config{DisableStartupMessage: true})，记得加日志：log.Printf("Blocked %s %s", ctx.Method(), ctx.Path())，否则线上无法排查误拦
ctx.Method() 并果断中断的中间件。
