京公网安备11010502063487号本机真实索引6件商品(3色各2件)，query的bool filter限定color=red：聚合桶真实也跟着只剩red。换成post_filter限定同样条件：返回文档真实仍只有2件red，但聚合桶真实blue/green/red三色都在各2件——post_filter真实完全不影响聚合，只收窄最终展示结果，正是电商按颜色筛选分面搜索的真实需求。
本机真实搜'elasticsearch performance'不设min_score命中3篇(得分1.63/0.41/0.31)，加min_score=0.5后只剩1.63那篇，hits.total精确收窄为1。真实验证min_score也会收窄聚合桶，这跟上一篇post_filter不影响聚合的结论形成直接对照——min_score在聚合之前生效，post_filter在聚合之后生效。
本机真实索引3位作者共6篇文章，不加collapse返回全部6条，加collapse(author)后真实每位作者只剩1条但hits.total依然是6。真实对text字段用collapse直接报错不支持，只能用keyword等doc_values字段。真实搭配inner_hits把每组折叠掉的次优文章重新取回来。
本机真实搜'quick'，基础排序词频高的文档排第一(0.167)。加rescore用match_phrase加权5倍、window_size=10覆盖全部时，排名真实翻转，短语匹配更精确的文档反超排第一(1.405)。真实把window_size收窄到1后，排名完全没翻转——第二名没被纳入窗口，哪怕按rescore_query分数更高也没有翻身机会。
本机真实配两条function_score规则(featured权重2、on_sale权重3)，score_mode=sum时同时满足两条件的文档得分真实2+3=5.0精确累加。换成score_mode=max后，同样的文档得分真实变成3.0，跟只满足一个条件的文档完全一样——真实丢失了双重命中这个信息。boost_mode=replace下未命中任何规则的文档真实退化成中性值1.0。
本机真实对10万条文档测script_score，便宜脚本稳定6-10ms，昂贵的1000次sqrt循环脚本真实飙到1358-1445ms，差约150倍。真实用200个源码各不相同的内联脚本连续查询，第151个真实触发编译限制报错'max:[150/5m]'。改成params参数化脚本后200次真实全部成功，一次编译限制都没触发。
本机真实配runtime field(price_dollars由price_cents实时计算)，range查询真实耗时12-32ms，等价的真正索引字段range查询只要0-2ms，差10到20倍。真实验证精确命中数两边完全一致(10001)，证明runtime field不是牺牲正确性换速度，纯粹是写入零成本和查询开销之间的权衡。
本机真实对30万条文档的聚合查询反复请求，默认request cache稳定0ms，关闭后变1-3ms，_stats精确记录hit_count=3。真实最意外的发现：同一个term过滤条件连续用了40多次，query_cache的hit_count真实始终是0——证明query cache依赖Lucene自适应策略判断是否值得缓存，不是用了就一定缓存，不像request cache那样确定性命中。
本机真实构造bool.filter查询混合便宜的status精确匹配和昂贵的开头通配符code匹配，总耗时2-28ms。用profile:true拆解，TermQuery(status)真实只用93583纳秒，MultiTermQueryConstantScoreBlendedWrapper(code通配符)真实吃掉3003456纳秒，占94%以上——精确定位出真正的性能瓶颈。
本机真实对比20条独立查询：挨个发起总耗时18.07ms，每条服务端执行都是0ms；打包成1次_msearch只要6.42ms，快约2.8倍，省下的全是HTTP往返开销。真实验证错误隔离：3条查询里塞1条写错类型的range查询，真实只有那一条报错，前后两条正常返回完全不受影响。
本机真实提交对5万条文档跑2000次sqrt循环的昂贵查询到_async_search，只等1ms真实拿到is_running:true和id，查询在后台继续跑。1秒后轮询真实is_running变false，结果已算好。真实删除后再查同一个id，直接404 resource_not_found_exception，证明结果是有生命周期需显式管理的服务端资源。
本机真实对昂贵script_score查询设timeout=1ms，真实timed_out:true但took实际190ms远超设定预算，timeout在检查点才生效而非瞬时截止，返回的是已算出的部分结果。真实用_tasks找到正在跑的查询task id并_cancel，任务状态变cancelled:true，客户端真实收到400 task_cancelled_exception——这才是真正彻底的中途终止。