应使用 e.get("/health", healthhandler).skipmiddleware = true 显式跳过中间件，而非先 e.use() 再注册路由；/health 仅检查进程存活、无 io、响应 ≤1s，/readyz 才可做短超时依赖探测。
Echo 框架里怎么注册 /health 路由不被中间件拦住
必须用 e.GET("/health", healthHandler).SkipMiddleware = true，而不是先 e.Use() 再注册路由。Echo 的中间件默认作用于所有后续路由，健康检查若被 JWT 验证、CORS 或日志中间件套住，轻则返回 401/403，重则因超时或 panic recover 干扰导致探针误判。
常见错误写法：e.Use(middleware.JWT()) 放在最前，然后 e.GET("/health", ...) —— 这时 JWT 中间件已生效，/health 会要求 token。
-
.SkipMiddleware = true是 Echo v4+ 的显式跳过机制，只对当前路由生效 - 别用
e.Group("/").SkipMiddleware(...)，Group 不支持 SkipMiddleware - 如果用了自定义中间件（比如请求 ID 注入），也要确认它没对
/health做副作用操作（如强制写 header）
/health 和 /readyz 该用什么逻辑区分
Go 生态里，/health 应只回答“进程是否还在跑”，/readyz 才回答“能不能接流量”。Kubernetes 的 livenessProbe 和 readinessProbe 就是按这个语义设计的，混用会导致雪崩。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
/health：检查atomic.LoadInt64(&up)或简单返回{"status":"ok"}，无 IO，响应必须 ≤1s -
/readyz：可查db.PingContext(ctx, 500*time.Millisecond)、redisClient.Ping(ctx).Err()，但超时必须设短（≤1s），且失败只影响 readiness，不杀进程 - 别在
/health里调db.Ping()—— 一旦 DB 挂了，K8s 会无限重启 Pod
handler 函数签名和响应体怎么写才不出错
Echo 的 handler 必须返回 error，且不能用 c.String() 直接塞状态码，否则中间件可能二次写 header 导致 http: multiple response.WriteHeader calls 错误。
- 正确写法：
return c.JSON(http.StatusOK, map[string]string{"status": "ok"}) - 避免
c.String(200, "ok")：它不设 Content-Type，某些探针（如旧版 kubelet）会因 MIME 类型不匹配判为失败 - 不要在 handler 里打常规日志（如
log.Println）——高频探针会让日志量暴增；真要记录，只在 error 场景写到 stderr - 如果用了
echo.HTTPErrorHandler全局兜底，确保它对/health和/readyz不做重定向或额外渲染
为什么不能用 http.HandleFunc 单独起一个 server
有人图省事，在 Echo 启动后另起一个 http.Server 监听 :8081 做健康检查，这看似隔离，实则埋雷。
- 运维视角丢失统一端口：K8s Service 只暴露一个 port，你得额外开
targetPort，配置变复杂 - HTTPS/TLS 终止失效：Ingress 或 LoadBalancer 做了 TLS 终止，但新起的 server 拿不到证书上下文，
/health只能走 HTTP，违反安全策略 - 就绪信号不同步：主服务启动完成才该置
ready = 1，但两个 server 生命周期独立，容易出现/readyz已返回 ok，而业务路由还没注册完 - 真正轻量又可控的方式，就是走 Echo 原生路由 +
SkipMiddleware，复用同一监听地址和 TLS 配置
