闭包本身不构成策略路由，真正起作用的是结构体持有的策略接口加闭包封装的初始化逻辑；闭包仅捕获依赖并返回HandlerFunc，负责绑定上下文，不参与策略判断或调度，策略应由SearchStrategy接口的Execute方法实现。
闭包本身不构成策略路由，真正起作用的是结构体持有的策略接口 + 闭包封装的初始化逻辑；直接把业务逻辑全塞进闭包里，后期根本没法做灰度、开关或指标采集。
闭包在策略路由里只干一件事：捕获依赖并返回 HandlerFunc
你看到的 s.Search() 这种写法，本质是闭包工厂——它不执行业务，只返回一个能访问 service 实例字段的 HandlerFunc。关键点在于：闭包只负责“绑定上下文”，不负责“判断策略”或“调度行为”。
- 闭包捕获的是结构体指针（如
*service），不是值拷贝，所以能读写其字段（如portManager） - 闭包内不能放策略选择逻辑（比如根据请求头决定走缓存还是 DB），那该由策略接口的
Execute()方法承担 - 如果闭包里写了
if req.Header.Get("X-Env") == "test" { ... }，等于把策略硬编码进路由层，违反开闭原则
策略必须抽成接口，而不是靠多个闭包分支
用一堆 func() HandlerFunc 工厂函数模拟策略，看着灵活，实则不可维护。正确做法是定义明确的策略接口，并让结构体持有其实例。
- 定义
type SearchStrategy interface { Execute(param PageParam) ([]TestPortManager, int64, error) } -
service结构体加字段：searchStrategy SearchStrategy -
Search()方法不再自己实现查询，而是调用s.searchStrategy.Execute(...) - 测试时可注入
&MockSearchStrategy{}，上线换为&DBSearchStrategy{db: s.db}
组合结构体要暴露策略切换入口，而非重写闭包
当路由需要支持“同一路径在不同环境走不同策略”时，靠重新注册 engine.POST("/page", newService().Search()) 是低效且易错的。结构体应提供运行时可变的策略绑定能力。
立即学习“go语言免费学习笔记（深入）”；
- 给
service加方法：func (s *service) SetSearchStrategy(ss SearchStrategy) { s.searchStrategy = ss } - 启动时按配置注入：
s.SetSearchStrategy(cfg.BuildSearchStrategy()) - 避免在 HTTP handler 内部做
switch cfg.Mode，那会让 handler 变成策略分发器，职责混乱 - 注意：
SetSearchStrategy必须是线程安全的（加锁或仅限初始化阶段调用）
闭包+结构体组合最容易踩的内存坑
闭包捕获结构体指针本身没问题，但若闭包引用了局部变量（尤其是切片、map、通道），极易引发意外的内存泄漏或数据竞争。
- 错误示范：
func(s *service) Search() HandlerFunc { data := make([]byte, 1024); return func(...) { use(data) } }——data会随闭包常驻内存，无法被 GC - 正确做法：所有临时数据都在 handler 函数体内分配，闭包只捕获结构体字段或全局/单例对象
- 结构体字段如果是大对象（如
*sql.DB或sync.Pool），确保它是共享实例，不要在闭包里反复 new - 用
go vet -race检查 handler 是否意外捕获了 goroutine 局部变量
真正难的不是写出能跑的闭包路由，而是让策略可观察、可替换、可灰度——这要求你把“策略决策”从闭包里拎出来，交给接口和结构体字段管理；闭包只做它该做的：干净地把 handler 和依赖粘在一起。
