京公网安备11010502063487号本机真实造出三个索引分别是green(不要副本)/yellow(要副本单节点放不下,50%活跃)/red(主分片用allocation.require指向不存在节点,0%活跃)。真实查整个集群_cluster/health，哪怕另外两个索引都健康，整体状态真实照样被拖到red——取的是所有索引里最差的那个，监控应同时按索引维度细分。
本机真实对red索引主分片用allocation/explain诊断，真实查出filter决策器拒绝(分配规则配置错误)。对yellow索引副本同样诊断，真实查出same_shard决策器拒绝(副本不能跟主分片同节点，是拓扑限制不是配置问题)。同样都是unassigned，这个API真实能精确区分出完全不同、可操作的修复方向，不需要靠猜测排查。
本机真实对已经started的分片用allocation/explain，正常返回can_remain_on_current_node:yes和rebalance_explanation。不带请求体且集群健康时真实400报错，懒人模式只对unassigned分片生效。加include_disk_info=true后，响应里的磁盘字节数(free_bytes约27.1GB)真实跟本机df命令精确吻合，证明查询的是实时状态而非估算值。
本机真实用cluster.routing.allocation.exclude排除唯一节点，已有分片真实完全没被赶走依然STARTED，集群green——ES优先保证数据可用不会主动驱逐。同样规则生效期间创建新索引，主分片真实直接unassigned集群变red，explain精确指出filter决策器拒绝。同一条规则对已有数据和新建分片真实表现出完全不同的严格程度。
本机真实配total_shards_per_node=1限制2分片索引，第一个分片STARTED第二个真实直接unassigned集群变red。allocation/explain真实精确指出shards_limit决策器拒绝，报错写出具体限制值。调大限制到2后，两个分片真实立刻都STARTED，不需要任何手动reroute——配置限制放宽后ES自动重新评估解开僵局。
本机磁盘用量长期94%左右，真实验证水位必须满足low≤high≤flood_stage的顺序约束；全新分片撞上high水位直接unassigned，已started的分片水位下调后不被驱逐只加read_only_allow_delete这个block；真实验证这个block连文档删除都拒绝，真正允许的delete是删除整个索引。
本机节点加上node.attr.zone属性后真实对比三种配置：不开awareness副本因same_shard而unassigned；开启非强制awareness.attributes结果跟基线一字不差；开启声明了不存在zone的forced awareness则真实多出awareness决策器，写出具体的配额计算过程，证明forced awareness是硬性限制而非强制awareness只是软性参考。
真实搭建2节点zoneA+1节点zoneB的3节点集群，验证不开awareness时主副本有真实概率被同时分到同一zone，开启非强制awareness.attributes=zone后连续测试全部实现跨区分布，并真实kill掉唯一的zoneB节点模拟可用区下线，验证集群仅降级yellow、全部主分片健在且能正常读写。
真实把cluster.max_shards_per_node调低到10逼近触发边界捕获真实拒绝报错；再用同样5000条文档对比1分片与20分片索引，真实测出20分片版本多用58%磁盘空间，但match_all查询延迟在这个数据量级下真实完全测不出差异。
真实用5万条文档对比1分片和50分片索引性能，过程中发现_bulk的took字段数值异常改用wall-clock计时；测出批量写入50分片因多核并行反而略快，但聚合查询50分片真实比1分片慢超过1倍，揭示过度分片代价集中在查询侧的跨分片合并开销。
本机单节点集群用默认设置建索引，默认1份副本让集群立刻变yellow，allocation/explain确认根因是same_shard；真实验证wait_for_status=green会卡满timeout直接超时，因为这个yellow永远不会自己好；把number_of_replicas改成0后集群立刻恢复green。
真实搭建3节点集群，kill掉主分片所在节点，验证原副本约1秒内被提升为新主分片、集群仅yellow且数据完整可读写；缺失的副本先进入delayed_unassigned等待状态，等满delayed_timeout后才真实被重新分配；宕机节点重新上线后只是作为普通节点加入，不会抢回原主分片身份。