JeecgBoot项目集成ShardingSphere分库分表组件问题解析

问题背景

在JeecgBoot 3.7.3版本(基于Spring Boot 3.1.5)中集成ShardingSphere分库分表组件时，开发者遇到了一个典型的堆栈溢出错误。当调用测试接口时，系统抛出jakarta.servlet.ServletException: Handler dispatch failed: java.lang.StackOverflowError异常，导致服务不可用。

错误现象分析

从错误截图可以看出，系统陷入了无限递归调用，最终导致堆栈溢出。这种错误通常发生在以下场景：

1. 组件之间存在循环依赖
2. 拦截器或AOP逻辑处理不当
3. 框架集成时Bean初始化顺序问题

配置分析

开发者提供的ShardingSphere配置看似合理：

• 配置了单数据源(ds0)
• 使用CLASS_BASED分片算法
• 对sys_log表按log_type字段进行分片(分为2个表)

根本原因

经过深入分析，问题根源在于Spring Boot 3.x与ShardingSphere的自动配置存在兼容性问题。具体表现为：

1. 版本冲突：Spring Boot 3.x默认使用Jakarta EE API，而某些ShardingSphere组件可能仍依赖Javax EE
2. 自动配置顺序：ShardingSphere的自动配置与JeecgBoot的自定义配置在初始化顺序上存在冲突
3. Bean循环依赖：数据源初始化过程中产生了循环引用

解决方案

根据项目维护者的建议，解决方案是：

手动管理ShardingSphere JDBC依赖，而不是使用Spring Boot的starter自动配置。具体实施步骤：

1. 排除Spring Boot自带的ShardingSphere依赖
2. 显式引入特定版本的ShardingSphere JDBC核心依赖
3. 手动配置数据源和分片规则

技术启示

1. 框架集成注意事项：在集成第三方组件时，特别是像ShardingSphere这样的复杂中间件，需要特别注意版本兼容性
2. 依赖管理策略：对于重要基础设施组件，建议采用显式依赖声明而非隐式自动配置
3. 问题排查方法：遇到StackOverflowError时，应重点检查递归调用链和Bean初始化顺序

最佳实践建议

对于JeecgBoot项目集成ShardingSphere，建议采用以下实践：

1. 使用依赖管理统一版本
2. 分阶段测试：先测试基础数据源，再添加分片规则
3. 考虑使用ShardingSphere的Spring命名空间配置方式，提高可维护性
4. 对于生产环境，建议进行完整的性能测试和故障演练

通过以上分析和解决方案，开发者可以成功在JeecgBoot 3.x环境中集成ShardingSphere分库分表组件，避免堆栈溢出错误的发生。