Echo未注册对应HTTP方法时直接返回405，因路由匹配阶段先查路径再校验方法，两者缺一不可；只注册GET却用POST访问即触发405，且不进入中间件或HTTPErrorHandler。
为什么Echo没注册对应方法就会返回405
Echo不会自动 fallback 到其他方法，也不提供“方法重试”逻辑。当你发起 POST /users 请求，但代码里只写了 e.GET("/users", ...)，Echo 就会直接返回 405 Method Not Allowed，连中间件都不会进——请求在路由匹配阶段就被拦下了。
这个行为由 Echo 内置的 NotFoundHandler 和方法检查机制共同决定：它先查路径是否存在，再校验该路径是否支持当前 HTTP 方法。两者缺一不可。
- 只注册
GET，却用curl -X POST访问 → 405 - 路径拼错（如
/uservs/users）→ 404，不是 405 - 注册了
POST，但中间件里c.Abort()早于 handler 执行 → 仍可能 405，取决于 abort 是否发生在方法校验后
如何让405错误走自定义HTTPErrorHandler
默认情况下，405 不会触发你设的 e.HTTPErrorHandler，因为它属于路由层拒绝，不是 handler 抛出的错误或 panic。想统一捕获，必须手动干预。
最稳妥的做法是：在所有路由注册完成后，用 e.NoMethodHandler 覆盖默认行为，并在里面显式调用 c.Error()：
e.NoMethodHandler = func(c echo.Context) error {
err := echo.NewHTTPError(http.StatusMethodNotAllowed, "method not allowed")
c.Error(err)
return nil
}
这样，err 就会被你的 e.HTTPErrorHandler 拦住，日志、状态码、响应格式都能统一控制。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 别在
NoMethodHandler里直接c.JSON(405, ...)—— 这会绕过HTTPErrorHandler，失去统一处理能力 - 确保
NoMethodHandler设置在e.GET/e.POST等所有路由注册之后，否则可能被覆盖 - 如果用了
e.Group()，需对每个 group 单独设NoMethodHandler，它不继承自父实例
405和中间件顺序的关系
中间件对 405 几乎无影响——只要路由没匹配上对应方法，中间件根本不会执行。但有两个例外场景容易混淆：
- 你在中间件里调用了
c.Request().Method并做了判断，然后c.Abort()，这返回的是你自定义的状态码（比如 403），不是 405 - 你用了
echo.WrapMiddleware包裹第三方中间件，而它内部修改了Request.Method（极少见），可能导致方法校验失败 - Nginx 或 CDN 在转发时把
POST改成了GET（例如配置了rewrite且没加last），后端看到的是 GET，但客户端发的是 POST → 客户端收 405，服务端日志里却是 GET 请求
遇到这类情况，第一反应不是改 Echo 代码，而是抓包看原始请求方法是否被篡改。
调试405时最容易忽略的一点
开发时用 curl -v 或浏览器 DevTools Network 面板看响应，只关注状态码和响应体，但漏掉了关键头：Allow。Echo 默认会在 405 响应里带上这个 header，例如：
Allow: GET, HEAD, OPTIONS
它明确告诉你这个路径实际支持哪些方法。如果你看到 Allow: GET 却发了 POST，问题就锁定在路由注册；如果 Allow 为空或缺失，说明请求压根没走到 Echo 路由层，得去查 Nginx、WAF 或 TLS 握手阶段的问题。
