如何编写Java程序实现Statement到PreparedStatement的自动化转换

该需求完全可实现，核心不是靠字符串匹配的“硬替换”，而是通过结构化的Java源码静态分析完成自动化代码转换，工业界已有成熟的实现路径，能覆盖绝大多数业务场景下的Statement拼接SQL改造需求。

1. 避开正则匹配的坑 #

直接用正则表达式扫描源码做替换是不可行的：很容易误将日志文本、普通业务字符串、代码注释里的类SQL文本识别为SQL拼接逻辑，遇到带分支判断、三元表达式、嵌套方法调用的复杂SQL拼接场景时，正则完全无法追踪参数的实际拼接顺序，极易生成逻辑错误的代码。

2. 基于抽象语法树（AST）做结构化源码解析 #

选用成熟的Java源码解析工具（如JavaParser、Spoon）将输入的.java源文件解析为结构化的语法树，精准识别所有需要改造的目标节点，核心识别范围包括：

• 普通Statement的创建节点：定位所有通过connection.createStatement()生成的Statement变量，划定该变量的全局作用域范围
• SQL字符串的全链路构造逻辑：回溯找到该Statement后续调用executeQuery/execute/executeUpdate方法时传入的SQL变量，追踪该变量从声明、赋值到所有字符串拼接操作的完整执行路径，区分其中的固定SQL文本片段和动态拼接的入参表达式
• 动态入参的上下文：记录每个动态入参的Java类型、出现的位置、所在的代码分支（比如示例中groupId仅在非空判断的分支里才会被拼接到SQL中），确保后续参数绑定顺序和SQL占位符位置完全匹配

3. 按固定规则完成AST节点改写 #

在完成目标节点识别后，直接对语法树节点做替换，而非修改原始文本，保证代码逻辑的准确性：

• 替换SQL拼接片段：将所有动态拼接到SQL里的入参表达式，替换为?占位符，完全保留原有SQL的固定文本、分支判断逻辑（比如示例中仅当groupId非空才追加group_id条件的逻辑不会被改动）
• 替换Statement初始化逻辑：将原来的Statement stmt = connection.createStatement()改写为PreparedStatement stmt = connection.prepareStatement(query)，同时调整代码顺序，保证prepareStatement的调用位置在所有SQL字符串拼接逻辑完成之后，避免出现SQL未拼接完成就初始化预编译语句的顺序错误
• 自动生成参数绑定代码：维护一个从1开始递增的参数索引，按照参数在SQL占位符中出现的先后顺序，根据动态入参的Java类型自动生成对应的绑定方法，不需要额外定义示例中的parameterIndex临时变量，减少冗余代码：
  • Long类型参数生成stmt.setLong(索引, 参数值)
  • String类型参数生成stmt.setString(索引, 参数值)
  • Integer等其他基础/包装类型自动匹配对应的set方法
  • 分支内的参数绑定逻辑要和原分支的代码块保持一致，比如示例中groupId的绑定代码就要插入到原来的非空判断if块内部，不能挪到if块外面，避免参数顺序错位
• 替换执行方法调用：将原来带query参数的stmt.executeQuery(query)调用，改写为无参的stmt.executeQuery()，匹配PreparedStatement的方法调用规范

4. 边界场景的兼容校验 #

为了避免改写后出现代码错误，需要增加校验拦截逻辑：

• 识别无法直接改写的场景（比如动态拼接表名、列名的情况，这类场景不适合用?占位符），不对这类代码做自动替换，直接输出提示提醒人工处理
• 校验改写后的参数绑定数量和SQL中?的数量完全一致，检查参数顺序是否和占位符顺序匹配
• 保留原有的异常处理、资源关闭、try-with-resources等逻辑，不对原有非目标代码做额外修改

针对给出的示例代码，经过上述流程改写后，会完全匹配期望的PreparedStatement实现效果：将两个动态拼接的id、groupId替换为?，调整初始化逻辑为PreparedStatement，按顺序生成两个setLong的参数绑定代码，最后将executeQuery的入参移除，全程不需要人工调整代码结构。

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