preparedstatement能防sql注入，因其将sql模板与参数物理隔离：数据库先预编译含?的语句生成固定语法树，再将用户输入作为纯数据绑定，不参与解析；而字符串拼接使输入直入sql解析器，易被恶意构造改变逻辑。
预编译语句（PreparedStatement）是防止 SQL 注入最可靠、最通用的手段——只要参数值全部走 ? 占位符绑定，数据库层面就不可能把用户输入当 SQL 代码执行。
为什么 PreparedStatement 能防注入，而字符串拼接不能
根本区别在于：SQL 结构和参数在数据库中是否被物理隔离。
PreparedStatement 先把 "SELECT * FROM users WHERE id = ?" 这类带 ? 的模板发给 MySQL，服务端立即编译成执行计划，此时语法树已固定；后续调用 setInt(1, userInput) 时，MySQL 只把 userInput 当作纯数据塞进绑定位置，不参与任何解析或拼接。
字符串拼接（如 "SELECT * FROM user WHERE name = '" + name + "'"）等于把用户输入直接喂给 SQL 解析器，哪怕加了单引号、转义函数，也挡不住宽字节、十六进制绕过等手法。
- 恶意输入
"admin' OR '1'='1"在拼接场景下会变成完整可执行语句 - 在 PreparedStatement 场景下，它只会被当作一个字符串值存入字段，不会改变查询逻辑
- 数据库驱动层根本不允许参数影响 SQL 语法结构
Java 中 PreparedStatement 的正确写法
关键不是“用了没”，而是“用对没”。常见错误包括手动拼接、漏设参数、类型不匹配。
- 必须用
?占位符，不能在 SQL 字符串里拼接变量（如"WHERE name = '" + name + "'"是错的） - 所有参数都得通过
setString()、setInt()等方法绑定，不能靠toString()或字符串替换 - 占位符数量和
setXxx()调用次数必须严格一致，否则抛SQLException - 批量操作要用
addBatch()+executeBatch()，别循环创建新PreparedStatement
示例：
String sql = "SELECT * FROM users WHERE status = ? AND created_at > ?"; PreparedStatement ps = conn.prepareStatement(sql); ps.setInt(1, 1); // status = 1 ps.setTimestamp(2, timestamp); // 时间戳类型要匹配
哪些情况 PreparedStatement 也防不住
它只保护「参数值」，不保护「SQL 结构」。以下场景仍可能被注入：
- 表名、字段名、排序字段（如
ORDER BY后的内容）动态拼接：这些无法用?占位，必须白名单校验或枚举 - 拼接
IN子句（如WHERE id IN (?, ?, ?)）：参数个数不确定时，得动态生成占位符，但生成逻辑本身不能拼用户输入 -
SELECT * FROM " + tableName + " WHERE id = ?：若tableName来自用户请求且未校验，就直接失效 - 使用
setObject()且传入恶意构造的自定义对象：极少见，但若 JDBC 驱动存在反序列化漏洞，可能绕过
MySQL 原生命令级 PREPARE 的注意事项
MySQL 服务端也支持原生 PREPARE/EXECUTE 流程，但日常应用开发中极少直接使用，多见于存储过程或调试场景。
-
PREPARE stmt_name FROM preparable_stmt：preparable_stmt必须是单语句，且不能含变量引用 -
EXECUTE stmt_name USING @var1, @var2：参数只能是用户变量（@var），不能是字面量或表达式 -
DEALLOCATE PREPARE stmt_name：不显式释放也不会泄漏，但长连接中大量 PREPARE 可能占用服务端资源
注意：PREPARE 不处理客户端传入的参数，它只是服务端缓存执行计划的机制；真正的参数隔离和类型安全，仍依赖客户端 JDBC 驱动对 PreparedStatement 的实现。
