预编译语句是修复SQL注入的强制基线做法，因其在数据库层面将SQL结构与参数物理隔离，使用户输入仅作为纯数据绑定而不参与语法解析；字符串拼接则导致数据库无法区分代码与数据，恶意输入如admin' --会直接篡改语句逻辑。
预编译语句（PreparedStatement）不是“可选加固项”，而是修复SQL注入的**强制基线做法**——只要涉及用户输入拼进SQL，就必须用它，没有例外。
为什么字符串拼接必然导致SQL注入
漏洞根源在于：数据库无法区分“代码”和“数据”。当你写 "SELECT * FROM users WHERE username = '" + username + "'"，恶意输入 admin' -- 会直接变成合法SQL的一部分，注释掉后续密码校验逻辑。数据库执行的是最终拼出的整条语句，而不是你“本意”想执行的那条。
常见错误现象包括：
- 登录页输
' OR '1'='1就能绕过验证 - URL里加
id=1 UNION SELECT password FROM users能查出其他用户密码 - 错误信息里暴露表名、字段名甚至数据库版本（如
MySQL 8.0.33）
Java中正确使用PreparedStatement的三步
核心是：**占位符 + 类型绑定 + 不拼接**。下面以JDBC为例：
错误写法（仍在拼接）：String sql = "SELECT * FROM users WHERE username = '" + username + "'";
正确写法：
- 用
?占位，不插变量：String sql = "SELECT * FROM users WHERE username = ? AND password = ?"; - 调用
conn.prepareStatement(sql)获取PreparedStatement对象 - 用类型明确的方法设参：
pstmt.setString(1, username); pstmt.setString(2, password);（索引从1开始）
注意：setString 不是“转义字符串”，而是把值作为纯数据传给数据库驱动，由驱动按协议编码后发送——数据库收到的就是独立参数，不是SQL语法的一部分。
PHP里mysqli_prepare和PDO::prepare的关键区别
两者都支持预编译，但默认行为不同，容易踩坑：
-
mysqli_prepare：必须配合mysqli_stmt_bind_param使用，且参数类型需显式声明（如"ss"表示两个字符串）；漏掉绑定或类型错，会静默失败或报错mysqli_stmt::execute(): (HY000/2031) No data supplied for parameters in prepared statement -
PDO::prepare：更灵活，支持命名占位符（如:username），且execute()可直接传数组；但要注意PDO::ATTR_EMULATE_PREPARES默认为true（即PHP模拟预编译），这会退化为字符串拼接！必须关掉：$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
性能影响：真实预编译（emulate_prepares=false）会让SQL模板在数据库端缓存执行计划，重复查询更快；模拟模式则无此优势，且失去防注入保障。
哪些场景容易漏掉预编译
开发者常误以为“只读查询”或“数字ID”安全，其实只要输入未被隔离，就危险：
- 分页参数：
ORDER BY ?不合法（列名不能参数化），应白名单校验$_GET['sort']是否在['id', 'name', 'created_at']中 - IN 子句：
WHERE id IN (?)只能绑一个值；多个值需动态生成对应数量的?（如WHERE id IN (?, ?, ?)），再逐个绑定 - 表名/列名：无法参数化，必须用白名单或正则严格匹配（如
^[a-zA-Z_][a-zA-Z0-9_]*$） - 动态条件拼接：先收集条件，再构建含固定占位符的SQL，避免运行时拼接字段名或操作符
最易被忽略的一点：**ORM框架（如MyBatis、Hibernate）的 ${} 或 !{} 语法是字符串替换，不是预编译**——它们会重蹈拼接覆辙，必须改用 #{} 或命名参数。
