Hydra 源码深度解析：配置管理与实验调度机制

1. 为什么值得花时间读 Hydra 的源码

第一次接触 Hydra 是在一个多模型训练项目里。当时项目有十几个实验分支，每个分支的模型结构、数据集、优化器参数都不一样，团队里每个人维护一套自己的config.yaml，合并代码时冲突不断，跑实验时经常出现"我本地能跑，你那边报错"的情况。后来有人引入了 Hydra，配置冲突的问题一下子少了大半。但用着用着就发现，光会用@hydra.main装饰器远远不够——当配置需要动态组合、当实验要批量调度、当输出目录需要精细控制时，不理解它的内部机制就会处处碰壁。

这篇内容就是把我读 Hydra 源码的过程和结论整理出来。Hydra 是 Meta（原 Facebook）开源的一个 Python 配置管理与实验调度框架，核心解决的是"复杂项目里配置爆炸"和"实验批量运行"这两个问题。它适合已经用过 Hydra 基础功能、想进一步搞懂它内部怎么运转的开发者，也适合正在做实验管理平台选型、需要评估 Hydra 是否值得引入的技术负责人。我不会只讲 API 怎么调，而是会拆到源码层面，讲清楚 ConfigStore、Composition、JobRuntime 这些核心组件到底怎么协作，以及在实际项目里怎么用这些知识解决具体问题。

读源码这件事，很多人觉得是"屠龙术"，但 Hydra 是个例外。它的代码结构清晰，模块职责分明，读完之后你对"配置驱动"这种编程范式的理解会上一个台阶。下面我按自己的阅读顺序，从整体架构到核心模块逐个拆解。

2. Hydra 的整体架构与模块分层

2.1 从一次@hydra.main调用看执行链路

要理解 Hydra 的架构，最直接的方式是跟踪一次完整的调用。当你在代码里写下：

import hydra @hydra.main(config_path="conf", config_name="config") def main(cfg): print(cfg)

这行装饰器背后发生了一连串事情。hydra.main本身是一个装饰器工厂，它返回的装饰器会包装你的main函数。当 Python 执行到被装饰的函数时，Hydra 会先初始化一个Hydra对象（位于hydra/_internal/hydra.py），这个对象负责整个生命周期管理。

初始化阶段，Hydra 会做几件事：解析命令行参数、创建 ConfigLoader、加载主配置、执行配置组合、设置输出目录、配置日志系统。这些步骤在Hydra.run()方法里按顺序执行。我读源码时画过一张调用链，大致是：

hydra.main -> _run_hydra -> Hydra.create_main_hydra2 -> Hydra.run -> ConfigLoader.load_configuration -> ConfigRepository.load_config -> ConfigLoaderImpl._compose_config -> JobRuntime -> run_job

这条链路里，ConfigLoaderImpl._compose_config是最核心的一步，它负责把主配置和所有 defaults list 里引用的配置合并成最终的DictConfig。理解这条链路之后，很多"为什么配置没生效""为什么 defaults 顺序会影响结果"的问题就迎刃而解了。

2.2 核心模块的职责边界

Hydra 的源码目录结构本身就反映了它的架构设计。hydra/_internal/下放着所有核心实现，hydra/core/下是配置相关的数据结构，hydra/plugins/是插件体系。我整理了一张模块职责表：

这个分层里，ConfigRepository负责"找到配置文件"，ConfigLoaderImpl负责"把配置组合起来"，ConfigStore负责"管理配置的注册和查询"。三者职责清晰，但协作紧密。比如当你在 defaults list 里写- db: mysql，ConfigLoaderImpl会去ConfigStore里查db/mysql这个配置组，而ConfigStore的数据来源是ConfigRepository扫描配置目录的结果。

2.3 配置组合的优先级规则

Hydra 配置组合的优先级是很多人容易搞混的地方。源码里ConfigLoaderImpl._compose_config的实现揭示了完整规则。简单说，优先级从低到高是：

1. 主配置的顶层字段
2. defaults list 中靠前的配置
3. defaults list 中靠后的配置
4. 命令行 override

但这里有个细节：defaults list 里的配置是按顺序合并的，后面的会覆盖前面的同名字段。而_self_的位置决定了主配置自身字段相对于 defaults 的优先级。如果你在 defaults list 里写- _self_放在最前面，那主配置的字段优先级最低；放在最后面，优先级最高。这个机制在源码里是通过_self_在 defaults list 中的索引位置来控制的。

