PreparedStatement 并不能彻底防止 SQL 注入，前提是必须严格遵守“SQL 结构固定、参数纯数据化”原则；任何动态拼接表名、字段名、ORDER BY 子句，或误用 setObject 等行为都会使防护失效。
PreparedStatement 能彻底防止 SQL 注入，但前提是它被正确使用——任何绕过占位符、动态拼接 SQL 模板或误用 setObject 的场景，都会让防护形同虚设。
为什么 PreparedStatement 不是“开箱即用”的银弹
很多人以为只要用了 PreparedStatement 就安全了，其实不然。它的防护机制依赖于“SQL 结构固定 + 参数纯数据化”这一契约。一旦破坏这个前提，比如在 prepareStatement 的 SQL 字符串里拼接表名、字段名或 ORDER BY 子句，? 占位符就完全失效。
- 错误示例：
String sql = "SELECT * FROM " + tableName + " WHERE id = ?";—— 表名无法用?参数化，必须白名单校验 - 错误示例：
"ORDER BY " + sortField—— 字段名需从预设枚举中取值，不能直接反射或拼接 - 错误示例：
ps.setObject(1, userInput, Types.VARCHAR)仍不安全 —— 若userInput是恶意构造的 JDBC 驱动扩展类型（如某些老版 MySQL 驱动支持的SET类型注入），可能触发非预期行为；应始终用明确的setString/setInt等方法
Java 17 中 PreparedStatement 的正确写法
Java 17 对 JDBC 规范无颠覆性变更，但强化了资源自动管理与类型安全意识。关键在于：所有用户可控输入必须走 setXxx() 方法，且 SQL 模板必须是编译期常量或严格受限的字符串。
- ✅ 推荐写法（try-with-resources + 显式类型方法）：
String sql = "SELECT id, name FROM users WHERE status = ? AND created_at > ?"; try (Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, "ACTIVE"); ps.setTimestamp(2, Timestamp.from(Instant.now().minusSeconds(86400))); try (ResultSet rs = ps.executeQuery()) { while (rs.next()) { /* ... */ } } } - ⚠️ Java 17 特别注意：
setObject(int, Object)在处理null或泛型类型时可能触发驱动内部隐式转换，建议改用setNull(int, int)显式声明空值类型 - ⚠️ 不要依赖 IDE 自动补全的
setObject—— 它掩盖了类型歧义，例如传入LocalDateTime时，不同驱动对时区和精度的处理不一致
容易被忽略的三类“伪安全”场景
这些情况看似用了 PreparedStatement，实则埋下注入隐患：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
-
LIKE查询中的通配符未转义：用户输入"%admin%"是合理需求，但如果直接ps.setString(1, "%" + userInput + "%")，而 userInput 包含_或%，就会语义污染；应统一用ESCAPE子句并调用setEscapeCharacter（JDBC 4.2+）或手动replace转义 - IN 子句参数个数动态变化：不能写成
"WHERE id IN (?)"并试图塞入数组；必须根据实际元素数量生成对应数量的?，再逐个setXxx；推荐用 MyBatis 的<foreach>或 JPA 的CriteriaBuilder替代手写 - 数据库函数内嵌用户输入：如
"WHERE DATE(created_at) = DATE(?)"安全，但"WHERE " + userFunction + "(?) = 'x'"不安全 —— 函数名属于 SQL 结构，不可参数化
真正“彻底”的防护需要组合策略
单靠 PreparedStatement 只能解决“参数注入”，而真实系统还需应对表名/列名/排序/分页等结构注入。Java 17 下更务实的做法是：
- 对所有动态 SQL 片段（如表名、字段列表、
GROUP BY）建立白名单映射，用enum或Map<String, String>控制可选值 - 用
java.sql.SQLType替代java.sql.Types常量（Java 8+ 引入，Java 17 已稳定），提升类型语义清晰度 - 在 DAO 层加一道轻量级输入过滤：对疑似 SQL 关键字（
UNION、SELECT、;、--）做前置拒绝，不是为了替代 PreparedStatement，而是作为纵深防御的兜底
最危险的不是不会用 PreparedStatement，而是用着它却把 SQL 模板当成了可信任输入源——模板一旦动态生成，防护边界就消失了。
