不能只靠“加预编译”重构拼接SQL，因表名、列名、ORDER BY字段等无法参数化；须分层剥离：先识别不可参数化部分，再用白名单/枚举校验，最后用QueryBuilder统一管理动态条件。
直接结论：不能只靠“加预编译”来重构拼接SQL
单纯把 String + "WHERE id = " + id 换成 PreparedStatement 是治标不治本。真正危险的不是字符串拼接本身，而是拼接逻辑混入了用户输入、动态表名/列名、条件分支控制流——这些根本无法用 PreparedStatement 参数化。重构必须分层剥离：先识别不可参数化的部分，再用白名单或元数据校验替代硬编码拼接。
第一步：识别哪些拼接根本不能进 setString()
以下三类内容在 SQL 字符串中出现时，PreparedStatement 完全无效，强行套用只会掩盖问题：
- 表名、列名（如
"SELECT * FROM " + tableName + " WHERE ..."） - ORDER BY 字段或方向（如
"ORDER BY " + sortField + " " + sortOrder） - 动态 WHERE 条件块（如
sql += " AND status = '" + status + "'"且status可能为空）
这类拼接一旦存在，说明业务逻辑和 SQL 结构耦合过深。必须拆出独立的“SQL 结构生成器”，而不是试图用 ? 占位。
第二步：用白名单 + 枚举替代运行时字符串拼接
对表名、列名、排序字段等有限集合，禁止接收任意字符串，改用枚举或配置白名单校验：
立即学习“Java免费学习笔记（深入）”；
// ✅ 正确：用枚举约束可选字段
public enum SortField { NAME, CREATED_TIME, STATUS }
public String buildOrderBy(SortField field, String order) {
if (!"ASC".equalsIgnoreCase(order) && !"DESC".equalsIgnoreCase(order)) {
throw new IllegalArgumentException("Invalid order: " + order);
}
return "ORDER BY " + field.name() + " " + order.toUpperCase();
}
<p>// ❌ 错误：直接拼接未校验的 userSortField
String sql = "SELECT * FROM user ORDER BY " + userSortField;注意：field.name() 是安全的，因为枚举值在编译期确定；但若从 HTTP 参数解析枚举，务必用 Enum.valueOf() 并捕获 IllegalArgumentException，不能 fallback 到原始字符串。
第三步：把动态条件提取为独立的 QueryBuilder 类
遗留代码中常见的 if (name != null) sql += " AND name LIKE '%" + name + "%'" 必须重写。手动拼接极易漏转义、错空格、少括号：
- 不要自己拼
AND/OR，用链式构建器统一管理连接词 - 所有值一律走
PreparedStatement，结构变化（如是否包含某条件）由 Java 控制，不体现在 SQL 字符串里 - 避免“空条件默认加 1=1”这种反模式，它破坏执行计划缓存
示例核心逻辑：
QueryBuilder qb = new QueryBuilder("SELECT * FROM user");
qb.where("status = ?", status); // 自动跳过 null/empty
qb.where("name LIKE ?", "%" + name + "%");
qb.orderBy("created_time DESC");
String sql = qb.getSql(); // "SELECT * FROM user WHERE status = ? AND name LIKE ? ORDER BY ..."
Object[] params = qb.getParams(); // [status, "%xxx%"]关键点：where() 内部判断参数是否有效，只在必要时追加条件片段并登记参数——SQL 字符串和参数列表同步生成，不会错位。
最易被忽略的是数据库关键字转义（如列名叫 order 或 user）。即使用了白名单，也要在生成 SQL 前对标识符加反引号（MySQL）或双引号（PostgreSQL），且必须依赖数据库方言，不能硬编码。这点在跨库迁移时经常引发静默错误。