我踩过一个坑：主配置里定义了lr: 0.001，defaults 里引用的optimizer/adam也定义了lr: 0.0001，结果最终生效的是0.0001，因为默认情况下_self_在 defaults 之后。要改这个行为，就得显式调整_self_的位置。这个知识点在官方文档里讲得比较简略，但源码里_compose_config的合并逻辑写得很清楚。

3. ConfigStore 与配置发现机制

3.1 ConfigStore 的注册与查询逻辑

ConfigStore是 Hydra 的全局配置注册中心，位于hydra/core/config_store.py。它的核心数据结构是一个嵌套字典，按配置组名和配置名组织。当你调用ConfigStore.instance().store(name="db/mysql", node={...})时，实际上是在这个嵌套字典里插入了一个节点。

源码里ConfigStore.store方法的签名是：

def store(self, name: str, node: Any, group: Optional[str] = None, package: Optional[str] = None) -> None:

name参数支持用/分隔的路径，比如db/mysql会被解析成 group=db，name=mysql。如果显式传了group参数，则以group为准。这个设计让配置的注册非常灵活——你可以在代码里动态注册配置，也可以从文件系统加载。

查询时，ConfigStore.load方法会根据 group 和 name 去嵌套字典里查找。如果找不到，会抛出MissingConfigException。这里有个细节：ConfigStore支持"配置组默认值"，也就是当 defaults list 里只写了- db而没指定具体配置时，会去找db组下的默认配置。这个默认配置是通过ConfigStore.set_default设置的，源码里对应_defaults字典。

3.2 配置文件扫描与 ConfigRepository

ConfigRepository负责从文件系统发现配置。它的初始化接收一个ConfigSearchPath，里面包含多个搜索路径。每个搜索路径有一个provider和path，provider 通常是hydra或main，分别代表 Hydra 内置配置和用户项目配置。

扫描逻辑在ConfigRepository.load_config里。它会遍历搜索路径，用_create_config_search_path生成候选路径，然后尝试读取文件。支持的文件格式包括.yaml、.yml、.json。读取后会用 OmegaConf 解析成DictConfig。

这里有个值得注意的设计：ConfigRepository会缓存已加载的配置。缓存键是配置的完整路径。这个缓存在同一个 Hydra 运行周期内有效，跨运行不共享。如果你在代码里动态修改了配置文件，需要清缓存才能生效。我在调试配置问题时，经常因为缓存导致改了文件没生效，后来养成了在调试时加--cfg job打印最终配置的习惯。

3.3 配置组的默认值与覆盖

配置组的默认值机制是 Hydra 配置管理的一个亮点。假设你有这样的目录结构：

conf/ db/ mysql.yaml postgresql.yaml config.yaml

在config.yaml的 defaults list 里写- db: mysql，就会加载db/mysql.yaml。如果写- db，则会去找db组的默认配置。默认配置的设置方式有两种：一是在db目录下放一个default.yaml，二是在 defaults list 里用- db: default显式指定。

源码里这个逻辑在ConfigLoaderImpl._load_defaults_list和_process_defaults_list里。它会先解析 defaults list 的每一项，判断是 group default 还是 package default，然后递归加载。递归过程中会维护一个"已加载配置"的集合，避免循环引用。如果检测到循环，会抛出ConfigCompositionException。

我在实际项目里用配置组管理不同环境的配置，比如env/dev.yaml、env/prod.yaml，然后在 defaults list 里写- env: dev。切换环境时只需要改一个地方，非常方便。但要注意，配置组的默认值只在 defaults list 里没显式指定时生效，命令行 override 的优先级最高。

4. defaults list 的解析与组合算法

4.1 defaults list 的语法与语义

defaults list 是 Hydra 配置组合的核心机制。它的语法看起来简单，但语义层次很丰富。一个典型的 defaults list：

defaults: - base_config - db: mysql - _self_ - override hydra/launcher: basic

每一项的含义不同。- base_config是引用一个同级的配置文件；- db: mysql是引用db组下的mysql配置；- _self_是占位符，标记主配置自身字段的位置；- override hydra/launcher: basic是覆盖 Hydra 内置配置。

