function_score是在保留原始_score基础上叠加业务逻辑加权排序，而非替换默认相关性；若仅用sort则放弃_score计算，导致结果脱离匹配度。
直接用 function_score 干预排序，而不是靠 _score 默认打分——这是最可控、也最常被误用的方式。
为什么不能只改 sort 字段？
ES 里一旦你在 sort 中指定非 _score 字段（比如 price 或 created_at），它就自动放弃相关性计算，_score 全变成 1.0。这意味着：你搜“蓝牙耳机”，结果不是按“匹配程度”排，而是纯按价格或时间排，哪怕某条文档根本没出现“蓝牙”二字也会排上来。
而 function_score 是在保留原始 _score 的基础上，叠加业务逻辑再加权——这才是“干预”，不是“替换”。
- 想让“距离近 + 评分高”的酒店排前面？用
function_score把两者都转成分数再乘起来 - 用户搜“iPhone”，但希望官方旗舰店权重更高？加一个
filter+weight就行 - 价格越接近用户心理预期越靠前？用
gauss函数围绕期望值衰减打分
function_score 的三种常用函数选哪个？
不是所有场景都适合同一种函数：
-
weight：最简单，就是给匹配到的文档统一乘个固定系数。适合“某类商家加权”这种硬规则 -
field_value_factor：拿字段原始值直接参与计算，比如"field_value_factor": {"field": "rating", "factor": 1.5}，适合线性增强（但注意字段不能是keyword） -
gauss/exp/linear：适合带衰减逻辑的场景，比如“距离越远分数越低”“价格偏离越远分数越低”。其中gauss最常用，衰减平滑，参数origin（中心点）、scale（影响范围）、decay（衰减强度）必须配合理解
别直接抄示例里的 scale: "25"——如果字段单位是“元”，那 25 元还说得过去；如果是“万”，就得改成 "25000"，否则所有价格都会被压到几乎一样分。
Laravel 中拼 function_score DSL 容易漏的关键点
PHP 数组嵌套深、键名易错，几个高频翻车位置：
-
"functions"是数组，但里面每个元素必须是对象（PHP 关联数组），不能少一层[]包裹 -
"filter"不是必须的，但如果写了，它必须能独立执行（比如不能写match同时又依赖外层bool的上下文） - 多个函数叠加时，默认是
multiply模式（各函数分相乘），如果想加总，得显式写"score_mode": "sum" - 日期字段参与
gauss打分时，origin必须是 ES 能 parse 的格式，比如"2026-08-01T00:00:00Z"，传 PHPtime()时间戳会报错
示例中常见错误写法："origin" => time() → 正确应为 "origin" => date('c', time())。
性能与调试：别让 function_score 拖垮查询
function_score 是实时计算，每条匹配文档都要跑一遍函数逻辑。以下操作会显著拖慢响应：
- 在
functions里嵌套复杂script（尤其带循环或外部调用） - 对未
doc_values的字段做field_value_factor（ES 会 fallback 到fielddata，内存暴涨） - 用
exp或linear配错offset导致大量文档得分归零，反而让_score主导排序，白忙活
验证是否生效，最直接方法是加 "explain": true 查看返回中的 details 字段——你会看到原始 _score、每个函数输出、最终合成值。没这一步，等于盲调。
真正难的不是写对语法，而是把业务意图准确翻译成函数参数：比如“用户觉得 300 块左右最值”，这个“左右”到底是 ±50 还是 ±150？scale 差三倍，结果可能天差地别。别跳过测试环节，更别信“先上线再调”。
