在 LoHoSearch 里碰到无法执行的查询时，先不要急着改写语句。更稳妥的做法是先判断这个查询是真的超出工具能力，还是只是语法或参数写法不对。搜索工具对查询的支持范围通常由三个因素决定：查询语法、索引字段、后端能力。大多数查询拒绝可以靠错误消息或最小化词测试缩小范围：先提交一个只含单个关键词的请求，再逐步增加条件，直到出现失败，最后被加进去的那个条件往往就是问题来源。

LoHoSearch 对查询说不支持时，应先根据报错或最小化词测试判断拒绝原因：语法写错、字段不支持，还是功能超出范围。能简化的就在查询层改；简化不了的在应用层拆解查询并合并结果；功能本身缺失的，需要同步调整索引或查询后端，不能靠无限制堆查询词解决。

先定位：报错、空结果还是部分成功？

把“不支持”分成三种现象，因为处理动作完全不同。如果接口返回明确错误码，通常是参数名、操作符或查询语法不被接受，需要改写查询。如果请求成功但返回空结果，这不算不支持，只是查询条件没有命中数据。如果请求在复杂组合下超时或只返回部分结果，说明查询本身可能被接受，但计算代价过高，需要降低复杂度。

把查询简化到工具支持的范围

很多“不支持”其实是写法超出了接口语法。常见做法：将嵌套布尔表达式改写成多条简单查询；去掉工具不支持的通配符或前缀匹配；把对多个字段的联合搜索改成单字段过滤。以空格分隔多个词在很多搜索引擎中默认按 AND 处理，可以先只用空格，比硬写 AND 和括号更稳。

验证方式用逐段添加条件。例如“中文分词 配置 报错”查询失败，先试“中文分词”，成功后改成“中文分词 配置”，再改成完整查询。如果失败点总在某个词上，就可以认为问题出在这个词或它所在的字段上，换词或换字段过滤比调语法更快。

风险边界：简化查询会改变排序和相关性，不要期望得到和复杂查询完全一致的结果。

在应用层拆解查询并合并结果

当查询本身确实超出接口能力，可以考虑让应用层做“小查询 + 合并”：对每个关键词分别执行搜索，在代码中合并结果、去重和排序。这只适合不需要严格相关性的场景，例如按标签检索、用 id 列表做并集。

# 通用示意：以你实际部署环境的接口为准，不要直接照搬
def split_search(base_url, terms, limit=20):
    seen = {}
    for term in terms:
        resp = request("GET", base_url, params={"q": term, "limit": limit})
        for item in parse_items(resp):
            doc_id = item["id"]
            if doc_id not in seen:
                seen[doc_id] = item
    return list(seen.values())

这个骨架中，返回顺序取决于请求次序，不代表服务端相关性排序。如果你需要按时间或权重排序，要在合并后自己排序。分页也同理，每个子查询都要取足量结果，否则翻页时可能漏数据。

风险边界：这类拆分合并方案不能获得复杂查询的语义相关性，也不能替代服务端排序；拆分合并只是绕过不支持查询的止血措施，不是性能提升方案。后续仍需要评估是否调整索引字段或查询后端。

确认边界并考虑后端调整

当多次测试都指向同一个能力缺失，比如某个字段根本没有建立索引、接口不支持某些操作符，就该考虑后端调整。可能的路径包括：在索引阶段把需要检索的字段补齐；用过滤器或范围参数替代全文查询；或更换更适合的查询后端。这些改动需要结合当前部署的 LoHoSearch 版本、索引配置和数据规模来评估，影响范围通常不在查询层。

风险：直接换后端是架构变更，需要重新验证索引构建、查询结果和一致性，不能只看单条查询是否返回。

常见问题

怎么区分“不支持”和“没有结果”？

看请求是否成功。接口不报错、返回空数组，一般是条件无命中；报错或返回错误提示才属于“不支持”。如果不确定，去掉一个条件再请求一次，若结果出现，说明原条件的某个词或字段有问题。

报错信息不明确怎么办？

先验证最简单的查询是否可用，再从简单查询逐步加入条件，定位失败点。前提是保留请求日志，至少能看到完整查询串和返回状态。

把查询拆开后结果顺序变了，能恢复吗？

通常不能和原来的排序完全一致，因为服务端没有参与整体排序。只能在合并后按自己的字段重新排序，但相关性逻辑需要自己处理。