PreparedStatement 在 Java 21 中仍有效防 SQL 注入，因其预编译机制由 JDBC 驱动和数据库协同实现，但前提是所有用户输入均通过 setXxx() 绑定、SQL 模板无字符串拼接。
PreparedStatement 在 Java 21 中仍是防 SQL 注入的首选机制，但它本身不自动免疫——是否安全，取决于你怎么写、怎么传、在哪用。只要参数全走 setXxx()、SQL 模板里没有拼接变量，就基本能拦住绝大多数注入。
为什么 PreparedStatement 在 Java 21 里依然有效？
Java 21 没改变 JDBC 规范的核心行为：PreparedStatement 的预编译逻辑仍在驱动层（如 MySQL Connector/J 8.3+、PostgreSQL JDBC 42.7+）中严格执行。数据库收到的是已解析的执行计划 + 独立绑定的数据包，恶意字符串（比如 ' OR 1=1 --）只会被当作文本值存进字段，不会参与语法树构建。
注意：这不是 Java 版本的功劳，而是 JDBC 驱动和数据库协同的结果。Java 21 只是继续支持这套契约，没削弱也没增强底层安全性。
- ✅ 有效前提：SQL 字符串里所有用户可控部分都用
?占位，且只通过setString()、setInt()等方法赋值 - ❌ 无效场景：哪怕只拼接一个变量，比如
"WHERE name = '" + name + "' AND status = ?"，整个防护就崩了 - ⚠️ 兼容性提醒：Java 21 默认启用
--enable-preview不影响 JDBC；但若你用了自定义 ClassLoader 加载老版驱动（如 mysql-connector-java 5.1），可能触发Unsupported major.minor version错误——得换 8.0+ 驱动
IN 子句怎么写才不破防？
WHERE id IN (?) 只能匹配单个值，这是硬限制。直接传逗号分隔字符串（如 "1,2,3"）会被当做一个整体字面量，查不出数据；用字符串拼接生成 IN (?,?,?) 又容易漏转义。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
推荐做法是动态构造占位符数量，再逐个绑定：
List<Integer> ids = Arrays.asList(101, 102, 105);
String placeholders = String.join(",", Collections.nCopies(ids.size(), "?"));
String sql = "SELECT * FROM orders WHERE user_id IN (" + placeholders + ")";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
for (int i = 0; i < ids.size(); i++) {
ps.setInt(i + 1, ids.get(i));
}
// execute...
}- 别用反射或工具类“自动绑定集合”——很多 ORM 封装（如 MyBatis 的
<foreach></foreach>）底层也是这么干的，但手写更可控 - 如果
ids可能为空，得单独处理：WHERE 1=0或改用临时表/UNION ALL 方案，避免IN ()语法错误 - MySQL 对
IN参数个数有限制（默认 max_allowed_packet 影响），超 1000 项建议分批或走中间表
ORDER BY / GROUP BY / 表名列名能不能用 ?
不能。PreparedStatement 的 ? 只接受“标量值”，不接受标识符（identifier）。你写 ORDER BY ?，数据库会把输入当字符串字面量排序，比如按字面值 "created_at" 而不是按字段 created_at 的内容排——结果永远是单行或乱序，还可能报 SQLException: Parameter index out of range。
正确做法是白名单校验 + 字符串拼接（但仅限于校验后的安全值）：
String allowedSortFields = "id,name,created_at";
String sortField = request.getParameter("sort");
if (!allowedSortFields.contains(sortField)) {
throw new IllegalArgumentException("Invalid sort field");
}
String sql = "SELECT * FROM users ORDER BY " + sortField + " DESC";
// 后续仍要用 PreparedStatement 绑定其他参数，如 WHERE status = ?- 白名单必须是静态字符串或枚举，不能从配置文件读取后不做校验就拼接
-
ORDER BY ? DESC这种写法在某些旧驱动里会静默失败，Java 21 下多数驱动会明确抛异常，别抱侥幸心理 - 涉及权限控制时（如租户隔离），表名也得走白名单，例如只允许
"tenant_123_users"、"tenant_456_logs"这类格式
最容易被忽略的三个破防点
很多团队用了 PreparedStatement 还被扫出高危漏洞，问题往往不在主流程，而在边缘逻辑：
- 日志打印 SQL：有人为了调试把
sql + " with params: " + username打进日志，结果攻击 payload 直接落盘——应只记录模板，参数打码 - 批量更新用
addBatch()时混用拼接：比如循环里ps.addBatch("UPDATE t SET x = " + val + " WHERE id = ?")，前面那截val就是注入口 - 时间类型陷阱：Java 21 的
LocalDateTime传给setTimestamp()时若时区不一致，可能查不到数据，但这不是注入；真危险的是把用户输入的时区字符串（如"UTC'; DROP TABLE users; --"）拼进CONVERT_TZ()函数调用
真正的防线不在某一行代码，而在于每次拼字符串前，问一句：这个变量是不是用户输入？它会不会出现在 SQL 结构位置？答案为“是”，就必须进白名单或拒掉。
