PreparedStatement本身不等于安全，因其仅对参数值占位，若拼接用户输入构造SQL字符串、动态标识符或绕过预处理机制，仍会导致SQL注入。
能彻底防止SQL注入——但前提是正确使用，且不绕过预处理机制。
为什么 PreparedStatement 本身不等于安全
很多人以为只要用了 PreparedStatement 就高枕无忧，其实不然。常见破防点包括：
- 在 SQL 字符串里拼接用户输入，再传给
prepareStatement()，比如："SELECT * FROM users WHERE name = '" + userInput + "'"—— 这根本没走预处理，只是徒有其表 - 用字符串拼接构造表名、列名、ORDER BY 子句等动态结构（这些不能用 ? 占位），例如：
"SELECT * FROM " + tableName + " WHERE id = ?" - 调用
Statement执行拼接后的 SQL，却误以为自己在用预处理
这些操作让数据库驱动完全无法介入参数绑定，恶意输入直接进入解析阶段，PreparedStatement 的隔离机制形同虚设。
Java 17 中必须启用的两个关键配置
JDBC 驱动默认可能禁用真正的服务器端预处理，导致实际走的是客户端模拟（emulated）模式，性能和安全性都会打折扣。务必确认连接 URL 中包含：
立即学习“Java免费学习笔记（深入）”；
-
useServerPrepStmts=true：强制使用 MySQL 服务端预处理语句（需数据库支持） -
cachePrepStmts=true：开启预处理语句缓存，避免重复编译开销
完整示例 URL：jdbc:mysql://localhost:3306/mydb?useServerPrepStmts=true&cachePrepStmts=true&rewriteBatchedStatements=true。漏掉 useServerPrepStmts=true，即使写了 prepareStatement()，驱动也可能把 ? 替换为字符串后发给服务端，失去“代码/数据分离”的核心保护。
哪些地方不能用 ? 占位，必须额外防护
PreparedStatement 只允许对**参数值**占位，不支持对标识符（表名、列名、排序字段、UNION 子句等）占位。遇到这类动态结构时：
- 绝对不要拼接用户输入到 SQL 字符串中
- 改用白名单校验：比如排序字段只允许
"name"、"created_at"、"status"几个固定值，用switch或Set.of()判断 - 表名/列名若必须动态，优先通过配置或枚举定义，而非运行时接收任意字符串
- 如真需灵活结构（极少见），可考虑
String.format()+ 严格正则过滤（如^[a-zA-Z_][a-zA-Z0-9_]*$），但这是兜底手段，不是首选
例如：ORDER BY %s 中的 %s 必须来自白名单，绝不可是 request.getParameter("sort") 原样代入。
资源关闭与 try-with-resources 的强制要求
Java 17 要求显式管理资源，否则可能因未关闭 PreparedStatement 或 ResultSet 导致连接泄漏，间接影响预处理语句缓存命中率，甚至引发连接池耗尽。正确写法必须用 try-with-resources：
try (PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE email = ?")) {
stmt.setString(1, userEmail); // 用户输入只进这里
try (ResultSet rs = stmt.executeQuery()) {
while (rs.next()) { /* 处理结果 */ }
}
}漏掉 try (ResultSet rs = ...) 或手动调用 close()，在高并发下容易掩盖真实问题，让人误判预处理是否生效。
真正难的不是写对那一行 prepareStatement()，而是守住所有可能把用户输入塞进 SQL 字符串的缝隙——尤其是动态表名、排序、分组、条件字段这些非参数位置。一旦松动，整个预处理防线就从内部瓦解。
