must_not 在 ES 9.x 中不等价于 SQL 的 NOT IN，因其对缺失字段返回 true 导致意外包含，且不支持集合级排除；安全做法是用 ids 查询或应用层差集。
ES 9.x 中 must_not 不等于 SQL 的 NOT IN
直接说结论：must_not 在 Elasticsearch 9.x 中不是“排除指定 ID 列表”的安全方式，尤其当配合 match 或 multi_match 使用时，极易因空值、缺失字段或布尔逻辑导致结果意外为空或漏匹配。它本质是“对每个文档单独执行否定判断”，而非集合层面的反向筛选。
-
must_not对term查询生效的前提是目标字段存在且非空；若文档缺失该字段，must_not条件自动为 true，该文档被纳入结果——这和预期“排除”完全相反 - 想实现类似 SQL
WHERE id NOT IN (1,2,3)，必须用bool/filter/should + bool/must_not套嵌，或改用terms_set+ 脚本（不推荐） - 更稳妥的做法是：把“要排除的 ID 列表”转成
terms放进filter，再用外层bool/must包裹主查询，靠应用层做差集（如先查出要排除的 doc_id，再在主查询中用idsfilter 排除）
用 filter + should 实现安全的“排除多个 term”
当你要筛掉一批已知 ID、状态或类目，且这些值确定存在、非空，优先走 filter + should 组合，避免 must_not 的语义陷阱。
- 例如排除商品 ID 为 [101, 205, 307] 的记录：
{ "query": { "bool": { "must": [{ "match": { "title": "手机" } }], "filter": [{ "bool": { "should": [ { "term": { "id": 101 } }, { "term": { "id": 205 } }, { "term": { "id": 307 } } ], "minimum_should_match": 0, "must_not": [{ "exists": { "field": "id" } }] } }] } } }❌ 这样写是错的——must_not + exists会把所有含id字段的文档都干掉 - 正确做法是：先用一次查询拿到要排除的 ID 集合，再在主查中用
idsfilter：$excludedIds = [101, 205, 307];['ids' => ['values' => $excludedIds]]放进外层bool/filter的must_not——但注意：只有ids查询本身支持这种“集合排除”，普通term不行 - 如果必须单次请求完成，用
script查询（仅限调试）："script": { "script": "doc['id'].value != params.except[0] && doc['id'].value != params.except[1]" }——但禁止用户可控参数进 script，有 RCE 风险
Laravel 客户端里怎么写才不出错
别在 Laravel 里拼 raw DSL 写 must_not，尤其别从 request 直接取数组塞进 must_not/terms。Elasticsearch 客户端（如 elasticsearch/elasticsearch）不校验字段是否存在，出错只报 parse_exception 或静默丢数据。
- 先校验输入：
$excluded = collect($request->input('exclude_ids', []))->filter()->map('intval')->unique()->values()->all();，空数组或非法值直接跳过整个排除逻辑 - 排除逻辑只作用于 keyword 类型字段（如
status、category_id），别对text字段用term；对id这种数值字段，确保 mapping 是long或keyword，不是text - 用
ids查询最省事：['ids' => ['values' => $excluded]]放进bool/filter/must_not——这是 ES 原生支持的集合排除，语义清晰、性能好、无空字段干扰 - 如果用 Scout，
whereNotIn()底层未必生成ids，可能退化成多个must_not/term，务必看生成的 DSL 日志确认
为什么不能依赖 must_not 做业务级“非”逻辑
must_not 的底层是 Lucene 的 BooleanQuery，它不参与评分，但会影响文档是否被纳入结果集——而它的触发条件极度依赖字段存在性、类型一致性、分词结果。一个 must_not 条件写错，整页搜索结果可能全空，且无明确报错。
- 比如对
tags字段（text类型）写must_not/term，实际查的是分词后的 token，不是原始数组值；想排除["vip", "hot"]，得用must_not/terms+tags.keyword - 对
price字段写must_not/range，若某文档 price 为 null，该文档会被包含进来——因为 range 查询对 null 返回 false，must_not false === true - 真正需要“非”语义的业务场景（如“非 VIP 用户”、“非上架商品”），应把正向条件建模为独立字段（如
is_vip: bool），然后用filter/term查false，而不是靠must_not反推
实际项目里，must_not 最适合用在“字段存在性否定”（如 exists 反向）或极简等值排除（单个 term），一旦涉及多值、范围、全文字段或用户输入，就得绕开它，用 ids、应用层差集或重构正向模型。这点很容易被忽略，直到线上搜索突然返回空结果才去翻日志。
