应将处理器函数定义为独立导出函数而非匿名函数或方法，以解耦路由与业务逻辑、便于测试和复用；路由与handler需按业务模块分离组织，中间件负责准备上下文数据，handler仅消费不构造依赖。
为什么不能把处理器函数直接写在 e.GET() 里
因为硬编码 handler 会导致路由注册和业务逻辑完全耦合，一旦 handler 需要复用、测试或加中间件，就得复制粘贴或绕弯子。比如你写了 e.GET("/users/:id", func(c echo.Context) error { ... })，后续想给这个接口加日志或鉴权，就得改路由注册行——这不是扩展，是破坏。
更实际的问题是：handler 函数体变长后，e.GET() 行会越来越难读；单元测试时无法单独调用该 handler；团队协作中别人不知道这个匿名函数在哪维护。
func(c echo.Context) error 应该定义成独立函数还是方法
优先定义为包级函数，不是方法。Echo 的 handler 签名固定为 func(echo.Context) error，把它塞进结构体方法里反而需要额外包装，徒增一层调用和 receiver 传递。
- ✅ 推荐：直接定义为导出函数，如
GetUserByID(c echo.Context) error - ❌ 避免：
u.UserHandler.GetUserByID(c echo.Context) error—— 这会让 handler 依赖实例状态，难以 mock 和复用 - ⚠️ 特殊情况：若 handler 必须访问某个服务实例（如 DB client），可通过闭包预绑定，而不是塞进方法里：
func(db *sql.DB) echo.HandlerFunc { return func(c echo.Context) error { ... } }
如何组织路由文件与 handler 文件的目录结构
常见错误是把所有 handler 都扔进 main.go，或者按 HTTP 方法（get.go / post.go）拆分——这违背了领域边界。应该按业务模块组织，且路由注册和 handler 实现物理分离。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 路由注册放
router/router.go，只负责e.GET()、e.POST()调用 - handler 实现放
handlers/user.go、handlers/product.go，每个文件对应一个资源 - 避免跨 handler 共享变量（如全局
db），统一通过依赖注入传入（如用echo.Group.Use()注入中间件提供上下文值）
示例：router/router.go 中写 userRouter := e.Group("/users"); userRouter.GET("/:id", handlers.GetUserByID)，而 handlers/user.go 只含 func GetUserByID(c echo.Context) error 定义。
中间件介入时，handler 如何保持无状态
中间件（如鉴权、日志）常需往 c.Request().Context() 或 c.Set() 存数据，但 handler 本身不该主动查这些——否则就又耦合了。正确做法是让中间件把必要信息“准备好”，handler 只管取。
- 鉴权中间件做完校验后，应把用户 ID 存到 context：
c.Set("user_id", userID) - handler 中用
c.Get("user_id")拿，不自己解析 token 或查 session - 不要在 handler 里调用
c.Request().Header.Get("Authorization")—— 这属于中间件职责 - 如果 handler 需要 DB 操作，中间件应已把
*sql.DB或 repository 实例挂进 context，handler 直接取用即可
真正容易被忽略的是：handler 函数签名看似简单，但它承载的是「契约」——它只承诺接收 echo.Context 并返回 error，其余一切依赖都该由外部注入，而非自行构造或全局获取。