源码里这些项被解析成不同的DefaultElement子类。GroupDefault对应db: mysql这种带组名的；PackageDefault对应base_config这种不带组名的；SelfDefault对应_self_；OverrideDefault对应override开头的。每种类型的处理逻辑在_process_defaults_list里分支处理。

4.2 组合顺序与覆盖规则

组合顺序是 defaults list 最容易出错的地方。源码里_compose_config的实现逻辑是：按 defaults list 的顺序依次加载配置，后加载的覆盖先加载的。_self_的位置决定了主配置字段在合并序列中的位置。

举个例子，假设 defaults list 是：

defaults: - db: mysql - _self_ - db: postgresql

这里db被引用了两次，最终生效的是postgresql，因为它排在后面。而_self_在中间，意味着主配置的字段会覆盖mysql的字段，但会被postgresql覆盖。这种"后覆盖前"的规则和 CSS 的层叠逻辑很像。

但有个特殊情况：如果两个配置引用了同一个组的不同配置，Hydra 会报错，除非用override关键字。比如上面的例子，如果不加override，Hydra 会提示"db 组被多次引用"。要允许覆盖，得写成- override db: postgresql。这个设计是为了防止意外的配置覆盖，但在需要显式覆盖时又提供了出口。

4.3 递归组合与循环检测

配置组合是递归进行的。当db/mysql.yaml自己也有 defaults list 时，Hydra 会递归加载它的 defaults。这个递归过程在_compose_config里通过栈来管理。每进入一层，就把当前配置的 defaults list 压栈，处理完再弹栈。

循环检测靠一个visited集合。每次加载一个配置，就把它的标识（group + name）加入集合。如果发现已经在集合里，就抛出异常。这个机制防止了 A 引用 B、B 又引用 A 的死循环。

我在一个项目里遇到过循环引用：base.yaml的 defaults 里引用了model.yaml，而model.yaml的 defaults 里又引用了base.yaml。Hydra 报的错很明确，指出了循环路径。解决方法是把公共部分抽出来放到第三个文件里，两边都引用它，避免互相引用。

4.4 命令行 override 的解析与合并

命令行 override 的解析在hydra/core/override_parser/下。OverridesParser会把db=postgresql这样的字符串解析成Override对象，包含 key、value、操作类型等信息。支持的操作包括赋值=、追加+=、删除~等。

合并时，override 的优先级最高，会覆盖配置组合的结果。源码里ConfigLoaderImpl._apply_overrides_to_config负责这一步。它遍历所有 override，用 OmegaConf 的update或merge方法应用到配置上。

这里有个细节：override 的 key 支持点号路径，比如db.host=localhost会修改db下的host字段。如果路径不存在，默认会报错，除非用+db.host=localhost显式表示新增。这个设计避免了拼写错误导致的静默失败。我在实际使用中，经常用+来添加临时字段，用~来删除不需要的字段，比改配置文件灵活得多。

5. JobRuntime 与实验调度机制

5.1 JobRuntime 的职责与生命周期

JobRuntime是 Hydra 管理单次任务运行的组件，位于hydra/core/utils.py。它负责设置工作目录、管理输出目录、配置日志、执行用户函数、处理异常。每次@hydra.main装饰的函数被调用，都会创建一个JobRuntime实例。

生命周期大致是：__enter__时创建输出目录、切换工作目录、配置日志；执行用户函数；__exit__时恢复原工作目录、清理资源。输出目录的命名规则是outputs/日期/时间，可以通过hydra.run.dir配置修改。

源码里JobRuntime的__enter__方法做了几件关键事：调用_create_output_dir创建目录，调用_chdir切换工作目录，调用_configure_log配置日志。_chdir的实现是保存当前目录，然后os.chdir到输出目录。这意味着你的代码里所有相对路径都是相对于输出目录的，而不是原始工作目录。这个行为经常让新手困惑——为什么读不到同级的配置文件？因为工作目录已经变了。

5.2 输出目录管理与日志配置

输出目录的管理是 Hydra 实验调度能力的基础。每次运行都会生成独立的输出目录，目录名包含时间戳，避免覆盖。目录结构默认是：

outputs/ 2024-01-15/ 14-30-25/ .hydra/ config.yaml hydra.yaml overrides.yaml main.log

.hydra目录下保存了本次运行的完整配置信息，包括最终组合的配置、Hydra 自身配置、命令行 override。这个设计对实验复现非常有用——你只需要把输出目录打包，别人就能完全复现你的实验。

