京公网安备11010502063487号真实给rn_test建快照后不删原索引，用rename_pattern/rename_replacement把恢复目标改名成restored_test，验证两个索引真实可以并存；再执行同样的改名恢复真实被拒绝因为新名字本身已存在，证明冲突检查针对的是改名后的最终目标名字而非快照记录的原始索引名。
真实搭建2节点1主1副集群，打快照后删除数据，分别直接查主分片和副本节点发现两边都查不到，证明副本对逻辑错误没有保护；用删除前的快照restore后数据完整找回；对照kill掉主分片所在节点，数据立刻能从副本查到不需要restore，勾勒出snapshot和replica分别解决逻辑回滚和物理高可用这两类互补问题。
真实注册一个指向本地目录的snapshot仓库，验证可写时注册和_verify都顺利通过；chmod成只读后_verify和快照尝试都失败，报错精确暴露具体文件路径；查失败快照状态发现404不存在，证明彻底失败的快照不留残留记录；改回可写后新快照立刻成功。
真实对同一个3条文档的小索引调用_cat/indices和_stats，前者只返回246字节摘要表格而后者返回10258字节完整JSON相差约42倍；_stats真实有19个顶层统计分类，search和segments下各有十几个_cat完全没暴露的细分字段；不加过滤的_cat/indices默认隐藏全部系统索引。
真实批量写入2万条文档算出平均每次写入0.0148毫秒；用轻量查询测query_current发现操作太快抓不到非零瞬间，换成重脚本查询后逮到fetch_current变成10；对比发现52次查询query只花360毫秒而fetch花了14758毫秒，揭示判断读写压力不能只看query阶段。
真实查_nodes/stats/jvm基线heap_used_percent是40%，灌数据跑重聚合后涨到41%、young gc多了1次；对比_cat/thread_pool和_nodes/stats/thread_pool查同一个线程池，stats视图多出completed和largest两个诊断字段。
真实验证index.search.slowlog.level这个早期设置在8.15.0上已经失效；把query和fetch的threshold.warn设成0ms后跑一次查询，验证slowlog把query和fetch两个阶段分别独立记录；把indexing的threshold设成0ms写入文档，验证indexing slowlog记下了被写入文档的完整原始内容和精确耗时。
真实把search slowlog的query阈值同时设成warn/info/debug/trace四档，验证234微秒的查询只在TRACE这一个最宽松级别留下1条记录；同样手法验证indexing slowlog一次592微秒的写入也遵循同一套单一级别判定；对比两边字段发现search slowlog真实只多出search_type/total_hits/total_shards这3个字段，核心结构一致。
真实查_nodes/stats/breaker发现6种断路器同时存在，parent断路器单独统计出518.8mb占用而非其他子断路器的简单加总；把request断路器限制压到1kb后跑3万桶聚合真实精确触发circuit_breaking_exception，报错写出想要分配6144字节但限制只有1024字节；tripped计数器确认记录了这次触发，恢复默认限制后聚合立刻重新成功。
真实用Xms=Xmx=1g启动时committed跟max精确相等；改成Xms=512m/Xmx=1g重启后committed只有512MB跟1GB的max对不上，量化了Xms不等于Xmx的真实风险；随后灌数据跑重聚合想撑大堆，committed却稳稳停在512MB没涨，诚实记录这个负面结果说明风险暴露与否取决于实际工作负载。
真实用ps查ES进程RSS是1421MB比1024MB堆上限还大，证明存在off-heap内存；用vmmap查虚拟内存发现VSZ高达469GB，Guard区域虚拟385GB但resident为0；细看mapped file区域发现178.4MB映射只有16.5MB真实resident，列出的具体文件正是本机es-lab数据目录下真实的Lucene段文件。
真实查主力es-lab节点max_file_descriptors是10240；临时搭建节点用ulimit -n 1000压低上限启动后，节点自报值精确变成1000；查启动日志发现WARN级别bootstrap check警告提醒上限太低，但没有阻止节点启动，最终照常达到green，揭示单节点绑定本地场景下是警告而非硬性阻断。