SQL预编译语句的核心安全价值在于严格分离SQL结构与用户数据，使输入仅作参数值处理而不参与语法解析，从而彻底阻断SQL注入；其机制包括模板预解析、参数类型绑定、执行计划复用，并需确保SQL模板固定且参数通过驱动接口传入。
SQL 预编译语句（Prepared Statement）的核心安全价值，在于从根本上切断 SQL 注入的路径——它把**SQL 结构**和**用户数据**在数据库驱动层就严格分离，让用户输入永远只被当作参数值处理，而不会被解析为可执行的 SQL 语法。
防止 SQL 注入的底层机制
普通拼接 SQL 时，用户输入直接嵌入字符串，数据库无法区分“代码”和“数据”。预编译则分两步执行：
- 先发送带占位符（如 ? 或 :name）的 SQL 模板给数据库，数据库立即进行语法解析、查询计划生成，并缓存执行计划；
- 再单独传入参数值，数据库按类型严格绑定，不经过 SQL 解析器，不参与语句拼接。
即使参数里含 ' OR 1=1 --，数据库也只会把它当做一个字符串字面量，不会触发逻辑绕过。
不只是防注入：附带的安全与性能收益
预编译不是“防注入专用工具”，它的设计天然带来多重加固效果：
- 类型强制校验：驱动会按声明的参数类型（如 INTEGER、VARCHAR）做转换或报错，非法格式（如用字符串传 ID）在绑定阶段就被拦截；
- 避免引号逃逸失误：开发者无需手动加引号、转义单引号或反斜杠，彻底消除因 escape 不全导致的漏洞；
- 服务端执行计划复用：同结构语句多次执行时，数据库可复用已编译的执行计划，降低解析开销，间接减少因高负载导致的异常行为风险。
关键使用前提：必须全程由驱动/框架完成绑定
预编译的安全性完全依赖实现方式。以下做法会直接失效：
- 用字符串拼接构造 SQL 模板（如 "SELECT * FROM user WHERE id = " + input），再套用 PreparedStatement；
- 将用户输入用于表名、字段名、ORDER BY 子句等无法参数化的位置（这些需白名单校验或硬编码）；
- 使用不支持真正预编译的旧驱动（如某些 JDBC MySQL 低版本未开启 useServerPrepStmts=true）。
真正安全的前提是：SQL 模板固定、占位符位置固定、参数通过 setString()、setInt() 等接口传入。
不是银弹，但它是防御纵深中最可靠的一环
预编译不能替代输入过滤、最小权限原则、错误信息脱敏等其他措施，但它属于“一次正确，处处生效”的基础设施级防护。只要用对了，哪怕业务逻辑复杂、前端校验被绕过、日志泄露原始输入，SQL 层依然牢不可破。在现代 ORM（如 MyBatis 的 #{}、Hibernate 的命名参数）和主流数据库驱动中，它已是默认推荐实践。
