SQL语句执行需经词法分析（切分token）和语法解析（构建AST）两步，只有生成合法抽象语法树后才进入优化与执行；拼接SQL会使恶意输入混入结构，而预处理通过分离SQL模板与参数数据，从源头阻断注入。
SQL语句在数据库里怎么“看懂”你写的那条查询
数据库执行一条SQL，不是靠“读句子”来理解的，而是走一套严格的词法分析 + 语法解析流程：先切分出关键字（SELECT、FROM）、标识符（表名、列名）、字面量（字符串、数字）、操作符（=、AND）等token，再按语法规则组装成抽象语法树（AST）。只有AST确定了，执行计划才能生成。
问题就出在拼接场景下：用户输入被直接塞进SQL字符串，比如 $sql = "SELECT * FROM users WHERE name = '$input'";。当 $input 是 admin' OR '1'='1，整个字符串变成：
SELECT * FROM users WHERE name = 'admin' OR '1'='1'
这时数据库“看到”的是一条完整、合法的SQL，它的AST里天然包含了一个恒真条件。它根本不知道哪部分是开发者本意，哪部分是攻击者塞进来的——因为所有内容都在同一个字符串里，混在同一个解析阶段。
prepare() 本质是把“结构”和“数据”拆到两个网络包里发
prepare() 不是 PHP 在本地做转义，而是让数据库服务器提前接收并编译一个**不含具体值**的模板。这个过程发生在客户端第一次调用时：
立即学习“PHP免费学习笔记（深入）”；
- PHP 发送纯结构：
PREPARE stmt1 FROM 'SELECT * FROM users WHERE id = ?'; - MySQL 解析该字符串，确认这是个合法的
SELECT语句，生成 AST 和执行计划，并缓存它 - 后续
execute()时，PHP 单独发一个二进制数据包，只含参数值（如整数123），不带任何 SQL 语法字符 - MySQL 直接把值填进已编译好的 AST 的占位符位置，跳过词法/语法重解析
这意味着：单引号、分号、--、UNION 这些注入关键字符，永远进不了 SQL 解析器的视野——它们只是数据包里的原始字节，不会被当作 token 切分，更不会参与 AST 构建。
命名参数和问号参数在词法层面没有区别
有人觉得 :name 比 ? “更安全”，其实不是。PDO 或 MySQLi 底层都会把命名参数转成位置参数再发给 MySQL。真正起作用的是“分离时机”，不是占位符写法。
但要注意实际使用中的坑：
-
bindValue()和bindParam()行为不同：bindParam()是引用绑定，如果变量后续被改写，执行时用的是新值；bindValue()是值拷贝，更可控 - 不能对表名、列名、排序方向（
ORDER BY后）用占位符——这些属于 SQL 结构，不是数据。必须白名单校验后硬编码，比如$order = in_array($_GET['sort'], ['id', 'name', 'email']) ? $_GET['sort'] : 'id'; - PDO 默认不开启
PDO::ATTR_EMULATE_PREPARES = false，即启用 MySQL 原生预处理；若设为true（模拟预处理），PHP 会自己拼接字符串再发给 MySQL，失去防御能力
为什么 addslashes() 或 utf8mb4 + htmlspecialchars 都挡不住真正的注入
因为它们全在 PHP 层做文章，而数据库解析器根本不认这些“防护”。addslashes() 只加反斜杠，但 MySQL 在宽字节（如 gbk）或特定 SQL_MODE 下可能忽略它；htmlspecialchars() 是为 HTML 输出设计的，对数据库解析器完全无效。
唯一可信的隔离点，是数据库服务端的词法解析入口。只要用户输入的数据没和 SQL 模板一起进解析器，注入就不可能发生——prepared statement 正是卡在这个环节上做切割的。
最常被忽略的一点：哪怕用了 prepare()，如果连接字符集没设对（比如 PHP 告诉 MySQL 是 latin1，但实际传 utf8mb4 数据），某些边界 case 下仍可能触发解析歧义。务必在 DSN 中显式指定：mysql:host=localhost;dbname=test;charset=utf8mb4。
