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 泄漏。

• 高频查询语句可封装为工具类成员变量（注意线程安全，建议配合 ThreadLocal 或连接池作用域管理）
• 批量插入/更新时：创建一次 PreparedStatement，反复调用 setXxx() → addBatch() → executeBatch()
• 避免在方法内临时创建、用完就丢；尤其在连接池环境下，频繁新建易触发资源告警

它管得住参数，管不住非参数位置

PreparedStatement 是核心防线，不是唯一防线。它能确保 WHERE 条件里的值 安全，但对 FROM 后的表名、SELECT 后的列名、GROUP BY / HAVING / LIMIT 的内容 无能为力。

• 这类动态结构必须配合白名单、正则校验或枚举限定
• 复杂场景建议叠加 ORM 框架（如 MyBatis 的 或 JPA 的 Criteria API），进一步收口 SQL 构建逻辑
• 日志中避免打印完整 SQL（含参数值），防止敏感信息泄露

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南