当前位置：首页 > 文章列表 > 文章 > php教程 > 为什么PHP的prepared statement能防御SQL注入_分析词法解析原理

为什么PHP的prepared statement能防御SQL注入_分析词法解析原理

2026-05-25 09:53:14 0浏览收藏

小伙伴们对文章编程感兴趣吗？是否正在学习相关知识点？如果是，那么本文《为什么PHP的prepared statement能防御SQL注入_分析词法解析原理》，就很适合你，本篇文章讲解的知识点主要包括。在之后的文章中也会多多分享相关知识点，希望对大家的知识积累有所帮助！

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 发送纯结构： 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。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~