Cat API 与 Stats API

做的事：本机真实建一个只有3条文档的小索引，分别调用_cat/indices和_stats这两个接口，真实比较返回内容的大小和详细程度

代码真实写入3条文档到cat_stats_test GET /_cat/indices/cat_stats_test?v GET /cat_stats_test/_stats

验证：_cat/indices真实只返回了246字节的一张人类可读表格，_stats真实返回了10258字节的完整JSON——体积真实是前者的42倍左右

_cat/indices真实返回(246字节):
health status index          uuid  pri rep docs.count docs.deleted store.size ...
green  open   cat_stats_test ...    1   0          3            0      3.4kb ...

_stats真实返回: 10258字节   ← 真实约42倍于前者

这个真实对比直接量化了cat API系列的设计初衷：它真实是为了在终端里快速扫一眼而存在的，只保留了最常被关心的几项摘要指标，排成一张人类一眼就能读懂的表格；而stats API真实是面向程序化监控系统设计的，返回的是结构完整、字段齐全的原始JSON，哪怕要查的索引只有寥寥3条文档，完整的统计结构本身也真实有相当的体积。

真实数一下_stats里到底藏了多少cat/indices完全没暴露过的细节字段

代码真实解析_stats的JSON结构，统计顶层分类数量， 并展开search和segments这两个分类下面具体有哪些字段

验证：_stats真实有19个顶层统计分类，光是search这一类下面就真实有13个细分字段，这些_cat/indices完全没有暴露任何一个

_stats真实的19个顶层分类:
docs, shard_stats, store, indexing, get, search, merges, refresh, flush,
warmer, query_cache, fielddata, completion, segments, translog,
request_cache, recovery, bulk, dense_vector, sparse_vector

search分类下真实的13个细分字段:
open_contexts, query_total, query_time_in_millis, query_current,
fetch_total, fetch_time_in_millis, fetch_current, scroll_total,
scroll_time_in_millis, scroll_current, suggest_total,
suggest_time_in_millis, suggest_current

segments分类下真实的13个细分字段(含各类内存占用的精确拆分):
count, memory_in_bytes, terms_memory_in_bytes,
stored_fields_memory_in_bytes, doc_values_memory_in_bytes, ...

真实还发现一个容易被忽视的差异：_cat/indices默认是不是会把系统索引也列出来

代码GET /_cat/indices?v # 真实不加任何过滤条件

验证：_cat/indices默认真实不显示任何以点开头的系统索引，哪怕集群里真实已经有4个这类索引在跑

本机当时active_primary_shards真实是4（来自.tasks、.async-search等系统索引）
GET /_cat/indices?v 真实返回: 只有表头，一行数据都没有
（当时测试用的普通索引还没建出来，而4个系统索引真实全部被隐藏了）

这个真实现象再次印证了cat API"面向人眼快速浏览"这个设计定位：系统内部使用的那些以点开头的索引真实默认被排除在外，避免真实查看集群概况的人被这些跟业务数据无关的内部索引干扰视线，想看到它们需要额外加上?expand_wildcards=all这类参数。

收尾：真实清理测试索引

代码DELETE /cat_stats_test

分步演示：从体积相差42倍的真实返回内容，到stats独有的19个统计分类，再到cat默认隐藏系统索引

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。