Golang策略模式实现多引擎搜索方案

本文深入探讨了如何在 Go 语言中基于策略模式构建高内聚、低耦合的多引擎搜索系统，核心在于通过严谨的契约设计（统一的 `SearchRequest` 和泛型 `SearchResult[T]`）剥离引擎差异，将分页、过滤、错误处理、序列化等特有逻辑完全下沉至各策略实现内部，避免跨引擎语义污染；同时强调工厂函数替代接口注册以精准管控连接生命周期，并警示泛型使用中类型导出、JSON 可见性及解码责任归属等易被忽视的关键细节——真正考验架构功力的，不是初始双引擎支持，而是后续任意引擎能力演进时，能否做到“改一处、不波及其他”，让策略模式从理论落地为可持续演进的工程实践。

怎么定义统一的搜索接口，让 Elasticsearch 和 DB 引擎能互换？

关键不是写两个 struct，而是先想清楚「什么必须一致」：输入参数、返回结构、错误语义。否则后期切引擎时要改业务代码，策略模式就白搭。

推荐用一个 SearchRequest 和 SearchResult 作为契约，字段只保留通用部分（如 Query、Offset、Limit、Total），引擎特有字段（如 ES 的 highlight 或 DB 的 OrderBy）不放进去，靠具体实现内部处理。

常见错误现象：
- 把 es.SearchSource 或 gorm.DB 直接塞进接口方法签名 → 违反抽象原则
- 返回类型用 interface{} 或 map[string]interface{} → 调用方没法做类型安全操作
- SearchResult.Items 类型不统一（ES 返回 []map[string]interface{}，DB 返回 []User）→ 必须转成同一结构体或泛型切片

• 用泛型定义结果集：type SearchResult[T any] struct { Total int; Items []T }
• 接口方法签名固定为：Search(ctx context.Context, req SearchRequest) (SearchResult[any], error)，实际使用时再类型断言或传入具体类型参数
• 避免在接口层暴露底层错误（如 elasticsearch.Error 或 mysql.MySQLError），统一转成自定义错误如 ErrSearchTimeout、ErrInvalidQuery

如何让 ES 和 DB 引擎共用同一套分页和过滤逻辑？

分页本身是通用的，但 ES 的 from/size 和 DB 的 LIMIT/OFFSET 行为不完全等价——ES 在深度分页（from > 10000）时会拒绝，DB 则可能慢但不会报错；过滤字段名也常不一致（比如 ES 用 status.keyword，DB 用 status）。

所以不能把原始 WHERE 或 bool query 拼接逻辑放在策略外，而应把「解析请求 → 映射为引擎原语」这步下放到每个策略内部。

• 在 SearchRequest 中用中立字段命名，如 Filters map[string]string，不带数据库或 ES 语义
• ES 策略里把 Filters["status"] 映射为 term query + status.keyword 字段；DB 策略里映射为 WHERE status = ?
• 分页统一用 Offset 和 Limit，ES 策略内判断是否超 10000，超了就返回 ErrDeepPagination，而不是静默降级
• 不要在调用前手动计算 from = Offset，交给具体策略决定——ES 可能改用 search_after，DB 可能加覆盖索引提示

为什么不用 interface{} 做策略注册，而要用工厂函数？

因为引擎初始化成本高（ES 需要 client 连接池，DB 需要 *gorm.DB 或 sqlx.DB），且配置差异大（地址、超时、重试、TLS）。如果用 map[string]interface{} 存实例，容易出现连接复用混乱、配置没生效、panic 时难定位。

真实场景里，你大概率需要：DB 引擎走读写分离（master/slave），ES 引擎支持多集群路由（logs/users），这些没法靠一个空接口承载。

• 用工厂函数封装初始化：func NewESEngine(cfg ESConfig) (Searcher, error)、func NewDBEngine(cfg DBConfig) (Searcher, error)
• 注册表存的是工厂，不是实例：registry := map[string]func() (Searcher, error){ "es": func() { return NewESEngine(esCfg) }, "db": func() { return NewDBEngine(dbCfg) } }
• 每次 Get("es") 都新建 searcher？不，工厂内部应做单例或连接池复用；关键是「谁控制生命周期」——由工厂自己管，别丢给上层协调
• 避免全局变量存 engine 实例；多个测试用例并行跑时，容易互相污染连接状态

泛型策略接口在 Go 1.18+ 怎么避免类型擦除导致的运行时 panic？

Go 泛型不是 C++ 模板，编译后类型信息会擦除。如果你写了 func (e *ESEngine) Search[T any](...)，但调用时传了未导出字段的 struct（比如 type user struct{ name string }），JSON 反序列化就会静默失败，Items 为空 slice —— 看似没报错，实则数据丢了。

这不是策略模式的问题，是 Go 反序列化机制的约束。必须提前守住这一关。

• 所有要进 SearchResult[T] 的 T，必须是导出类型（首字母大写），且字段可被 JSON 包访问（同样导出 + tag 正确）
• ES 策略内部用 json.Unmarshal 前，先检查 T 是否实现了 json.Unmarshaler；DB 策略用 sql.Scan 前，检查是否支持 driver.Valuer
• 最稳妥的做法：策略接口不暴露泛型方法，而是要求调用方传入「结果转换函数」：Search(ctx, req, func(raw json.RawMessage) (any, error))，把解码责任交出去，策略只管取原始字节流
• 别依赖 IDE 自动补全来判断泛型是否安全；跑一遍 go vet 和单元测试，用真实 struct 覆盖边界 case（如嵌套 map、nil slice）

事情说清了就结束。真正麻烦的从来不是写两个策略，而是当产品突然说“DB 搜索要支持模糊匹配，ES 要加同义词”时，你得确保改一处不影响另一处——那才考验接口抽象的厚度。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Golang策略模式实现多引擎搜索方案》文章吧，也可关注golang学习网公众号了解相关技术文章。