preparedstatement 的占位符仅支持参数值，不支持表名等结构化部分；安全处理动态表名须用白名单校验或元数据验证，严禁直接拼接用户输入。
PreparedStatement 的占位符（?）只支持参数值，不支持表名、列名、排序字段或 SQL 关键字等结构化部分——这是 JDBC 规范决定的，不是 bug，也不能绕过语法限制直接拼接。要安全、灵活地处理动态表名，核心思路是：**表名必须在 SQL 字符串拼接阶段确定，但必须严格校验，杜绝 SQL 注入**。
用白名单校验表名
最安全、最推荐的方式。把允许操作的表名预先定义为常量或配置项，运行时只从其中选择：
- 定义合法表名集合，例如：
Set.of("user", "order", "product") - 接收外部传入的表名字符串（如前端请求参数
tableName=user） - 检查该字符串是否存在于白名单中；不在则抛异常或返回错误，绝不继续执行
- 确认合法后，用字符串拼接进 SQL，再创建 PreparedStatement 处理参数值
示例：
String tableName = request.getParameter("table");
if (!Set.of("user", "order", "log").contains(tableName)) {
throw new IllegalArgumentException("非法表名");
}
String sql = "SELECT * FROM " + tableName + " WHERE status = ?";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
ps.setString(1, "active");
// 执行查询...
}用数据库元数据动态验证
适用于表名来自配置或需一定灵活性，但又不能硬编码白名单的场景。可通过 JDBC 获取当前数据库中真实存在的表名进行比对：
- 调用
conn.getMetaData().getTables(null, null, "%", new String[]{"TABLE"}) - 遍历结果集，提取所有表名，存入 Set
- 用传入的表名去查这个 Set，存在才允许拼接
- 注意：元数据查询有开销，建议缓存校验结果（如用 ConcurrentHashMap + 定时刷新）
避免常见错误做法
以下方式看似“能用”，但存在严重风险，应禁止：
-
直接拼接用户输入的表名：例如
"SELECT * FROM " + userInputTable→ 极易导致 SQL 注入（如输入user; DROP TABLE order --） -
用 PreparedStatement 占位符尝试绑定表名：例如
"SELECT * FROM ? WHERE id = ?"→ 会报 SQL 语法错误，驱动不支持 - 简单字符串替换或正则过滤：比如只删掉分号或注释符 → 绕过手段太多，不可靠
其他结构化参数的处理原则
列名、ORDER BY 字段、GROUP BY 字段等，和表名一样，都不能用 ? 占位。统一适用相同策略：
- 优先白名单控制（如固定排序字段：
"created_time"、"status"） - 次选元数据校验（如查询
getColumns()确认列是否存在） - 永远不信任外部输入，拼接前必须验证
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
