正确使用 preparedstatement 防 sql 注入的关键是所有用户输入必须通过 setxxx() 绑定，确保 sql 结构与数据彻底分离；表名、列名等结构化内容须白名单校验，禁止字符串拼接，且需复用实例以发挥性能优势。
用对 PreparedStatement 才能真正防住 SQL 注入。关键不在“用了没”，而在“怎么用”——所有用户输入必须走 setXxx() 绑定，SQL 结构和数据必须彻底分离。
所有参数都必须用 setXxx() 绑定
PreparedStatement 防注入的核心机制是：数据库先解析固定结构的 SQL 模板，再把参数值通过独立通道传入，值永远不参与语法解析。哪怕传入 "admin' OR '1'='1"，数据库也只当它是字符串值查，不会执行其中逻辑。
- 正确写法：
SELECT * FROM user WHERE name = ? AND status = ?，再调用pstmt.setString(1, userInput)和pstmt.setInt(2, status) - 数字、时间、布尔等类型不能例外：必须用
setInt()、setTimestamp()、setBoolean()，避免隐式转换引发漏洞或全表扫描 - 空值要用
setNull(index, Types.INTEGER)，不能传null给setInt()，否则抛NullPointerException
表名、列名、排序字段等结构内容严禁拼接
占位符 ? 只支持值，不支持 SQL 结构。一旦在 SQL 字符串里拼接用户可控内容（如表名、ORDER BY 字段、ASC/DESC），预编译立即失效。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 错误示例：
"SELECT * FROM " + tableName + " WHERE id = ?"—— 表名拼接即破防 - 安全做法：对动态结构做白名单校验，例如：
if ("name".equals(sortField)) sql += " ORDER BY name"; - 批量
IN查询不要手动拼"?, ?, ?"，应限制最大数量（如 ≤ 100），再用循环addBatch()
复用 PreparedStatement 实例才能发挥性能与安全双重优势
预编译的价值分两层：数据库端缓存执行计划 + 客户端复用对象。每次 new 一个 PreparedStatement，等于只用了“半截功能”，还可能引发 Statement 泄漏和 GC 压力。
- 批量插入/更新时：创建一次 PreparedStatement，反复调用
setXxx() → addBatch() → executeBatch() - 高频查询语句可封装为工具类成员变量（注意线程安全，建议配合 ThreadLocal 或连接池作用域管理）
- 避免在方法内临时创建、用完就丢；尤其在连接池环境下，频繁新建易触发资源告警
PreparedStatement 是核心防线，不是唯一防线
它管得住参数位置，但管不住非参数位置。完整防护需组合其他措施：
- 对非参数内容（如分页参数
limit、offset，排序方向）做严格白名单或范围校验 - 密码等敏感字段不用明文比对，改用 BCrypt 加盐哈希验证
- ORM 框架（如 MyBatis、Hibernate）默认启用参数绑定，但仍需警惕
${}语法拼接（MyBatis 中#{}安全，${}危险） - 前端传参仍需服务端二次校验，不信任任何来源：URL、表单、Header、Cookie
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
