必须显式调用e.Pre(echo.MiddlewareFunc())启用echo.Context复用池，否则10k+ QPS下runtime.mallocgc占CPU超15%；该调用须在e.Use()前，且Context中不可存大对象，HTTP客户端需设全三处超时。
echo.Context 复用池必须显式开启，否则缓冲区分配失控
Echo 默认每次请求都 new 一个 echo.Context 实例，不开启复用时，10k+ QPS 下 runtime.mallocgc 占 CPU 15% 以上——这不是业务代码问题，是框架层对象分配爆炸。缓冲区（如 JSON 序列化用的 bytes.Buffer）也依赖这个上下文池，关掉它等于关掉所有响应缓冲复用。
必须在初始化阶段调用 e.Pre(echo.MiddlewareFunc()) 启用上下文对象池；且该调用**必须在 e.Use() 之前**，否则中间件栈已构建完成，池机制不生效。
-
e.Pre()是唯一启用 Context 复用的入口，echo.New()不会默认开启 - 检查你是否误删或注释了这行：它常被当成“可选配置”忽略
- 开启后，
echo.Context内部的responseWriter缓冲、queryCache、paramCache全部走 sync.Pool
别在 Context 里存大对象，否则池失效还拖慢 GC
Context 复用池只回收对象本身，不清理字段内容。如果 handler 中往 c.Set("big-data", []byte{...}) 或 c.Set("dto", hugeStruct{}) 存了大结构体或字节切片，下次复用时这些内存仍被占用，池退化为“假复用”，GC 压力照旧。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 只存轻量引用：ID、string、*struct、func 等指针或不可变值
- 避免
c.Set()存[]byte、map[string]interface{}、JSON raw message - 高频接口若需缓存序列化结果，自己建
sync.Pool管理bytes.Buffer或 DTO 实例，别塞进 Context
HTTP 客户端超时没设全，缓冲池再快也卡死
压测时大量 goroutine 卡在 net/http.(*persistConn).roundTrip，pprof 堆栈停在 runtime.gopark——这不是 Echo 的锅，是下游 HTTP 调用没设全超时，连接池耗尽，导致后续请求排队等连接，响应缓冲根本没机会写。
- 必须同时设置三处：
Timeout（总生命周期）、Transport.DialContext.Timeout（拨号上限，建议 3s）、Transport.ResponseHeaderTimeout（发完请求到收响应头的上限） - 漏掉任一环节，高并发下就会出现“无报错但越来越慢”的假死
- 尤其注意
ResponseHeaderTimeout：后端挂住不发 header，你的缓冲区永远等不到 flush 时机
静态路由优先级影响缓冲复用效率
Echo 路由树按静态 > 参数 > 通配符顺序匹配。如果把 /users/:id 写在 /users/new 前面，每次访问 /users/new 都要先匹配参数路由失败再 fallback，多一次字符串解析和 buffer 分配——对高频静态路径，这种开销会被放大。
- 静态路由（如
/health,/metrics）尽量前置定义 - 避免用
/users/:id?这类可选参数路由替代两个独立静态路由 - 路由分组（
e.Group("/api")）本身不增加开销，但嵌套过深可能让中间件执行链变长，间接影响缓冲写入时机
真正卡住缓冲复用的，往往不是池本身配置，而是 Context 生命周期管理失当或下游依赖失控。开了 e.Pre() 只是起点，后面每一步都在决定它能不能真正省下那几 MB 内存和几十微秒 GC 时间。
