es 9.x 中 must 用于影响评分的全文检索，filter 用于不评分且可缓存的确定性条件（如上架状态、类目 id），混用会导致评分失真和缓存失效；中文模糊匹配应优先用 ngram 分词器配合 match 查询，避免直接使用 fuzzy；wildcard 查询须限制为前缀匹配（如 abc*），禁用无前缀形式；laravel 中需白名单校验参数并截断搜索字符串长度。
bool 查询里 must 和 filter 别混用
ES 9.x 强制要求 bool 查询必须显式区分 must（影响评分）、filter（不评分、可缓存）和 should（需设 minimum_should_match）。商品搜索里，上架状态、类目 ID、价格区间这些确定性条件必须放 filter；全文关键词匹配（比如用户搜“无线耳机”）才放 must 里的 multi_match 或 query_string。混进 must 会导致评分失真，且 filter 缓存失效。
中文模糊匹配别直接用 fuzzy query
fuzzy 查询在中文场景下效果差——单字编辑距离计算不符合业务语义，还容易把“苹果”匹配成“平果”“频果”。更稳的方案是：对标题、描述等字段启用 ngram 分词器，配合 match 或 match_phrase 实现子串召回。例如配置 min_gram: 2、max_gram: 3，就能让“蓝牙耳机”拆出 “蓝”“蓝牙”“牙耳”“耳机”等 token，查“耳”或“蓝牙”都能命中。
- 避免在生产环境对 text 字段直接用
fuzzy，尤其当字段未做分词优化时 - 若必须用 fuzzy，加
prefix_length: 2锁定前两个字不变，防过度膨胀 -
max_expansions建议设为20以内，防止生成海量变体拖垮协调节点
wildcard 查询要限制前缀长度
wildcard 看似简单，但 *abc 或 ?bc 这类无前缀的写法会触发全索引扫描，线上极易超时。安全用法是只允许前缀匹配，比如 abc* —— Lucene 能利用倒排索引快速定位，而 *bc 得遍历所有 term。
- 后端接收参数后，先用正则校验是否以字母/数字开头，拒绝
^[\*\?].*类输入 - 字段映射类型建议用
wildcard（ES 7.9+），比 text + wildcard query 更高效 - 不要在高并发接口中对未建索引的字段用 wildcard，响应时间可能从 20ms 涨到 2s+
Laravel 里参数校验不能只靠前端
用户传来的 q、category_id、price_min 等参数，必须在 Laravel 控制器里白名单过滤。ES 不校验字段是否存在，term 查一个不存在的字段会静默返回空结果；恶意构造的 script 或深度嵌套查询还可能触发熔断。
- 用
request()->validate()限定字段类型和范围，比如'price_min' => 'nullable|numeric|min:0' - 字符串类搜索参数（如
q）要做 trim + 长度截断（建议 ≤ 50 字符），防 DOS - 类目路径这类树形字段，优先用
prefix查询category_path，而不是让用户输任意 path 后拼 DSL
minimum_should_match —— 只要 bool 查询里用了 should，就必须显式设这个值，否则默认为 0，整个查询可能直接不生效。
