Echo框架路由默认无状态，因每个请求生成全新context且不共享内存；需避免包级变量、非法c.Set()、本地缓存无TTL等隐式状态，认证/会话/业务状态必须外置到JWT、Redis或数据库。
Echo 框架本身不自动保证无状态，但它的路由机制天然适配无状态设计——关键在你如何组织 handler、避免隐式状态依赖、并把状态外置。
为什么 Echo 的 GET/POST/PUT 路由默认就是无状态的起点
Echo 的路由注册（如 e.GET("/users", handler)）只绑定函数，不绑定实例或上下文。每个请求进来时，echo.Context 是全新构造的，里面没有跨请求共享的内存变量。这意味着：只要你不往 echo.Context 里塞全局缓存、不读写包级变量、不调用带内部状态的单例服务，handler 就是天然无状态的。
常见误操作包括：
- 在 handler 内部直接使用
var cache = make(map[string]interface{})—— 这个 map 会随 handler 复用而残留旧数据 - 从
echo.Context取出的c.Get("user_id")是临时存取，但如果你在中间件里写了c.Set("user_id", id)却没校验来源，就可能把伪造或过期值传给下游 - 用
sync.Map或map做本地缓存，却没加 TTL 或清理逻辑，导致脏数据累积
echo.Context 怎么用才不算破坏无状态性
echo.Context 是请求生命周期内的“暂存区”，不是状态存储。它只该用于传递本次请求已验证/已解析的数据，比如：
- 从 JWT 解析出的
user_id，经签名验证后存入c.Set("user_id", id)，下游 handler 直接信任使用 - 从
c.QueryParam("page")解析出的整数，转成int后存入c.Set("page_num", n)，避免重复解析 - 数据库查询结果临时挂载，仅用于模板渲染或后续中间件加工，不用于跨请求关联
绝对不要做：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 把
c.Set()当 session 用，例如存用户购物车 ID 并期望下个请求还能读到 - 在
c.Set()存时间戳然后和上个请求比对——这违反了无状态前提 - 把
c.Request().Context()里的 value 当长期状态容器（它只活到当前请求结束）
真正需要外置的状态有哪些，以及怎么对接
无状态 ≠ 没有状态，而是状态不能存在 handler 或 Echo 实例内部。以下三类必须外置：
-
认证状态：用 JWT 替代 session。解析后只取
sub、exp字段，验证通过即存入c.Set("user_id", ...)，不保存 token 本身到内存 -
会话数据：如用户偏好、临时表单草稿，存 Redis，key 用
session:{token_hash}，TTL 显式设置（如 30m） - 业务状态：如订单支付中状态，必须落库，不能靠内存 map 记录 “ID → pending”
示例：JWT 中间件中验证失败应返回 401，而不是往 c.Set() 写一个 "auth_failed" 标志让下游判断——那会让逻辑分散且不可测。
容易被忽略的隐式状态陷阱
这些地方看似无害，实则悄悄引入状态耦合：
-
time.Now()在 handler 里多次调用 —— 看似只是取时间，但如果用来生成唯一 ID（如拼接毫秒+随机数），在高并发下可能重复；应改用github.com/oklog/ulid或数据库自增 - 用
rand.Intn()生成验证码但没设 seed —— 默认 seed 来自时间，同一毫秒内多个请求会拿到相同值 - 中间件顺序错乱：比如日志中间件放在 JWT 验证之前，导致未认证请求也记了完整 body，既不安全又污染日志语义
- 数据库连接池配置不当：
MaxOpenConns设为 1，所有请求排队等待同一个连接，形成隐式串行状态
无状态的边界不在 Echo 框架层，而在你是否把「本次请求所需全部信息」显式收口、验证、传递。一旦开始靠「上次请求留下的痕迹」做判断，就已偏离 RESTful 本质。