日志配置在_configure_log里。Hydra 默认会配置 Python 的 root logger，输出到控制台和main.log。日志格式可以通过hydra.job_logging配置自定义。我在项目里会把日志级别、格式、输出文件都通过配置管理，不同环境用不同配置，切换起来很方便。

5.3 多任务调度的实现原理

Hydra 的多任务调度能力来自它的 launcher 插件体系。默认的basiclauncher 是串行执行，而joblib、submitit等 launcher 支持并行。调度的核心是hydra.launcher配置和@hydra.main的multirun模式。

当你用--multirun参数运行时，Hydra 会进入多任务模式。它会解析命令行里的 sweep 参数，比如db=mysql,postgresql，生成多个配置组合，然后交给 launcher 执行。源码里这个逻辑在Hydra.multirun方法里。它会调用Sweeper插件生成所有配置组合，然后调用Launcher插件执行。

Sweeper负责把 sweep 表达式展开成配置列表。比如db=mysql,postgresql lr=0.001,0.01会展开成 4 个组合。Launcher负责执行这些组合，可以是串行、并行、或者提交到集群。这个插件化设计让 Hydra 的调度能力可以灵活扩展。

5.4 实验复现与配置快照

实验复现是 Hydra 的一个隐藏亮点。每次运行，Hydra 都会把最终配置保存到.hydra/config.yaml，把 Hydra 自身配置保存到.hydra/hydra.yaml，把命令行 override 保存到.hydra/overrides.yaml。这三个文件合起来，就是一次运行的完整快照。

要复现实验，只需要用同样的代码，加上--config-path指向保存的配置目录，或者直接用--config-name加载保存的配置。我在团队里推行了一个规范：每次重要实验都把输出目录归档，记录在实验管理表里。后来有人质疑某个结果，我们直接翻出当时的配置快照，几分钟就复现了，省去了大量扯皮时间。

这个机制的原理在JobRuntime._save_config里。它用 OmegaConf 把配置序列化成 YAML，写入文件。注意这里保存的是组合后的最终配置，不是原始配置文件。所以即使原始配置文件后来改了，快照依然能复现当时的实验。

6. 源码阅读中发现的几个关键设计取舍

6.1 为什么用 OmegaConf 而不是原生字典

Hydra 选择 OmegaConf 作为配置的底层数据结构，而不是原生字典，这个决策影响深远。OmegaConf 提供了变量插值、类型安全、结构化配置等能力，这些是原生字典不具备的。

变量插值让配置可以互相引用，比如db_url: mysql://${db.host}:${db.port}/${db.name}。类型安全让配置在加载时就能发现类型错误，而不是等到运行时。结构化配置让配置有 schema，可以用 dataclass 定义，获得 IDE 补全和类型检查。

但 OmegaConf 也带来了学习成本。它的DictConfig和原生字典行为不完全一样，比如访问不存在的 key 会抛异常而不是返回 None。我在迁移旧项目时，经常遇到cfg.get("key", default)在 OmegaConf 里行为不同的问题。后来统一用cfg.get("key", default)或者OmegaConf.select来解决。

6.2 配置组合的"显式优于隐式"原则

Hydra 的配置组合设计遵循"显式优于隐式"原则。defaults list 必须显式列出所有要引用的配置，不能靠自动扫描。这个设计牺牲了一些便利性，但换来了可预测性。

对比其他配置管理工具，有些会自动扫描目录下所有配置文件并合并，看起来方便，但容易出现"改了某个文件不知道会不会影响结果"的问题。Hydra 要求你显式声明依赖，虽然多写几行，但配置的来龙去脉清清楚楚。

源码里这个原则体现在_process_defaults_list的实现上。它只处理 defaults list 里显式列出的项，不会去猜测你想加载什么。如果 defaults list 里引用的配置不存在，直接报错，不会静默跳过。这种"fail fast"的设计在大型项目里非常重要。

6.3 插件化架构的扩展点

Hydra 的插件化架构是它企业级能力的来源。核心扩展点包括：ConfigSource（配置来源）、Launcher（任务启动器）、Sweeper（参数扫描器）、SearchPathPlugin（搜索路径插件）、LoggingHandler（日志处理器）。

