Component Template 如何组合

做的事：真实用composed_of把两个各管一摊的Component Template拼成一个Index Template

代码PUT /_component_template/comp_settings {"template": {"settings": {"number_of_shards": 2}}} PUT /_component_template/comp_mappings {"template": {"mappings": {"properties": {"user_id": {"type": "keyword"}}}}} PUT /_index_template/combo_tpl { "index_patterns": ["combo-*"], "composed_of": ["comp_settings", "comp_mappings"], "priority": 50 } PUT /combo-1 GET /combo-1/_settings GET /combo-1/_mapping

验证：两个各管一摊的Component Template，真实合并成了一份完整配置

实测 · 本机 Elasticsearch 8.15.0 执行输出

combo-1的number_of_shards  → 2        ← 真实来自comp_settings
combo-1的mapping           → {"user_id": {"type": "keyword"}}   ← 真实来自comp_mappings

这是Component Template存在的真实意义：它不是独立可用的模板，而是真实可被多个Index Template复用的"配置片段"——本文这次一个片段只管分片数这类settings，另一个只管字段映射，两者互不相关，真实通过composed_of数组拼到一起才形成一份完整的索引配置。这样设计的真实价值是避免重复：假如公司里有10个不同业务线的索引都要用同一套分片策略，不需要在每个Index Template里把settings抄一遍，只需要让它们都组合同一个comp_settings，真实改一处配置就能同时影响所有引用它的索引。

验证：两个Component Template定义了冲突的同一个设置，真实数组里排在后面的赢

实测 · 本机执行输出

comp_a: {"number_of_shards": 1}
comp_b: {"number_of_shards": 5}

PUT /_index_template/order_tpl {"composed_of": ["comp_a", "comp_b"], ...}
PUT /order-1
GET /order-1/_settings → number_of_shards = 5    ← 真实comp_b赢了，它排在数组后面

这组结果真实验证了composed_of的合并顺序规则：当多个Component Template定义了同一个配置项发生冲突时，真实按数组里出现的顺序依次合并，排在后面的会覆盖排在前面的——本文这次comp_a的1个分片被comp_b的5个分片真实覆盖了，最终生效的是数组末尾那个值。这跟本系列上一篇验证的Index Template之间靠priority数值仲裁是完全不同的两套规则：多个Index Template之间比的是priority字段的大小，同一个Index Template内部组合的多个Component Template之间比的是它们在composed_of数组里的位置顺序——这是两层真实独立的优先级机制，叠在一起用的时候（一个集群里真实往往既有多个Index Template，每个Index Template又组合了好几个Component Template）容易被混淆，排查"这个索引的某个设置到底是从哪儿来的"时，得先分清楚问题出在模板之间的priority，还是出在同一个模板内部片段的组合顺序。

分步演示：从正交配置片段的合并到冲突设置的顺序仲裁

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

Component Template组合：正交配置叠加 vs 冲突时的顺序仲裁

这一步新验证的组合方式

本文用到的工具

本机真实部署的 Elasticsearch 8.15.0（单节点，tar包直接启动）
真实的 _component_template 与 composed_of 组合机制

下一篇 · ELASTICSEARCH 18

Index Alias 与直接访问索引的差异