bleve不能直接用作分布式引擎，因其仅为单机嵌入式索引库，缺乏分片、节点发现、远程协议及结果归并等分布式能力，需外层自研调度骨架，bleve仅作为各worker节点的本地引擎。
直接用 bleve 搭分布式架构不现实——它天生是单机嵌入式索引库，没内置分片、协调、节点发现能力。真要索引海量文档，得自己搭骨架，bleve 只能当每个 worker 节点的“本地引擎”。
为什么不能直接把 bleve 当分布式引擎用
bleve 的 Index 实例不支持跨进程共享，也不提供远程查询协议或分片路由逻辑。所谓“分布式”，必须靠外层调度：数据怎么切、请求发给谁、结果怎么合并，全得你写。
-
bleve.Open()只能打开本地磁盘路径，没法连远程节点 - 没有内置一致性哈希或 range 分片机制，文档分配得你自己实现
- 并发写入会 panic：
fatal error: concurrent map read and map write，哪怕加 mutex 也扛不住高吞吐写入 - 查询时若需跨节点聚合（比如 top-k 排序），
bleve.SearchRequest不提供 merge 接口，得手动归并 score 和 docID
worker 节点用 bleve，但必须隔离存储和生命周期
每个 worker 独占一个 bleve.Index 实例，对应独立目录，且必须用绝对路径 + 提前创建。
- 启动时调
os.MkdirAll(filepath.Join("/data", "node-001", "index.bleve"), 0755)，别用"./index" - 已有索引必须用
bleve.Open()，bleve.New()会清空并报invalid index format - 写入必须串行：封装
index.Index()到 channel 或 single-flight 模式，避免 goroutine 直接调用 - 每次批量写完后显式调
index.Close()，否则内存不释放，scorch 引擎可能丢数据
分片策略决定搜索质量，别用简单哈希
按文档 ID 哈希分片（如 docID % N）会导致 AND 查询失效——两个 term 落在不同节点，无法做倒排链交集。
- 推荐按字段值范围分片，比如按
created_at时间戳切天/月，或对user_id做预定义区间（[0, 9999], [10000, 19999]） - 中文场景慎用拼音首字母分片——“张”和“章”同音不同字，但分到不同片，查“zhang”就漏结果
- 分片元信息（如每个节点负责哪些 term 前缀）必须存 etcd 或本地配置文件，不能硬编码
- 查询路由时，
QueryStringQuery("title:go")得先解析出字段和关键词，再判断哪些分片可能含该 term——这步没现成库，得自己实现 term 路由表
结果合并不是简单拼数组
分布式搜索最易被忽略的点：各节点返回的 SearchResult.Hits 是局部 top-k，直接 concat 会丢全局最优结果。
- 必须要求所有 worker 返回足够多的结果（比如 size=100），主节点再按
Score归并取 top-k - 高亮字段（
fragments）不能跨节点复用——每个 worker 只有自己索引里的原始内容，合并时得保留来源节点标识 - facet 统计要二次聚合：各节点返回
TermFacet的 count，主节点 sum 后再排序 - 超时控制得设两层：单个 worker 查询超时（如 200ms），整体请求总超时（如 500ms），后者触发快速失败
真正难的不是写代码连通多个 bleve 实例，而是让分片边界对查询透明、让结果排序不失真、让写入不丢不乱——这些都得自己兜底，bleve 只管好自己那一小块磁盘。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
