预处理语句本身不防注入，真正起作用的是参数绑定机制；只有SQL模板完全固定、所有用户输入均通过?占位符+EXECUTE USING（或各语言对应绑定方法）传入，MySQL才能在服务端彻底隔离结构与数据。
预处理语句本身不防注入，真正起作用的是参数绑定机制——只有 SQL 模板完全固定、所有用户输入都走 ? 占位符 + EXECUTE USING（或各语言对应的 setString() / bind_param()），MySQL 才能在服务端彻底隔离结构与数据。
为什么 PREPARE + 字符串拼接仍是高危操作
很多人误以为只要调用了 PREPARE 就安全，结果写出类似这样的代码：
SET @sql = CONCAT("SELECT * FROM users WHERE name = '", $_GET['name'], "'");
PREPARE stmt FROM @sql;
EXECUTE stmt;这和裸拼接没区别：恶意输入 admin' OR '1'='1 会直接进入 SQL 解析器。MySQL 的 PREPARE 只对静态模板生效；一旦变量提前拼进字符串，预编译就失去意义。
-
PREPARE不会对@sql变量内容做二次解析或校验，它只把整个字符串当原始 SQL 处理 - 加引号、用
mysql_real_escape_string()、甚至十六进制编码都挡不住宽字节截断、多语句执行等绕过手法 - 真正防护的前提是 SQL 模板中不含任何用户输入，只含
?
各语言中 PreparedStatement 的正确绑定方式
不同语言底层协议一致，但占位符写法和绑定逻辑容易出错：
- Java：必须用
Connection.prepareStatement()创建，再调用setString(1, value)等类型明确的方法；"WHERE name = '" + input + "'"是错的 - PHP（PDO）：
prepare("SELECT * FROM t WHERE id = ?")后必须用execute([$id])或bindValue(':id', $id)；sprintf()拼接一律无效 - Python（PyMySQL）：只认
%s占位符，且不能加引号：cursor.execute("WHERE name = %s", (name,))；f-string或.format()是高危操作 - Node.js（mysql2）：默认启用参数化，但若显式设
options.multipleStatements: true又拼接用户输入，就会绕过防护
哪些地方 PreparedStatement 根本防不住
PreparedStatement 只保护「参数值」，不保护「SQL 结构」。以下场景必须额外校验：
-
ORDER BY ?、GROUP BY ?、TABLE ?、LIMIT ?, ?中第一个参数——数据库会直接报错或忽略占位符 - 排序字段必须白名单校验，比如只允许
status、created_at、score；不能直接插变量 - 动态表名（如分表）需正则严格过滤：
/^[a-z_][a-z0-9_]{1,63}$/i，更稳妥的是查配置中心白名单 -
IN (?, ?, ?)的占位符数量必须提前确定，生成逻辑本身不能拼用户输入
最容易被忽略的一点：预编译安全的前提是「所有用户可控输入都走参数绑定」——漏掉一个字段、拼一次表名、手写一个 ORDER BY，整条防线就垮了。
