PHP 8 防 SQL 注入：strict_types=1 + 真实预处理 + 类型校验
在PHP 8环境下防范SQL注入，如果还停留在“用了PDO::prepare就万事大吉”的认知，那风险可就大了。真实情况是，必须将强类型声明、严格绑定逻辑与预处理语句三者结合，形成一个完整的防御链条。否则，数字型绕过、隐式类型转换、模拟预处理退化这些漏洞，依然会悄无声息地撕开防线。
为什么 PHP 8 的 strict_types=1 对防注入有实际作用
这里有个常见的误区：PHP 8默认依然是弱类型兼容模式。这意味着，像intval(“1 OR 1=1”)这样的操作，会“友好”地返回1，看似安全，实则掩盖了输入被污染的实质问题。而一旦在文件顶部启用declare(strict_types=1)，游戏的规则就彻底改变了：
- 函数参数的类型声明（例如
function getUserById(int $id): array）会在调用时立即生效，直接拒绝非整数输入，从根本上杜绝将恶意字符串当作整数参数传入的可能性。 - 像
(int)$_GET[‘id’]这类强制转换的“兜底”行为失效了。如果用户传递的是id[]=1这样的数组，它将无法被转换成int，程序会直接抛出TypeError，而不是静默地变成0，导致查不到数据却无任何错误提示的诡异情况。 - 当它与
PDO::PARAM_INT绑定参数协同工作时，如果绑定的变量实际上是个字符串，PDO将不会进行自动转换，而是根据类型严格处理，或报错或截断，从而暴露问题而非掩盖隐患。
禁用 PDO 模拟预处理：PDO::ATTR_EMULATE_PREPARES = false
这一点至关重要，却常被忽略。PHP 8的PDO默认仍开启PDO::ATTR_EMULATE_PREPARES = true。这意味着，你调用的prepare()方法，可能只是PHP自己在幕后做字符串替换，然后把拼接好的完整SQL语句发送给MySQL——这与手动拼接SQL在安全层面没有本质区别。
- 务必在创建PDO实例后立即设置：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false)，强制使用数据库服务端的原生预处理。 - 需要注意，如果数据库连接不支持服务端预处理（尽管现代MySQL都支持），
prepare()可能会返回false。此时不能直接链式调用->bindValue()，否则会引发致命错误，必须进行错误检查。 - 如何验证是否生效？可以在执行查询后，运行
SELECT @@session.prepared_stmt_count，如果使用了真实的预处理，这个计数值应该会增加。
mysqli_bind_param 的类型字符串陷阱与 PHP 8 类型校验协同
mysqli_stmt_bind_param()的第一个参数是一个类型字符串（比如“is”），它本身并不校验传入变量的实际类型，只是按照指定的内存布局“塞”值进去。这时，PHP 8的强类型系统就成了至关重要的前置防线：
立即学习“PHP免费学习笔记（深入）”；
- 在函数入口处声明参数类型，如
string $email, int $status，就能有效防止$_POST[‘status’]是字符串“active”时被误传进来。 - 绑定参数前，必须确保变量已赋值且类型严格匹配。例如，先进行
$status = (int)$_POST[‘status’];转换，再绑定，远比直接$stmt->bind_param(‘si’, $_POST[‘email’], $_POST[‘status’])要安全得多。 - 对于字段名、表名、
ORDER BY排序方向这类“非值”的SQL上下文，预处理占位符无能为力，必须依赖白名单校验。例如：$order = in_array($_GET[‘sort’], [‘name’, ‘created_at’]) ? $_GET[‘sort’] : ‘id’;
容易被忽略的边界点：空值、联合类型与 NULL 安全
PHP 8引入的联合类型（如?string、int|null）并非语法糖，它们直接关系到数据绑定的安全行为：
- 可空参数必须显式处理。例如函数定义为
function searchUser(?string $keyword): array，那么当$keyword === null时，就不能简单地用PDO::PARAM_STR绑定，而应该改用PDO::PARAM_NULL。 - 预处理负责的是参数化查询，而非语义校验。像
str_starts_with()、filter_var(…, FILTER_VALIDATE_EMAIL)这些PHP 8内置的验证函数，应该在绑定前就完成工作，而不是等到数据库执行时报错。 - 最后一个常见的坑：即使使用了预处理，
WHERE id IN (?)这种写法仍然是错误的。IN子句无法用单个占位符匹配一个数组，必须动态生成对应数量的占位符（如?, ?, ?）并绑定数组的每个元素，或者考虑改用临时表等方案。
