使用 mysqli::prepare() + bind_param() 或 PDO::prepare() + execute()（禁用模拟预处理）是最直接有效的防SQL注入方式，通过预处理机制彻底分离SQL结构与数据，从执行层面杜绝注入可能。

用 mysqli::prepare() + bind_param() 是最直接有效的防注入方式

PHP 原生 MySQLi 扩展的预处理语句能彻底分离 SQL 结构与数据，让数据库引擎在解析阶段就拒绝恶意拼接。不是“过滤输入”，而是从执行机制上杜绝注入可能。

常见错误是只做 mysqli_real_escape_string() 或简单 str_replace()，这些对绕过型 payload（比如宽字节、十六进制编码、注释符组合）完全无效。

• 必须使用 prepare() 创建语句对象，再用 bind_param() 绑定变量，不能把变量直接拼进 SQL 字符串
• 参数类型标识要准确："s"（字符串）、"i"（整数）、"d"（浮点）、"b"（BLOB），类型不匹配可能导致绑定失败或隐式转换漏洞
• 注意连接字符集：确保 mysqli_set_charset($conn, 'utf8mb4') 已调用，否则宽字节注入仍可能发生

$stmt = $mysqli->prepare("SELECT * FROM users WHERE username = ? AND status = ?");
$stmt->bind_param("si", $username, $status);
$username = $_GET['user'] ?? '';
$status = (int)($_GET['active'] ?? 1);
$stmt->execute();
$result = $stmt->get_result();

PDO 的 prepare() + execute() 更灵活但要注意默认模式

PDO 默认启用模拟预处理（PDO::ATTR_EMULATE_PREPARES = true），此时 SQL 并未真正发给 MySQL，而是由 PHP 模拟参数替换——这会退化为字符串拼接，失去防护能力。

必须显式关闭模拟，并确认驱动支持原生预处理：

• 初始化时设置 PDO::ATTR_EMULATE_PREPARES => false
• 检查 $pdo->getAttribute(PDO::ATTR_CLIENT_VERSION) 和 MySQL 版本（5.1.17+ 支持完整原生预处理）
• 命名参数（:name）比问号占位符更易读，但底层安全等级一致

$pdo = new PDO($dsn, $user, $pass, [
    PDO::ATTR_EMULATE_PREPARES => false,
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
]);
$stmt = $pdo->prepare("INSERT INTO logs (ip, action) VALUES (:ip, :action)");
$stmt->execute(['ip' => $_SERVER['REMOTE_ADDR'], 'action' => 'login']);

不要用 mysql_*() 函数，它们已废弃且无法预处理

PHP 7.0 起已移除所有 mysql_connect()、mysql_query() 等函数，任何还在用它们的代码不仅有注入风险，还会直接报致命错误。

即使加了 mysql_real_escape_string()，也挡不住如下攻击：

• admin'

  

  -- （注释掉后续校验）
• admin' OR SLEEP(5) #（延时盲注）
• 1' UNION SELECT password FROM users #（联合查询）

迁移路径只有两条：改用 MySQLi 或 PDO，没有中间选项。

过滤函数如 htmlspecialchars() 不解决 SQL 注入

这个函数只用于输出 HTML 上下文，防止 XSS，对 SQL 查询毫无作用。把它用在查询前，等于给子弹套了个纸盒子——看起来像防护，实际一打就穿。

典型误用场景：

• 对用户输入先 htmlspecialchars() 再拼进 SQL（依然可注入）
• 用 intval() 处理 ID 但没校验返回值是否为 0（intval('1 OR 1=1') 返回 1）
• 用正则白名单过滤但遗漏了 Unicode 变体或编码绕过

真正安全的整数处理是：强制类型转换 + 边界校验 + 预处理绑定，三者缺一不可。