PreparedStatement仅在正确使用时才构成第一道可靠防线，其无法防御涉及SQL结构（如表名、排序字段）的高级注入变种，必须配合白名单校验、类型强约束与分层防御。
PreparedStatement 本身不能直接防住“高级 SQL 注入变种”，它只在**被正确使用时**才构成第一道可靠防线。所谓“高级变种”，比如利用 ORDER BY 字段、UNION SELECT 配合盲注、时间延迟注入、或结合数据库特定语法（如 MySQL 的 LOAD_FILE、PostgreSQL 的 pg_read_file）等，其突破口往往不在参数位置，而恰恰是 PreparedStatement **管不到的地方**——也就是 SQL 结构本身。
结构化内容必须白名单校验，不能靠 ? 占位
占位符 ? 只支持值（value），不支持标识符（identifier）。这意味着以下写法全是危险的，且 PreparedStatement 完全无效：
-
"SELECT * FROM " + tableName + " WHERE id = ?"—— 表名拼接，直接破防 -
"ORDER BY " + sortField + " " + sortOrder—— 排序字段和方向若来自请求参数，可能执行ORDER BY id; DROP TABLE users-- -
"WHERE status IN (" + generatePlaceholders(userIds.size()) + ")"—— 占位符个数动态拼接，若未限制长度或校验格式，可能触发超长 payload 或驱动解析异常
安全做法：对所有结构化输入做硬编码白名单匹配。
- 表名只允许
"user"、"order"、"log"等预设值 - 排序字段限定为
"created_at"、"status"、"score"，排序方向只接受"ASC"或"DESC" - IN 子句最多支持 100 个值，用循环
addBatch()，不拼 SQL 字符串
类型强约束 + 空值显式处理，堵住隐式转换漏洞
攻击者有时会利用类型混淆绕过基础防护。例如：
立即学习“Java免费学习笔记（深入）”；
- 把整型 ID 参数传成字符串
"1 OR 1=1"，若后端用setString(1, input)绑定到 INT 字段，部分驱动+数据库可能隐式转为数字并截断，导致逻辑异常 - 传
null给setInt()直接抛NullPointerException，暴露堆栈或引发服务中断
正确做法：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- ID、状态码等明确为整型的字段，必须用
setLong()或setInt()，不滥用setObject() - 允许为空的数值字段，用
ps.setNull(index, Types.BIGINT)，而非传null - 时间字段严格用
setTimestamp()，传java.time.Instant或java.sql.Timestamp，不传字符串
动态条件拼接要分层，SQL 模板与参数绑定严格隔离
搜索接口常需支持“姓名/邮箱/手机号任选其一”，这不是单条固定 SQL 能覆盖的。错误做法是写一个大 SQL 并用 OR 全部兜底；更糟的是用字符串拼接加 ? 混用。
推荐结构：
- 用
StringBuilder动态构建WHERE片段（仅限字段名、操作符、固定值），例如：sb.append(" AND status = ?") - 所有用户输入值，一律通过
setXxx()绑定，索引按顺序递增 - 最终 SQL 是确定结构 + 确定数量占位符，例如：
"SELECT * FROM user WHERE 1=1" + dynamicWhere
这样既保持灵活性，又确保每个变量都走预编译通道。
别把 PreparedStatement 当万能盾，它只是起点
即使 PreparedStatement 用得滴水不漏，仍需组合其他防御层：
- 分页参数
limit、offset做范围校验（如limit≤ 100） - 敏感操作（如导出、删除）增加二次确认或 RBAC 权限校验
- 密码比对不用明文，改用
BCryptPasswordEncoder.matches() - 开启数据库审计日志，监控异常高频查询或含
UNION/EXEC/LOAD_FILE的语句
不复杂但容易忽略。