每个扩展点都有对应的基类和注册机制。比如自定义 Launcher 需要继承Launcher基类，实现launch方法，然后通过hydra.launcher配置指定。源码里hydra/plugins/目录下是内置插件，hydra/core/plugins.py是插件发现和加载的逻辑。

我在项目里实现过一个自定义 Launcher，用来把任务提交到内部的任务队列。实现起来不复杂，继承基类、实现launch方法、注册插件，几十行代码就搞定了。这个扩展能力让 Hydra 不只是一个配置工具，而是一个实验调度平台。

6.4 错误处理与用户提示的设计

Hydra 的错误处理设计值得一提。它在多个层次做了错误捕获和提示优化。比如配置组合失败时，不是简单抛一个 KeyError，而是抛出ConfigCompositionException，附带详细的组合路径和失败原因。

源码里_compose_config的异常处理会收集组合过程中的上下文信息，包括当前处理的 defaults 项、已加载的配置列表、失败的具体位置。这些信息在异常消息里呈现，帮助用户快速定位问题。

我印象最深的一次是配置循环引用，Hydra 的报错直接画出了循环路径：a -> b -> c -> a。这种提示质量在开源工具里算很高的。读源码后发现，这是通过在递归过程中维护调用栈实现的。每个配置加载时把标识压栈，异常时把栈内容格式化输出。

7. 把源码知识用到实际项目里的几个场景

7.1 动态配置注册解决多环境问题

理解了ConfigStore的机制后，我解决了一个多环境配置的难题。项目需要支持开发、测试、生产三套环境，每套环境的数据库、缓存、消息队列配置都不同。传统做法是维护三套配置文件，改一个公共字段要改三处。

用ConfigStore的动态注册能力，我把公共配置抽出来，环境差异部分在代码启动时根据环境变量动态注册：

from hydra.core.config_store import ConfigStore from omegaconf import OmegaConf cs = ConfigStore.instance() env = os.environ.get("APP_ENV", "dev") env_config = OmegaConf.load(f"conf/env/{env}.yaml") cs.store(name="env_config", node=env_config)

然后在主配置的 defaults list 里引用- env_config。这样公共配置只维护一份，环境差异通过动态注册注入。切换环境只需要改环境变量，不用改任何配置文件。

7.2 自定义 Sweeper 实现智能参数搜索

Hydra 内置的 Sweeper 支持网格搜索，但有时候我们需要更智能的搜索策略，比如贝叶斯优化。理解了 Sweeper 的接口后，我实现了一个自定义 Sweeper，把参数搜索委托给 Optuna。

核心是继承Sweeper基类，实现sweep方法。方法接收配置和 sweep 参数，返回一个迭代器，每次产出一个配置组合。内部用 Optuna 的 study 对象管理搜索过程，每次 trial 产出一个配置。这样就把 Hydra 的调度能力和 Optuna 的搜索能力结合起来了。

这个实现的关键是理解Sweeper的契约：它只负责生成配置组合，不负责执行。执行交给 Launcher。这种职责分离让两个插件可以独立替换，组合出各种调度策略。

7.3 配置快照在实验管理中的落地

前面提到 Hydra 会自动保存配置快照，我在项目里把这个能力用到了实验管理上。具体做法是：在@hydra.main装饰的函数里，运行结束后把.hydra目录的内容上传到实验管理平台，和实验指标关联起来。

这样每个实验都有完整的配置记录，查询实验时可以直接看到当时的配置。对比不同实验时，可以 diff 配置文件，快速定位差异。这个实践让团队的实验管理规范了很多，再也不会出现"这个结果是用什么配置跑的"这种问题。

实现上，我在函数末尾加了上传逻辑：

@hydra.main(config_path="conf", config_name="config") def main(cfg): # 训练逻辑 result = train(cfg) # 上传配置快照 upload_config_snapshot(Path(".hydra"), result.experiment_id)

注意工作目录已经被 Hydra 切换到输出目录了，所以.hydra是相对输出目录的路径。这个细节在读源码时搞清楚后，用起来就不会踩坑。

7.4 用 ConfigRepository 的缓存机制优化启动速度

大型项目的配置加载可能成为启动瓶颈。理解了ConfigRepository的缓存机制后，我做了一个优化：把不常变的配置预加载到缓存里，减少重复的文件 IO。

