Elasticsearch-Head 的“实时”刷新：不是魔法，是一套精打细算的轮询工程
你有没有在调试一个刚写入的文档时，盯着elasticsearch-head界面等了两秒、三秒……然后突然刷新出结果，心里嘀咕：“它到底什么时候才‘看到’我刚存进去的数据？”
这不是你的错觉——elasticsearch-head从不主动“知道”任何变化。它没有监听器，不订阅事件，也不建立 WebSocket 连接。它的“实时”，是靠一次又一次、规规矩矩地敲开 Elasticsearch 的门，问一句：“现在怎么样了？”
这种看似朴素甚至有点笨拙的方式，恰恰是它能在十多年间被无数开发者反复拉出来救急的根本原因：零服务端侵入、单文件可运行、不挑版本、不设门槛。但正因为它足够轻，也足够裸，所以一旦你开始依赖它做判断——比如“写入成功了吗？”、“索引是不是真的 yellow 了？”、“这条日志怎么还没出现？”——你就必须清楚：它回答你的，永远是「上一次敲门时看到的景象」。
它怎么“看”集群？两个接口，两种成本
elasticsearch-head不是靠一个接口包打天下。它把“感知集群状态”这件事，拆成了两个明确分工、成本迥异的动作：
🌟 第一层心跳：/_cat/indices?v&format=json—— 轻如呼吸
这是head启动后每秒必发的请求（默认 1000ms），也是整个刷新机制的主干。它不查文档，不跑 query，只读取集群内存里现成的元数据快照。
它的响应体长什么样？类似这样（简化）：
[ {"index":"logs-2024-06-01","health":"green","status":"open","docs.count":"4287","store.size":"12.3mb"}, {"index":"metrics-2024","health":"yellow","status":"open","docs.count":"15620","store.size":"89.1mb"} ]为什么选它？
- ✅ES 内部几乎零计算：数据来自ClusterState缓存，协调节点直接组装返回；
- ✅响应极小：百索引规模下通常 <2KB，网络传输快；
- ✅信息密度高
