同义词扩展搜索应在查询时改写而非索引时冗余，Go中推荐用内存映射表+OR条件实现轻量级替换，支持大小写归一化、最长词匹配及JSON配置管理。
同义词扩展搜索的核心是查询时改写，不是索引时冗余
Go 语言里做同义词扩展搜索，最容易走偏的方向是试图在 Elasticsearch 或 bleve 索引阶段把同义词全打散塞进去——这会导致召回率虚高、排序失真、存储膨胀。真正可控且可调试的做法，是在用户输入查询词后、发起检索前，用 Go 主动做一次语义等价替换，生成一组逻辑或（OR）查询条件。
关键判断点：你是否需要支持“模糊匹配”“多级同义”“领域定制”？如果只是基础场景（比如“笔记本”→“notebook”“laptop”），直接查内存映射表 + 拼接 OR 条件就够了；如果涉及词性、上下文或动态权重，就得引入分词器（如 gojieba）配合同义词图谱。
用 map[string][]string 实现轻量级同义词映射
适用于中小规模、静态词表、无歧义场景（如电商类目词、API 错误码说明）。不依赖外部服务，启动即加载，毫秒级响应。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 同义词表建议用 JSON 文件管理，避免硬编码：
synonyms.json结构为{"笔记本": ["notebook", "laptop", "便携电脑"]} - 加载时做小写归一化（
strings.ToLower），但保留原始词用于结果展示 - 查询改写时用
strings.TrimSpace清理空格，再做精确 key 匹配——不要用子串匹配，否则“苹果”会错误触发“苹果手机”“苹果汁” - 注意大小写敏感问题：若用户搜
"iPhone"，而词表存的是"iphone"，需统一转小写比对，但最终拼查询条件时还原原始大小写（尤其对区分大小写的搜索引擎）
与 Elasticsearch 集成时，用 bool.should 替代 synonym filter
很多人直接在 ES 的 analyzer 里配 synonym_graph，结果发现“华为手机”被拆成“华为 OR 手机”，召回大量无关结果。根本原因是 synonym filter 在分词阶段生效，破坏了短语完整性。
更稳妥的做法是 Go 层控制改写逻辑，再发多条件查询：
query := map[string]interface{}{
"bool": map[string]interface{}{
"should": []interface{}{
map[string]interface{}{"match_phrase": map[string]string{"title": "华为手机"}},
map[string]interface{}{"match_phrase": map[string]string{"title": "华为Mate"}},
map[string]interface{}{"match_phrase": map[string]string{"title": "华为Pura"}},
},
"minimum_should_match": 1,
},
}
这样既保住了短语匹配语义，又实现了同义扩展。注意：minimum_should_match: 1 是必须的，否则 ES 默认要求 all should 子句都命中。
遇到“笔记本电脑”和“笔记本”歧义时，优先按词长逆序匹配
用户搜“笔记本电脑”，你不该同时展开“笔记本”+“电脑”的同义词（导致爆炸式组合），而应优先匹配最长可能词项。这是中文分词中经典的“最大正向匹配”思想，在同义词扩展中同样适用。
实现要点：
- 预加载同义词 key 时，按 UTF-8 字符长度倒序排序：
[]string{"笔记本电脑", "笔记本", "电脑"} - 匹配时从最长开始试，一旦命中就停止，不再尝试更短的子串
- 若需支持重叠匹配（如“苹果手机壳”想同时匹配“苹果手机”和“手机壳”），则改用 DAG 分词方式，推荐集成
gojieba的CutAll或自建 AC 自动机 - 注意 Unicode 变体：中文顿号、英文逗号、全角/半角空格都应提前标准化，否则
"笔记本、电脑"和"笔记本,电脑"会被视为两个不同 key
复杂点往往不在扩展本身，而在边界处理——比如用户输入带括号的“iPhone (iOS)”，括号内容是否参与同义匹配？要不要剔除？这些必须结合业务定义清楚，不能靠通用库自动猜。
