Hyperf的ConfigFetcher不能直接解密敏感配置，因其仅读取原始字符串而不解析；需自定义实现ConfigFetcherInterface，在fetch()中识别ENC:前缀密文并解密，失败时抛出RuntimeException中断启动。
Hyperf 的 ConfigFetcher 为什么不能直接解密敏感配置？
因为默认的 ConfigFetcher 只负责从文件或环境变量中读取原始字符串，不做任何解析或转换。如果你把加密后的密文（比如 AES 加密的 enc_123abc...）直接写进 config/autoload/database.php，Hyperf 会原样返回它——后续数据库组件拿到的是密文，不是明文密码，必然连接失败。
必须在配置加载完成、但尚未被组件消费前，对特定 key（如 database.default.password）做解密干预。
如何注册自定义 ConfigFetcher 并确保它生效？
Hyperf 的配置加载流程是：启动时调用 ConfigLoader → 它依赖注入的 ConfigFetcher 实例去拉取数据 → 合并后存入 Config 对象。所以你要替换的是容器里绑定的 ConfigFetcherInterface 实现。
在 config/autoload/dependencies.php 中覆盖绑定：
return [
Hyperf\Config\Contract\ConfigFetcherInterface::class => App\Config\EncryptedConfigFetcher::class,
];
注意两点：
- 你的
EncryptedConfigFetcher必须实现ConfigFetcherInterface，且fetch()方法需先调用父类（或原始逻辑）获取原始配置数组，再遍历处理敏感字段 - 不能在
fetch()里直接读环境变量或文件——要复用原有逻辑，否则会丢失.env或多环境覆盖能力
哪些配置项需要解密？怎么安全标记它们？
硬编码判断 key 名（如 password、secret）风险高：可能误伤非敏感字段，也难维护。推荐用统一前缀标记密文，例如所有加密值都以 ENC: 开头：
'password' => 'ENC:U2FsdGVkX1+Z...', 'access_key' => 'ENC:U2FsdGVkX1+Y...',
解密逻辑只作用于值匹配 ^ENC:(.*)$ 的字段。这样：
- 配置文件保持可读性：开发者一眼看出哪些是密文
- 避免正则误匹配真实含
password字符串的配置（如注释、URL 参数） - 加解密密钥可独立管理（如从 KMS 或
HYPERF_ENCRYPTION_KEY环境变量读取），不耦合在配置文件中
解密失败时该怎么处理？
生产环境配置解密失败必须中断启动，不能静默 fallback 到空字符串或默认值——那会导致数据库连不上、Redis 认证失败等隐蔽故障。
在 EncryptedConfigFetcher::fetch() 中，对每个匹配 ENC: 的值做解密，一旦抛出异常（如密钥错误、密文损坏），立刻 throw 新的 RuntimeException，包含原始 key 路径和错误原因：
throw new RuntimeException("Failed to decrypt config key [database.default.password]: " . $e->getMessage());
这样：
- Hyperf 启动失败并打印清晰错误，运维能快速定位是解密环节出问题
- 不会因部分字段解密失败而留下半解密状态（比如只解了 password 没解 access_key）
- 避免在运行时才暴露问题（如首次 DB 查询时 panic）
真正麻烦的是密钥轮换——旧密文无法用新密钥解，必须配合配置热更新或滚动发布策略，这点容易被忽略。
