如何在Java中重构旧的Statement代码为PreparedStatement防SQL注入-SQL-PHP中文网

直接拼接字符串的statement必然不安全，因用户输入原样进入sql导致注入；改用preparedstatement需同时满足三条件：sql用?占位、参数用setxxx()设置、调用方式不变。

如何在java中重构旧的statement代码为preparedstatement防sql注入

为什么直接拼接字符串的`Statement`一定不安全

因为用户输入会原样进入SQL语句，数据库不区分“数据”和“代码”。比如用户名输入 ' OR '1'='1，拼成 "SELECT * FROM users WHERE name = '" + input + "'" 后，实际执行的是 SELECT * FROM users WHERE name = '' OR '1'='1'——整张表都被查出来了。这不是漏洞利用技巧，是字符串拼接的必然结果。

替换`Statement`时必须改三处地方

只把 Statement 换成 PreparedStatement 不够，漏掉任何一项都会白忙活：

SQL 字符串里所有动态值必须改成 ? 占位符（不能用 String.format 或 + 拼接）
所有参数必须通过 setXxx() 方法设置（比如 setString(1, username)），不能塞进 SQL 字符串里
原来用 executeQuery() 或 executeUpdate() 的地方，调用方式不变，但对象已经是 PreparedStatement

错误示例：String sql = "SELECT * FROM user WHERE id = " + id; → 即使后面用了 PreparedStatement，也完全无效。

`setXxx()` 方法选错会导致类型错误或截断

数据库字段类型和 setXxx() 方法要对得上，否则可能报错、丢数据，甚至绕过类型校验：

java-enterprise

Java企业开发专家，专注于Spring Boot、微服务架构和JVM优化。适用于：Java语言掌握、

下载

整数字段（如 INT）优先用 setInt()，别用 setString() —— 虽然多数驱动能隐式转换，但 Oracle 等数据库可能报 ORA-01722: invalid number
时间字段（如 TIMESTAMP）用 setTimestamp()，不是 setString() 或 setDate()；后者会丢失毫秒或时区信息
大文本（如 TEXT / CLOB）用 setCharacterStream() 或 setString()（看长度），避免 setBytes() 误转码

特别注意：setNull(int parameterIndex, int sqlType) 必须传 JDBC 类型常量，比如 Types.VARCHAR，不能传 0 或 null。

批量操作和 NULL 值最容易漏处理

批量插入/更新时，很多人只改了单条逻辑，忘了循环里每次都要重设参数：

String sql = "INSERT INTO log (msg, level) VALUES (?, ?)";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
    for (LogEntry e : entries) {
        ps.setString(1, e.getMsg());  // ✅ 每次都设
        ps.setString(2, e.getLevel());
        ps.addBatch();
    }
    ps.executeBatch();
}

NULL 值不能直接 ps.setString(1, null) —— 这其实合法，但某些老驱动会出错；更稳妥的是显式调用 ps.setNull(1, Types.VARCHAR)。

真正麻烦的是嵌套查询或动态 WHERE 条件：参数个数不确定时，得先收集条件再拼 ?，不能硬编码索引。这种场景往往需要重构 SQL 组装逻辑，而不是简单替换 API。