PreparedStatement 能防 SQL 注入因其参数由驱动单独传输、数据库分离处理模板与数据，不参与语法解析；占位符仅支持值，表名列名等须白名单校验；类型匹配和空值处理需严格遵循 JDBC 规范。
为什么 PreparedStatement 能防 SQL 注入
因为它的参数不是拼进 SQL 字符串里的，而是由数据库驱动在预编译阶段就单独传给数据库服务器的。数据库会把 SQL 模板和参数分开处理——模板走解析、优化、生成执行计划；参数只当数据用，不参与语法分析。
这意味着哪怕你传 "admin' OR '1'='1" 这种字符串，数据库也只会把它当一个普通用户名值去查，不会去“执行”里面的逻辑。
常见错误现象：
用 Statement + 字符串拼接，比如 "SELECT * FROM user WHERE name = '" + name + "'"，一遇到带单引号的输入就崩，或者被绕过权限校验。
- 必须用
?占位符，不能写成"WHERE name = '?'"（引号包住问号就失效了） - 占位符只支持**值**，不支持表名、列名、排序方向（
ORDER BY后的ASC/DESC）等结构信息 - 不同数据库对批量参数数量有限制（如 MySQL 默认 max_allowed_packet 影响一次 setXXX 调用上限）
setString() 等方法怎么选，类型错会怎样
每个 setXxx() 方法不只是“设个值”，它还告诉 JDBC 驱动：这个参数该按什么 JDBC 类型传给数据库。类型匹配不上，轻则报错，重则隐式转换出错（比如把数字当字符串传，可能触发全表扫描）。
立即学习“Java免费学习笔记（深入）”；
使用场景举例：
查用户 ID 是整数，但前端传的是字符串；或时间字段存的是 TIMESTAMP，你却用 setString() 传 "2024-01-01" —— 数据库可能解析失败，或存成 1970 年零点。
-
setString()对应VARCHAR/TEXT；setInt()对应INT；setTimestamp()对应TIMESTAMP - 不确定类型时，优先看数据库字段定义，而不是 Java 变量类型（比如 Java 用
Long存 ID，但 DB 是BIGINT，就该用setLong()） - 空值要用
setNull(index, Types.INTEGER)，不能传null给setInt()，否则 NPE
预编译真的每次都走缓存吗
不一定。是否复用执行计划，取决于数据库是否开启预编译缓存，以及 SQL 模板是否完全一致（包括空格、换行、大小写）。JDBC 层的 PreparedStatement 对象只是个句柄，背后能不能省解析开销，得看数据库配置和驱动行为。
性能影响明显的情况：
MySQL 默认关闭服务端预编译（useServerPrepStmts=false），此时只是客户端做参数转义，执行计划仍每次生成；PostgreSQL 则默认启用，且对相同模板自动缓存计划。
- 检查是否真走了预编译：MySQL 开启
general_log，看日志里是Execute还是重复Prepare - 连接 URL 加
?useServerPrepStmts=true&cachePrepStmts=true（MySQL）才能让服务端真正复用 - SQL 模板里别混用
"SELECT *"和"SELECT id,name"——字段列表不同，就是两条新语句
动态列名 / 表名怎么安全处理
PreparedStatement 的 ? 占位符对表名、列名、ORDER BY 子句完全无效。硬塞进去会直接报错：java.sql.SQLException: Parameter index out of range 或更隐蔽的语法错误。
这不是 PreparedStatement 的缺陷，而是 SQL 标准决定的：结构信息必须在预编译前确定，不能运行时动态改变语法树。
- 白名单校验是最靠谱的方式：把允许的列名写死在代码里，用
switch或Map映射 - 避免用反射或配置文件读取列名后直接拼接，除非你 100% 控制输入源（比如内部管理后台的固定下拉选项）
- 如果真要动态，先用正则
^[a-zA-Z_][a-zA-Z0-9_]*$过滤，再加反引号包裹（MySQL）或双引号（PostgreSQL），例如"ORDER BY `" + safeColumn + "` DESC"
事情说清了就结束。最常被忽略的一点：很多人以为用了 PreparedStatement 就万事大吉，结果在日志打印、监控埋点、动态 SQL 拼接这些地方又把参数裸露出去，照样泄露敏感信息或引发注入。防注入不是加个类名就完事，是整个数据流转链路的约束。