具体做法是在应用启动时，调用ConfigRepository的load_config方法预加载核心配置。这些配置会被缓存，后续 Hydra 运行时直接命中缓存，省去文件读取和解析的时间。实测在配置较多的项目里，启动时间能减少 30% 左右。

但要注意缓存的失效问题。如果配置在运行时会变，需要手动清缓存。源码里ConfigRepository没有暴露清缓存的方法，但可以通过重新创建实例来达到目的。我在需要热更新的场景里，会定期重建ConfigRepository实例。

8. 读源码过程中踩过的坑和验证方法

8.1 版本差异导致的源码行为不一致

Hydra 的版本迭代比较快，不同版本的源码行为有差异。我在读源码时，先确认了版本号，然后对照对应版本的代码。比如_self_的默认位置在 1.0 和 1.1 里就不一样，1.1 之后默认放在 defaults list 末尾，而更早的版本行为不同。

验证方法是写一个最小复现脚本，打印最终配置，对比不同版本的行为。我建了一个测试目录，里面放几个简单的配置文件，用不同版本的 Hydra 跑同一个脚本，观察输出差异。这个方法帮我搞清楚了好几个版本相关的疑惑。

8.2 用调试器跟踪配置组合过程

光看源码有时候不够直观，我会用调试器实际跟踪一遍。在ConfigLoaderImpl._compose_config里打断点，然后单步执行，观察每一步的配置变化。PyCharm 的调试器可以可视化DictConfig的内容，非常直观。

跟踪过程中我发现了几个文档里没写的细节：比如配置组合时会先做一次深拷贝，避免修改原始配置；比如 override 的应用是在组合完成后单独一步，而不是穿插在组合过程中。这些细节对理解行为边界很重要。

8.3 配置组合失败的常见原因排查

配置组合失败是使用 Hydra 时最常见的问题。我总结了一个排查清单：

这个清单是我在实际项目中反复验证过的，覆盖了大部分常见问题。特别是--cfg job这个参数，能在不实际运行的情况下打印最终配置，排查配置问题时非常有用。

8.4 源码阅读的节奏与方法

读 Hydra 源码不要试图一次读完。我的方法是按需阅读：遇到问题时，定位到相关模块，读那部分代码，理解后记录下来。这样积累下来，对整个框架的理解会越来越完整。

我建了一个笔记文件，记录每个模块的核心逻辑和关键代码位置。比如"ConfigStore 的 store 方法在 config_store.py 第 120 行左右""配置组合的核心循环在 config_loader_impl.py 的 _compose_config 方法"。这些笔记在后续排查问题时能快速定位。

另外，Hydra 的测试代码是很好的学习材料。tests/目录下有大量测试用例，覆盖了各种边界情况。读测试用例能快速理解一个功能的预期行为。我经常先读测试，再读实现，这样理解起来更有针对性。

9. 从源码看 Hydra 的适用边界

Hydra 不是万能的，理解它的适用边界比盲目使用更重要。从源码设计来看，Hydra 最适合的场景是：配置结构复杂、需要多环境多实验管理、需要批量调度的 Python 项目。它的配置组合能力和调度能力在这些场景下优势明显。

但如果项目配置很简单，只有几个参数，引入 Hydra 反而增加复杂度。我见过一个项目，总共就三个配置项，硬套 Hydra，结果配置文件比代码还多。这种场景用环境变量或者简单的 argparse 就够了。

另一个边界是学习曲线。Hydra 的概念比较多——defaults list、配置组、override、sweeper、launcher，每个都有学习成本。团队引入 Hydra 时，需要预留学习时间，最好有人先踩坑再推广。我在团队里推广时，先做了一个内部培训，把常见用法和坑点整理成文档，后面大家上手就快多了。

从源码的扩展点设计来看，Hydra 的插件体系是它最有价值的部分。如果你的项目需要自定义调度策略、自定义配置来源、自定义日志处理，Hydra 的插件机制能省去大量造轮子的时间。但前提是你要理解插件接口的契约，这又回到了读源码的价值上。

最后分享一个我个人的体会：读 Hydra 源码最大的收获不是记住了多少实现细节，而是理解了"配置驱动"这种设计思路。它把配置提升为一等公民，让代码逻辑和配置数据分离，这种思路可以迁移到很多其他系统设计里。即使你以后不用 Hydra 了，这种思路依然有价值。