京公网安备11010502063487号本机真实用routing精确控制，让target全局50条(第一)但每个分片局部只排第21(被20个各15条的噪声词压制)。默认shard_size下，target真实完全消失在结果里，取而代之的是5个只有15条的噪声词。真实把shard_size调到25后，target才正确以50条回到结果第一位，误差归零。
本机真实索引5万条UUID文档(真实唯一值50000)，cardinality默认阈值估算49947(误差-0.11%)，调到precision_threshold=100误差放大到-1.77%，调到40000误差收窄到-0.09%。真实又验证唯一值2000低于默认阈值3000时，cardinality真实返回精确值2000，一个都不差。
本机真实用两条只差2小时的文档(23:30和01:30 UTC)验证date_histogram：不指定时区按UTC分天，真实分进两个不同的天桶各1条；加time_zone:+08:00后，真实两条被重新分进同一个桶doc_count变2——因为按北京时间两者都落在16号这一天，印证了忘记设时区会让统计的'天'跟用户体感自然日对不上。
本机真实索引价格两端密集中间空白的6件商品，histogram(interval=10)真实自动生成11个等宽桶，中间5个真实是空桶(doc_count:0)依然被返回。换成range聚合手工指定4个宽窄不一的区间，真实0个空桶每个都有数据。加min_doc_count:1后histogram桶数从11收缩到6，去掉空桶但会产生跳跃断档。
本机真实索引1000种(cat,sub)组合，用composite聚合size=100配合after_key循环翻页，真实翻了11次(10页满数据+1页空终止)，去重后精确收集到1000条。真实查看after_key结构，精确等于上一页最后一个桶的key。真实确认集群search.max_buckets默认65536，composite用size+after分批规避熔断上限，实现高基数聚合桶的安全完整遍历。
本机真实对4天销售额(100/150/120/200)跑date_histogram+sum，叠加derivative精确算出增量(50/-30/80)，cumulative_sum算出累计总额(100/250/370/570)跟手工验证一致。max_bucket真实定位出销售额最高的01-04(200)。故意写错buckets_path子聚合名，真实400报错精确指出找不到对应聚合。
本机真实对4分类聚合加bucket_script算出total_val=avg*2，用terms.order直接引用它排序真实400报错'Cannot find aggregation named'——terms.order无法引用同级pipeline聚合结果。改用bucket_sort真实成功按total_val精确降序排出b(200)/d(100)/a(40)/c(10)，厘清两者生效时机的本质区别。
本机真实索引alice的3篇和bob的2篇文章，terms分组嵌套top_hits按views降序取size=1，真实精确拿到了各自浏览量最高的文章(500/300)。真实验证top_hits.hits.total精确等于外层桶的doc_count(3/2)，证明排序基于完整的桶内文档集合而非被截断的子集，比collapse更通用能嵌套在任意层级。
本机真实索引5篇文档(3active/2inactive)，query层bool.filter限定status=active，聚合只统计过滤后的a(2)/b(1)。改用filter聚合，query不过滤，真实同一请求里同时拿到overall_by_cat(全部5篇a:3/b:2)和active_only.by_cat(限active的3篇a:2/b:1)——一次请求并存整体与筛选后两份视图，query层filter天然做不到。
本机真实索引5件商品，filters聚合定义重叠条件high_value(price>=100)和is_vip(vip=true)，两桶各统计出2件，加起来4件超过真实满足至少一条件的3件——一件price500且vip=true的商品被同时计入两桶。加other_bucket:true后rest桶精确统计出2件都不满足的商品，证明filters聚合的命名分支真实允许重叠，不像terms强制互斥分组。
本机真实索引2个含nested商品的订单，直接对items.price跑avg聚合真实不报错，静默返回value:null——比报错更危险。真实用nested聚合正确包装后，avg_price精确算出116.67，跟手工(100+200+50)/3吻合；真实发现nested聚合的doc_count统计的是3个子文档总数而非2个父订单数，这个特殊语义容易造成误解。
本机真实建2个问题3个回答的join关系，children聚合默认跨问题拉平统计，avg_score=6.0。真实用parent_id限定到q1，avg_score变7.5(只算q1的2个回答)。真实用has_child查询找出有分数>=10回答的问题，真实只命中q1，排除q2——印证parent-child支持nested不具备的双向关联查询。