preparedstatement通过参数化查询将sql结构与用户输入物理隔离，使参数仅作为纯数据绑定，不参与sql解析，从而彻底防止sql注入；它不依赖转义，而是由驱动在协议层安全封装参数值。
PreparedStatement 本身不负责“转义”特殊字符，而是通过参数化查询机制彻底避免 SQL 注入和特殊字符解析问题——它把参数值当作纯数据传给数据库驱动，由驱动在协议层安全封装，不拼接进 SQL 字符串。
为什么不用手动转义
传统 Statement 拼接 SQL 时（如 "SELECT * FROM user WHERE name = '" + name + "'"），单引号、反斜杠、分号等会破坏 SQL 结构，必须手动 escape（如用双单引号、添加反斜杠）。而 PreparedStatement 把 SQL 模板和参数分离：
- SQL 模板只含占位符（
?），无用户数据参与字符串拼接 - 调用
setString(1, "O'Reilly")时，JDBC 驱动将该值以二进制或协议安全格式发送给数据库，数据库直接按字段类型接收，不经过 SQL 解析器的词法分析 - 像
O'Reilly、hello"world、1; DROP TABLE user这类输入，数据库都视为普通字符串值，不会触发语法解析或命令执行
哪些情况仍需注意
虽然 PreparedStatement 解决了 SQL 层面的注入风险，但以下场景仍需额外处理：
-
动态表名/列名/排序字段：这些不能用
?占位，必须拼接。应严格白名单校验（如if (!Arrays.asList("name", "age", "email").contains(fieldName)) throw ...） -
LIKE 模糊查询中的通配符：
%和_在数据库中是通配符。若想查字面量"10%"，需用 ESCAPE 子句并指定转义字符：SELECT * FROM product WHERE code LIKE ? ESCAPE ''，然后ps.setString(1, "10\%")（Java 字符串中写两个反斜杠） -
数据库特定字符集或 collation 影响：如 MySQL 的
utf8mb4支持 emoji，若连接未正确设置 charset，可能造成乱码或截断，但这属于连接配置问题，与 PreparedStatement 无关
正确使用示例
以下写法安全，无需任何手动转义：
String sql = "INSERT INTO user (name, email, bio) VALUES (?, ?, ?)";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
ps.setString(1, "O'Reilly"); // 含单引号 → 安全
ps.setString(2, "a@b.com"); // 正常邮箱 → 安全
ps.setString(3, "I said: "Hello""); // 含双引号、反斜杠 → 安全
ps.executeUpdate();
}
即使 bio 是 "Robert'); DROP TABLE users; --"，数据库也只会插入这一整段字符串，不会执行删除语句。
不推荐的“伪转义”操作
以下做法不仅多余，还可能引入 bug：
- 对参数值提前 replace 单引号（如
str.replace("'", "''")）→ 可能破坏原始语义，且不同数据库转义规则不同（PostgreSQL 用''，MySQL 可用'或''） - 在 SQL 模板里写
WHERE name = ''' || ? || '''→ 破坏参数化本意，可能引发类型错误或驱动不支持 - 用
StringEscapeUtils.escapeSql()（Apache Commons）→ 该工具已废弃，且仅模拟旧式转义，无法替代 PreparedStatement
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
