PreparedStatement通过预编译、参数绑定和资源复用实现高效与安全统一：参数必须用setXxx()绑定，禁止拼接SQL结构，动态部分需白名单校验，批量操作应复用实例并合理使用addBatch()。
Java 中 PreparedStatement 通过“结构与数据分离”实现高效与安全的统一——它不是单纯防注入的补丁，也不是只图快的缓存技巧，而是把预编译机制、参数绑定规范和资源复用策略三者拧在一起发挥作用。
参数必须全走 setXxx() 绑定
这是安全的底线。数据库先解析固定 SQL 模板（如 SELECT * FROM user WHERE id = ? AND status = ?），再把参数值通过独立通道传入。哪怕传入 "admin' OR '1'='1"，也只当普通字符串处理，不会触发语法解析。
- 数字、时间、布尔等类型不能用 setString 替代：必须用 setInt()、setTimestamp()、setBoolean()，避免隐式转换导致全表扫描或逻辑错误
- 空值不能直接传 null 给 setInt()：要用 setNull(index, Types.INTEGER)，否则抛 NullPointerException
- 所有用户输入，无论来自表单、URL 还是 API 请求体，都必须进 setXxx()，不漏一个
结构化内容严禁拼接，白名单校验不可少
占位符 ? 只支持值，不支持表名、列名、ORDER BY 字段、ASC/DESC 等 SQL 结构。一旦拼接，预编译立即失效。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 错误写法："SELECT * FROM " + tableName + " WHERE id = ?" —— 表名拼接即破防
- 安全做法：对动态结构做白名单校验，例如 if ("create_time".equals(sortField)) sql += " ORDER BY create_time DESC"
- 批量 IN 查询别手动拼 "?, ?, ?"：限制最大数量（如 ≤ 100），再用循环调用 addBatch()
复用实例才能兑现性能与安全双重价值
每次 new PreparedStatement，等于只用了“半截功能”：数据库端执行计划可能缓存，但客户端对象频繁创建会加重 GC 压力，还容易引发 Statement 泄漏。
立即学习“Java免费学习笔记（深入）”；
- 高频查询语句可封装为工具类成员变量（注意线程安全，建议配合 ThreadLocal 或连接池作用域管理）
- 批量插入/更新时：创建一次 PreparedStatement，反复调用 setXxx() → addBatch() → executeBatch()
- 避免在方法内临时创建、用完就丢；尤其在连接池环境下，频繁新建易触发资源告警
它管得住参数，管不住非参数位置
PreparedStatement 是核心防线，不是唯一防线。它能确保 WHERE 条件里的值 安全，但对 FROM 后的表名、SELECT 后的列名、GROUP BY / HAVING / LIMIT 的内容 无能为力。
- 这类动态结构必须配合白名单、正则校验或枚举限定
- 复杂场景建议叠加 ORM 框架（如 MyBatis 的 <bind> 或 JPA 的 Criteria API），进一步收口 SQL 构建逻辑
- 日志中避免打印完整 SQL（含参数值），防止敏感信息泄露
