PHP防止SQL注入的核心是使用PDO或MySQLi预处理语句实现SQL与数据分离，辅以输入验证、最小权限、禁用错误显示及关闭模拟预处理等深度防御措施。
PHP 8.4 接口防止 SQL 注入，核心是杜绝字符串拼接 SQL，坚持用预处理语句 + 严格输入控制。PHP 8.4 本身不新增防护机制，但强化了类型系统和错误提示，让旧漏洞更易暴露、安全写法更清晰——关键在你怎么用。
用 PDO 预处理语句（推荐首选）
PDO 是 PHP 8.4 中最通用、最安全的数据库接口，支持 MySQL、PostgreSQL、SQLite 等，且自动处理字符集与参数绑定。
- 连接时强制指定
charset=utf8mb4，防宽字节注入：$pdo = new PDO("mysql:host=localhost;dbname=test;charset=utf8mb4", $user, $pass, [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]); - 只用命名占位符（如
:email）或问号（?），绝不拼接变量到 SQL 字符串中：$stmt = $pdo->prepare("SELECT id, name FROM users WHERE status = :status AND created_at > ?"); - 用
execute()传数组绑定值，类型由 PDO 自动推断：$stmt->execute(['status' => 'active', $_POST['since'] ?? '2020-01-01']); - 对
LIKE查询，通配符必须在 PHP 层加，不能塞进占位符：$keyword = '%' . trim($_GET['q']) . '%'; $stmt->execute([$keyword]);
输入验证必须前置，不能依赖“后面再过滤”
预处理语句防注入，但不防非法数据。接口收到参数后立即校验，失败直接返回错误，不进数据库层。
- 整数 ID：用
filter_var($id, FILTER_VALIDATE_INT, ['options' => ['min_range' => 1]])，不是(int)强转（会静默转 0） - 邮箱/URL：用
filter_var($email, FILTER_VALIDATE_EMAIL)或FILTER_VALIDATE_URL - 枚举类字段（如
sort、order）：只允许白名单值：$sort = in_array($_GET['sort'] ?? '', ['name', 'created_at', 'score']) ? $_GET['sort'] : 'created_at'; - 自由文本长度限制：用
strlen()检查，超长直接拒绝，避免拖慢查询或埋藏异常
权限与环境配置不可省略
即使代码写得再严，数据库账号权限过大或错误信息泄露，也会让攻击者获得突破口。
立即学习“PHP免费学习笔记（深入）”；
- 数据库账号只授予当前接口需要的权限，例如只读接口就只给
SELECT，禁用DROP、GRANT、UNION SELECT相关操作 - 生产环境关闭错误显示：
ini_set('display_errors', '0'); error_reporting(0);
同时开启错误日志：ini_set('log_errors', '1'); ini_set('error_log', '/var/log/php-app-security.log'); - 禁用模拟预处理（尤其 MySQL）：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);，确保真正走服务端预处理
不建议依赖的“备用方案”
这些方法在 PHP 8.4 中已明确不推荐作为主要防护手段：
-
mysqli_real_escape_string()：仅适用于未启用预处理的老代码迁移，不能替代 prepare -
addslashes()：完全不可靠，宽字节、多编码场景下极易绕过 - 黑名单过滤（如删掉
'、;）：攻击向量太多，永远追不上，应彻底放弃 - ORM（如 Laravel Eloquent）：虽内置预处理，但若误用
DB::raw()或拼接查询仍会中招，不能当“免检金牌”
