Hikari 启动报 configuration of the pool is sealed，检查 CONNECTION_TIMEOUT 环境变量

给 Spring Boot 的 Hikari 连接池增加超时配置，错误却指向另一个参数：

Failed to bind properties under 'spring.datasource.hikari'
The configuration of the pool is sealed once started.
Use HikariConfigMXBean for runtime changes.

如果环境里写了 SPRING_DATASOURCE_HIKARI_CONNECTION_TIMEOUT，先改正这个键。这里多出的下划线会把 connection-timeout 拆成 connection.timeout。绑定器可能先调用数据源的 getConnection()，提前启动连接池，随后再绑定其他池参数时才遇到“配置已封存”。

这条排查路径适用于启动阶段的属性绑定错误，Spring Boot 4.1.0 的直接 Hikari 绑定有对应表现。已经运行的应用通过代码修改配置而报同样异常时，须另查运行时修改路径，不能只凭一句 sealed 就归到环境变量。

连字符删除，点才变成下划线

Spring Boot 环境变量的规范转换规则是：属性名里的点变成下划线，连字符删除，再转成大写。因此两种写法的含义不同：

spring.datasource.hikari.connection-timeout
SPRING_DATASOURCE_HIKARI_CONNECTIONTIMEOUT

spring.datasource.hikari.connection.timeout
SPRING_DATASOURCE_HIKARI_CONNECTION_TIMEOUT

Hikari 要的是 connectionTimeout，不是 connection 对象下面的 timeout。正确环境变量示例如下，值 5000 表示这个池参数的毫秒值：

SPRING_DATASOURCE_HIKARI_CONNECTIONTIMEOUT=5000

在 Compose、Kubernetes、部署平台或进程管理器中更正原来注入的位置，并移除错误键。不要只在本机终端设置新值，让旧键继续留在真实服务的环境里；两个不同键并存，错误的嵌套路径仍可能被处理。

若使用自定义前缀，如 my.datasource.hikari，同样需要按点和连字符区分层级。直接写 YAML 时保持叶子属性：

my:
  datasource:
    hikari:
      connection-timeout: 5000

下面这种写法引入了一层真实的 connection，不是同义写法：

my:
  datasource:
    hikari:
      connection:
        timeout: 5000

为什么报错的却是 initialization-fail-timeout

JavaBean 绑定会查找中间属性的 getter。HikariDataSource 的 getConnection() 有实际副作用：创建或取得连接时会使连接池启动，启动后部分静态配置不能再设置。

因此错误可能出现在后续的 pool-name、initialization-fail-timeout 等字段上。它们只是最先撞上封存状态的设置，不一定是最早的错误。不要为此反复调整参数声明顺序；先修正导致数据源被提前访问的路径。

日志建议 HikariConfigMXBean 面向的是允许运行时修改的配置场景，不能把它当成启动配置绑定的通用补丁。应用尚未完成初始化时，应先让属性正确绑定，再让连接池正常启动。

同一套环境中其他带下划线的长键偶然能够绑定，也不能证明命名正确。是否有同名中间 JavaBean 属性，会影响错误能否显现；按规范生成键名才能避免把层级交给偶然的对象结构决定。

更改前保存配置差异，查看环境时只核对相关键名与数值，不输出数据库密码。按原部署方式重启目标应用后，确认属性绑定完成、目标池使用预期超时、连接到正确数据库，并且没有在配置未齐时提前初始化。不要用耗尽生产连接池的方式验证超时。

若修正后变成 jdbcUrl is required with driverClassName，继续检查Hikari 直接绑定的 URL 属性。两类故障都发生在数据源配置附近，但一个是错误层级触发 getter，一个是 URL 属性适配缺失，处理方式不同。