用function_score而非boost实现置顶，因boost仅是乘法因子，无法强制某文档排第一；function_score可通过filter+weight硬性干预得分，支持稳定置顶与沉底共存。
为什么用 function_score 而不是 boost 做置顶
因为 boost 只是乘法因子，影响的是整个 query 的 _score，但无法单独控制某类文档“强制排第一”。比如你希望 ID 为 123 的商品永远置顶，哪怕它匹配度低——boost 没法绕过相关性计算，而 function_score 可以用 filter + weight 或 script_score 实现硬性干预。
常见错误是把 should 里加 term 再设 boost，结果发现置顶不稳：Elasticsearch 9.x 后 bool 查询必须显式区分 must/filter/should，should 缺少 minimum_should_match: 1 就可能被忽略。
-
filter里的条件不参与打分、可缓存，适合做置顶/沉底的判定依据（如['term' => ['id' => 123]]） -
weight函数比script_score更轻量，适合简单置顶；需要动态计算（如按时间衰减）才用 script - Laravel 中拼 query body 时，别直接
json_encode($arr)后塞进 HTTP body——确保 key 顺序和空格不影响 DSL 解析，建议用http_build_query或手动构造字符串
怎么写一个稳定置顶 + 沉底共存的 function_score
置顶和沉底本质是 score 的正向/负向偏移。用 functions 数组叠加多个 filter + weight 是最稳妥的方式，避免 script 复杂度和性能开销。
示例：ID=123 置顶（+1000 分），ID in [456,789] 沉底（-500 分），其余走默认 match 相关性：
{
"query": {
"function_score": {
"query": { "match": { "title": "手机" } },
"functions": [
{ "filter": { "term": { "id": 123 } }, "weight": 1000 },
{ "filter": { "terms": { "id": [456, 789] } }, "weight": -500 }
],
"score_mode": "sum",
"boost_mode": "sum"
}
}
}
-
score_mode: "sum"表示各 function 的 score 相加；boost_mode: "sum"表示 function score 和原始 query score 相加 - 沉底用负 weight 是最简方案，但注意不能低于 -2^31（Elasticsearch 底层用 int32 存 score），一般 -1000 以内安全
- 如果置顶规则依赖业务字段（如
is_pinned: true），确保该字段在 mapping 中是"type": "boolean"，且已索引（"index": true）
Laravel 中传参防注入 + 白名单校验怎么做
用户输入直接拼进 function_score 的 filter 会引发 DSL 注入风险，比如传 {"script": "Math.random() > 0.5"} 可能触发任意代码执行（尤其开启 dynamic scripting 时）。
必须做三层过滤：
- 字段名白名单：只允许
id、is_pinned、category_id等已知字段出现在 filter 中 - 值类型强校验：ID 必须是 int，
is_pinned必须是 bool，category_id必须是 int 或 int 数组 - 长度截断：
mb_substr($input, 0, 32)防止超长字符串拖垮集群（ES 单 query body 默认限制 100MB，但实际应控制在 10KB 内）
别信 Laravel 的 request()->validate() 能拦住 DSL 注入——它只校验 PHP 层结构，不校验最终生成的 JSON 是否合法或安全。
排序沉底后为什么分页错乱？
因为 from/size 是基于最终排序结果截取的。如果置顶/沉底改变了文档相对位置，但没同步调整 from 偏移量，第 2 页可能重复出现第 1 页的置顶项。
根本解法只有两个：
- 用
search_after替代from/size：把上一页最后一条的sort值传回来，天然规避 deep pagination 问题 - 置顶/沉底逻辑放在应用层：先查出原始结果（带 ID 列表），再用 PHP 把指定 ID 插到开头/末尾，最后按需 slice —— 适合小数据量（
注意：Elasticsearch 的 track_total_hits: false 在启用 function_score 时可能导致 hits.total.value 不准确，别依赖它做分页总数展示。
