京公网安备11010502063487号本机真实让两个update_by_query并发抢同一批文档，用严丝合缝互补的updated/version_conflicts数字证明它底层是逐条乐观并发写回。
本机真实验证delete_by_query精确删除匹配文档，wait_for_completion=false的异步任务模式，以及_tasks API里真实支持的任务取消能力。
本机真实验证integer改long这种看似安全的类型扩容依然被拒绝，但新增字段、追加多字段、调整ignore_above等参数都是被允许的增量修改。
本机真实用_analyze的explain:true逐级打印char_filter/tokenizer/token_filter的完整输出，验证停用词删除后position留空位而不紧凑重排的真实设计。
本机真实对比有无html_strip char_filter时HTML文本的分词结果差异，并证明tokenizer参数结构上只接受单值，跟可叠加的char_filter/token_filter角色不同。
本机真实用同一句'Hello-World, ES 8.15 is running_fast!'分别喂给standard、whitespace、keyword三种tokenizer：standard真实按Unicode词边界切成6个干净单词；whitespace真实只认空格，标点原样粘连；keyword真实整句不分词。真实又建了三个字段做词项聚合，三组桶的数量差异直接量化了选错tokenizer的后果。
本机真实验证ES默认standard分词器对中文完全不做词语切分，逐字拆成单字token；真实装上analysis-smartcn插件重启后切出词语级别结果。真实用检索实验量化后果：standard下查询'北京天气'真实把无关的'南京路边小吃'当命中返回了，换smartcn后真实被正确排除。
本机真实搭建edge_ngram自定义analyzer做自动补全：'Elastic'真实被切成el/ela/elas一路到elastic共6个前缀片段。真实验证写入用edge_ngram、查询用standard的正确配置能让'elas'命中相关文档；真实又验证两边都用edge_ngram的常见误用——搜'stick'真实命中了毫不相关的'Elastic Stack'，因为st这个前缀片段两边共享。
本机真实用_validate/query的explain模式打印出match查询'QUICK fox'底层真实生成的body:quick body:fox两个词项查询。真实验证operator参数(and/or默认)如何组合这些词项，又验证keyword字段没有analyzer可跑，match在它上面真实退化成大小写敏感的精确比对。
本机真实用explain对比term和match查询：match把'QUICK fox'分析成小写body:quick body:fox，term查body字段的'Quick'真实原样保留大写一个字母没变。真实验证后果：term搜大写Quick在text字段上查不到(0命中)，必须搜索引里真实存的小写quick才行；而在keyword字段上term才是真实设计初衷，精确比对存储值。
本机真实验证match_phrase的slop：紧挨着的quick brown不需要slop直接命中；隔1词的quick fox slop=0查不到slop=1才命中。真实最意外的发现：反转顺序搜fox quick，同样隔1词，slop=2依然查不到，要slop=3才行——词序颠倒真实的代价远超单纯间隔数的直觉估算。
本机真实对比同样的status:active条件放must里(doc1得分1.04)和放filter里(doc1得分降到0.57)。真实用_explain拆开打分明细，filter版本的sum of里只剩title:quick一项，status条件完全没参与打分。真实又验证must_not排除逻辑，以及should单独使用时真实表现成OR语义。