echo网关需严格按约定存consul kv路由：key以config/gateway/routes/开头、用连字符分隔、无点号；value为合法json，含id/uri/predicates字段；写入须加-从stdin读；acl需kv_read权限；后台goroutine用waitindex长轮询监听，原子更新内存路由表。
Consul KV 路由数据怎么存，Echo 才能正确读取
Consul 本身不理解“路由”语义，只认 key 和字符串 value。Echo 网关必须自己约定结构，错一个字符就查不到、解析失败。
推荐使用 config/gateway/routes/ 作为前缀（和 Spring Cloud Gateway 兼容，也方便后续统一治理）。每个路由单独一个 key，例如：
config/gateway/routes/user-service
value 必须是合法 JSON 字符串，不能带 BOM、尾随逗号或注释。至少包含字段：id、uri、predicates（如 [{"name":"Path","args":{"pattern":"/api/users/**"}}]）。
- key 中避免点号（
.），改用连字符（-）——某些 Go 客户端会把service.v1解析成嵌套结构，导致匹配失败 - 写入时用
consul kv put -从 stdin 读，漏掉-会导致空内容写入，后续watch静默跳过 - 确保 ACL token 有
kv_read权限，否则watch不报错但永远收不到变更
用 Echo 中间件加载并热更新路由表
Echo 没有内置配置中心集成，得靠自定义中间件 + 后台 goroutine 维持 watch 连接。不能只在启动时拉一次，否则扩容缩容就失效。
流程分两步：先用 consul api.KV().List() 拉全量初始路由；再用 consul api.QueryOptions.Wait = "0s" 启动长轮询 watch。注意要传 consul api.QueryOptions.Token，ACL 权限不足时 watch 会静默失败。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 每次
watch返回新结果后，必须原子替换内存中的路由映射——用sync.Map或RWMutex保护的map[string]Route，不能边遍历边修改，否则并发访问时 panic - watch 默认间隔是 10 秒，不是实时；若 Consul 集群多节点，确保连接的是 leader 节点（用
consul operator raft get-config查 leader ID） - 日志里没出现
Watch returned new results提示，优先检查 ACL 权限和 key 前缀是否完全匹配（结尾斜杠、大小写都算不匹配）
Director 函数里必须重写的两个字段：Path 和 Host
90% 的 404 和后端鉴权失败，根源都在 req.URL.Path 和 req.Host 没被显式重写。Echo 的反向代理不自动适配后端期望，也不联动 predicate 规则。
假设路由规则中 predicates 是 [{"name":"Path","args":{"pattern":"/api/users/**"}}]，那 Director 里就得做：
proxy := httputil.NewSingleHostReverseProxy(&url.URL{Scheme: "http", Host: "127.0.0.1:8081"})<br>proxy.Director = func(req *http.Request) {<br> req.URL.Path = strings.TrimPrefix(req.URL.Path, "/api")<br> req.Host = "users-srv"<br>}
-
strings.TrimPrefix(req.URL.Path, "/api")的前缀必须和predicates中定义的pattern完全一致，多一个斜杠、大小写错误或正则通配符未对齐，TrimPrefix就失效 -
req.Host必须设成目标服务注册到 Consul 的Name（如users-srv），而不是 IP+端口——这样才能让下游服务（比如基于服务名做鉴权或灰度）正确识别来源 - 别依赖
httputil.NewSingleHostReverseProxy的默认行为，它不会帮你做路径剥离或 Host 注入
为什么不用 Gin 而选 Echo？性能差异其实不关键
选 Echo 主要不是因为压测数字高几毫秒，而是它的中间件生命周期更可控、错误传播更清晰，适合网关这种需要精细控制请求流的场景。
Gin 的中间件链在 panic 时容易吞掉错误上下文；Echo 的 echo.Context.Error() 和 HTTPErrorHandler 更容易注入兜底逻辑（比如路由未匹配时返回 404 并打标日志）。
- Echo 的
Group路由支持嵌套中间件，方便按 path prefix 分离动态路由与静态 API - 它的
echo.HTTPError可直接携带原始错误原因，调试时比 Gin 的c.AbortWithStatusJSON()更易定位是 Consul 连接超时还是 JSON 解析失败 - 真正卡脖子的从来不是框架，而是 KV watch 断连重试逻辑、Director 路径重写精度、以及 ACL 权限颗粒度——这些和用啥框架关系不大
