hydra 不支持直接通过 yaml 覆盖列表中字典元素的特定键（如 `key_a.0.entry_a_1`），因其底层使用 `omegaconf.merge()` 进行配置合并，而列表会被整体替换而非深度合并。推荐方案是将列表重构为键值对字典，并借助 `oc.dict.values` 动态转为列表。
在 Hydra 配置系统中，列表（ListConfig）本质上是不可“部分覆盖”的结构。当你尝试用 key_a.0.entry_a_1: YYYY 语法在 outer.yaml 中覆盖 inner.yaml 的某个列表项字段时，Hydra 会静默忽略该覆写——因为 OmegaConf.merge() 对列表执行的是整项替换（shallow replace），而非递归合并字典字段。
✅ 正确且推荐的解决方案：将列表改为命名字典（DictConfig）
以你的原始 inner.yaml 为例：
# inner.yaml
key_a:
item1:
entry_a_1: xxxx
entry_a_2: xxxxx
item2:
entry_a_3: xxxx
entry_a_4: xxxxx此时，你可在 outer.yaml 中精准覆盖任意字段：
# outer.yaml
defaults:
- inner_config@key_a: inner # 将 inner.yaml 的 key_a 注入为顶层 key_a
key_a:
item1:
entry_a_1: YYYY # ✅ 成功覆盖！语义清晰、完全支持若业务逻辑仍需以列表形式访问（例如 for item in cfg.key_a），可借助 OmegaConf 内置解析器 oc.dict.values 实现动态转换：
# config.yaml（主配置）
defaults:
- inner
key_a_dict: # 保持字典结构用于覆盖
item1:
entry_a_1: xxxx
entry_a_2: xxxxx
item2:
entry_a_3: xxxx
entry_a_4: xxxxx
key_a: "${oc.dict.values: key_a_dict}" # 运行时自动展开为 ListConfig这样，cfg.key_a 在解析后即为标准 Python 列表行为（[{"entry_a_1": "xxxx", ...}, {...}]），同时保留了 YAML 层面的可维护性与覆盖能力。
? 补充技巧：结合 Hydra Config Groups 实现模块化
对于更复杂的场景（如多个可插拔组件），建议拆分为 config group：
conf/
├── objects/
│ ├── obj1.yaml # obj1: {_target_: ...}
│ └── obj2.yaml # obj2: {_target_: ...}
└── config.yamlconfig.yaml：
defaults:
- objects: [obj1, obj2] # 自动加载为 dict
main:
_target_: __main__.Main
objects: "${oc.dict.values: objects}" # 安全转为列表传入⚠️ 注意事项：
- 避免在 defaults 中使用 @ 语法试图“重定位”列表（如 inner_config@outer_inner_config），该语法仅适用于 config group 映射，不改变数据结构语义；
- 所有 oc.* 解析器均在 resolve=True 或 instantiate() 时触发，确保调用链中启用解析（如 OmegaConf.to_yaml(cfg, resolve=True)）；
- 若必须保留原始列表格式（如第三方库强依赖 ListConfig 索引），唯一替代方案是改用 Python 预处理脚本动态 patch，但会丧失 Hydra 的声明式优势。
综上，“字典 + oc.dict.values” 是 Hydra 生态中兼顾可覆盖性、可读性与运行时灵活性的最佳实践，既规避了列表合并限制，又无需侵入业务代码逻辑。
