LoHoSearch 这类本地全文索引库，在电商项目里能承担的任务只有一件：根据商品标题、品牌和规格词，在可控规模下召回商品 ID。价格、库存、排序这些字段最好别塞进搜索索引，留在商品服务里做二次过滤。理解这个边界，方案就能接。

LoHoSearch 适合商品量几千到几万、更新频率不高、查询以标题/品牌/规格关键词为主的电商搜索。实现上先为商品生成搜索文本并建索引，搜索后拿商品 ID 回到数据库补全过滤；库存、价格、排序放第二步做。若需要复杂分面、实时商品池或大规模并发排序，需要重选方案。索引更新方式要先结合本模块版本确认。

先确定商品搜索文本怎么生成

LoHoSearch 索引的是本地文本文件，不是数据库表，也不是直接传 JSON。每个商品对应一个文本文件，文件内容好坏直接决定搜索结果。

商品ID: 10023
标题: 某品牌 无线蓝牙耳机 主动降噪
品牌: 某品牌
品类: 数码影音 耳机
搜索词: 蓝牙 耳机 降噪 无线

这个文本不必包含商品详情页的全部描述，更不要直接抓 HTML。建议只放标题、品牌、品类词以及用于搜索的同义词。文件名按商品 ID 命名，例如 prod_10023.txt，索引返回文件路径时就能反查商品。

建索引与更新节奏

建立索引通常在部署数据库同步任务时做。商品上架、标题修改、品牌变动时，先把商品文本文件写入待索引目录，再调用索引器重建该文件。批量导入场景建议先全量建一次，之后只对变化文件做增量。

my $index = LoHoSearch->new('索引文件目录');
while (my $record = $source->next_product) {
    $index->add_to_index('待索引目录/prod_' . $record->id . '.txt');
}
@results = $index->search('蓝牙耳机');

上面是调用思路，具体方法名和参数需要以你本地安装的模块版本为准。不要假设所有版本的 API 都一致，运行前先打印方法列表或看模块自带的测试脚本。

不建议在用户每次搜索时实时创建索引，也不建议把搜索索引当成商品主数据。出现索引结果比商品库慢一点没关系，但出现不一致时要能通过重建消除。

搜索召回商品 ID，再回数据库补全

LoHoSearch 的搜索结果通常给的是文档路径或文档名，不是完整商品记录。所以查询链路建议分成两段：先解析出商品 ID，再用 ID 批量查询商品服务。

SELECT id, title, price, stock, cover
FROM product
WHERE id IN (10023, 10024, 10021)
  AND status = 1
ORDER BY hot_score DESC
LIMIT 20;

价格区间、库存过滤、上下架状态、销量排序都放在 SQL 或商品服务里做。LoHoSearch 只负责“哪些 ID 可能匹配”，最终展示结果以数据库为准。若商品下架但索引文件未更新，搜索后回表过滤时自然会被排除；这是可以接受的降级。

中文分词和排序边界

LoHoSearch 这类本地索引库，通常不带有成熟的中文分词器。直接索引一整行中文时，用户输入“无线耳机”可能匹配不到“无线蓝牙耳机”里的词。解决办法是在生成商品文本时预先切好词，把用户可能搜索的词放到“搜索词”字段里，而不是让引擎替你分词。

排序方面，不建议把 LoHoSearch 返回的相关度分数直接展示给用户。若同义词和权重没有调过，排序结果不稳定。建议只把它当召回层，排序一律由数据库或者商品中台决定。

还需要确认模块是否支持删除和覆盖。如果不支持，每次变更就直接重新生成全部索引文件，否则会出现旧商品反复出现的现象。

上线前验证清单

• 用真实商品测试“一个完整品牌词”“一个中文片段”“一个同义词”三类搜索，确认结果不空、不混入无关商品。
• 将一些商品下架并重建索引，确认 ID 不再出现在搜索召回结果里。
• 搜索一个商品库中不存在的词，确认搜索服务会走空结果兜底，而不是报 500。
• 记录一次全量重建所需时间，结合你的更新频率确认重建周期是否合理。
• 如果没有兜底逻辑，先加一层从商品标题 LIKE 查询的降级搜索，避免 LoHoSearch 索引异常时用户完全不能用搜索。

LoHoSearch 在电商里的定位是一个低成本召回组件，不是搜索中台。它能解决标题关键词匹配，但解决不了商品运营对分面、排序和实时性的完整需求。接之前先确认数据量、更新频率和回表时间是否符合预期。