最稳的鉴权跳过方式是用 Group 拆分路由：public.Group() 放免鉴权接口（如 /login、/health），auth.Group("/api") 统一挂载 JWT 中间件；避免全局注册+路径白名单，防止漏校验或误判，同时必须显式放行 OPTIONS 预检请求。
用 Group 拆分路由是最稳的跳过方式
直接把需要鉴权和不需要鉴权的接口划到不同 e.Group() 下，而不是在中间件里写一堆 if path == "/login" 判断。Group 天然隔离中间件作用域，避免漏掉 OPTIONS 预检、带参数路径（如 /users/:id）或未来新增接口。
常见错误是把 jwt.Middleware 放进 e.Use() 全局注册，再靠中间件内部硬编码路径白名单绕过——这既难维护，又容易因路径解析差异（比如 c.Path() 和 c.Request().URL.Path 不一致）导致校验意外触发。
-
public := e.Group("")放/login、/health、/register等无需 JWT 的接口 -
auth := e.Group("/api")专门挂载auth.Use(jwt.Middleware(...)) - 所有需鉴权的 handler 必须注册在
auth下，不能错挂到根实例或public
必须混用同一组时，用 context 标记跳过
遗留系统改造等极少数场景下无法拆分 Group，就得自己封装一层 JWT 中间件，在原逻辑前插入跳过判断。官方 jwt.Middleware 不支持动态跳过，硬改它源码或 patch 都不可取。
关键不是“跳过中间件”，而是让 JWT 校验逻辑主动短路：提前调用 c.Set("skip_jwt", true)，再确保自定义中间件注册在 jwt.Middleware 之前。
- 标记必须在
jwt.Middleware执行前完成，比如放在另一个中间件里，或在特定路由 handler 开头手动c.Set() - JWT 中间件内部要读
c.Get("skip_jwt")，为true时直接return next(c)，不执行 token 解析和校验 - 绝不能只
return nil或裸调next(c)后续不处理——这会跳过日志、CORS 等后续中间件
OPTIONS 预检请求必须被显式放行
CORS 预检请求（OPTIONS）不会携带 Authorization 头，如果它被 JWT 中间件拦住，前端发不出真实请求，现象是浏览器控制台报 401 或 Network Error，但后端日志里看不到对应 GET/POST 日志。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
无论用 Group 还是 context 标记方式，都得确认预检请求没被卡住。最可靠的做法是在 JWT 中间件开头加判断：
- 检查
c.Request().Method == "OPTIONS"，直接return next(c) - 不要依赖路径匹配（比如只放行
/api/*下的 OPTIONS），因为预检路径和实际请求路径完全一致，/api/users/:id的预检就是OPTIONS /api/users/123 - 避免在中间件里调用
c.NoContent(204)响应预检——这会让浏览器认为服务端不支持 CORS，应交由 Echo 自带的middleware.CORS()处理
别在中间件里做路径字符串匹配
用 c.Path() == "/login" 或正则匹配路径来跳过，看似简单，实则埋雷。Echo 的 c.Path() 是路由解析后的路径（已去掉查询参数、已展开参数占位符），而 c.Request().URL.Path 是原始路径；两者在重定向、代理、带参数路由等场景下可能不一致。
更严重的是，这种写法把业务路径耦合进中间件，一旦接口改名、加版本前缀、引入网关透传路径，就会漏掉校验或误判跳过。
- 路径判断只用于健康探针（如
/health）、预检（OPTIONS）等极少数明确、稳定、无参数的路径 - 绝不拿它做业务接口分类依据——那是路由分组（Group）该干的事
- 如果真要动态控制，优先用
c.Get("skip_jwt")这类上下文标记，而非路径字符串
复杂点在于，跳过逻辑一旦写进中间件，就很难做单元测试覆盖所有路径变体；而 Group 方式天然可测、可读、可维护。真正该花时间的，不是写更复杂的跳过条件，而是把路由结构理清楚。
