ShardingSphere 5.5.3 初始化池报空值，检查 Hikari 可选插件

ShardingSphere-JDBC 从 5.5.2 升到 5.5.3，原 SQL Server 配置没有改，启动却在 Hikari 连接池初始化时报：

HikariPool$PoolInitializationException: Failed to initialize pool:
Cannot invoke "Object.toString()" because the return value of "java.util.Map.get(Object)" is null

如果数据源采用 com.zaxxer.hikari.HikariDataSource，先检查运行产物是否包含 ShardingSphere 的 Hikari 可选插件。业务依赖里有 HikariCP，不代表框架用来创建、适配这个池的 SPI 实现也在。

连接池类与连接池适配插件是两层依赖

5.5.3 的可选插件划分中，shardingsphere-infra-data-source-pool-hikari 提供 Hikari 数据源创建和属性适配。它的元数据会把 ShardingSphere 通用属性映射到 jdbcUrl、maximumPoolSize 等 Hikari 名称。升级后缺少这一层，不能通过反复调整数据库密码或放大连接超时补齐。

应先核对报错是否来自这次升级和数据源初始化，再查看最终依赖解析及打包内容。相同的 Map.get() 空值也可能来自其他配置；外层一句 Failed to initialize pool 不足以证明根因。

补齐与当前版本一致的可选插件

在已经使用 ShardingSphere 5.5.3 的 Maven 项目中，可以补入以下依赖；版本属性应与现有 ShardingSphere 依赖统一：

<dependency>
  <groupId>org.apache.shardingsphere</groupId>
  <artifactId>shardingsphere-infra-data-source-pool-hikari</artifactId>
  <version>${shardingsphere.version}</version>
</dependency>

不要把 HikariCP 自己的版本填进这个版本属性，也不要同时带入几个版本的 ShardingSphere 插件。只改 pom.xml、运行时却仍用旧打包文件，SPI 可见性不会改变。

SQL Server 还需要相应数据库适配与 JDBC 驱动。5.5.3 的 SQL Server 用法明确列出 shardingsphere-jdbc-dialect-sqlserver 和 com.microsoft.sqlserver:mssql-jdbc。若当前场景采用 Cluster 模式及 ZooKeeper，另检查 shardingsphere-cluster-mode-repository-zookeeper；采用 jdbc:shardingsphere:classpath: 加载配置，则检查对应 classpath URL 插件。

这些模块按实际功能选择，不是要求所有项目装上全部插件。业务用了分片、读写分离、权限或其他可选功能时，也应按其配置核对相应实现。仅补一个 Hikari 模块，不能保证所有后续模块都齐全。

包里有依赖，启动时仍要能发现SPI

项目做 shaded JAR、依赖裁剪或原生镜像时，检查 SPI 服务描述是否在打包过程中丢失或被覆盖。不要通过复制一份来源不明的 JAR 到服务器绕开构建，也不要在测试和生产分别拼出不同的类路径。

验收应使用与部署一致的完整产物，确认初始化越过原来的空值位置、池属性保持预期、能连接到正确数据库，并覆盖实际启用的规则与模式。补依赖后若出现明确的 SQL Server 认证或网络错误，那是后续阶段，应保留完整异常链继续定位。

本次调整不需要改数据库结构或迁移业务数据。保留原依赖锁定、构建产物和配置；需要回退时一起恢复，避免退回主模块却留下不兼容的新插件。