在自定义库中开放Spring Data JDBC包私有SqlGenerator方法是否合理？

核心结论 #

直接开放包私有SqlGenerator类的方法不是合理方案，原因和替代方案如下：

为什么不建议开放 #

• 破坏封装设计：Spring将SqlGenerator设为包私有，本质是把它标记为内部实现细节，不希望外部依赖。强行开放会让你的库绑定到Spring的内部逻辑，一旦Spring后续版本重构SqlGenerator（比如修改方法签名、删除核心功能），你的库会直接出现兼容性问题。
• 违反API契约：Spring Data JDBC的公共API才是官方承诺稳定兼容的部分，依赖内部类等于跳过了官方的兼容性保障，后续升级Spring版本会面临极高的维护成本。
• 设计耦合风险：你的库会和Spring的内部实现深度耦合，无法独立于Spring版本迭代，不符合模块化设计的基本原则。

更合理的替代方案 #

1. 基于公共API封装适配层 #

既然你已经实现了DataAccessStrategy等公共接口，完全可以基于这些公开API封装自己的SQL生成逻辑，或者复用官方公共组件的能力。比如利用JdbcConverter、MappingContext这些公开类来构建需求，而非直接依赖内部的SqlGenerator。

2. 遵循Spring的扩展点设计 #

Spring Data JDBC提供了标准扩展点，比如自定义DataAccessStrategy时，可以通过组合或继承DefaultDataAccessStrategy来扩展功能——它内部会调用SqlGenerator，但你不需要直接依赖这个包私有类，既复用了官方逻辑，又保持了与公共API的绑定。

3. 临时场景的折中方案（不推荐长期使用） #

如果确实需要临时用到SqlGenerator的能力，不要自己在org.springframework.data.jdbc.core.convert下新增类（这属于侵入Spring包结构的不规范做法），可以通过Spring容器获取内部实例：

// 仅作临时场景示例，生产环境不推荐
SqlGenerator sqlGenerator = applicationContext.getBean(SqlGenerator.class);

但这种方式依然依赖内部实现，仅适合短期过渡，长期来看还是要转向公共API方案。

总结 #

优先基于Spring Data JDBC的公共API构建自定义仓库，避免依赖内部包私有类。如果现有公共API无法满足需求，建议自行实现独立的SQL生成逻辑，或者向Spring Data社区提交Feature Request，这才是更稳定、可维护的方案。

内容的提问来源于stack exchange，提问作者Khusayn