使用 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 模拟参数替换——这会退化为字符串拼接，失去防护能力。
必须显式关闭模拟，并确认驱动支持原生预处理：
立即学习“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 变体或编码绕过
真正安全的整数处理是：强制类型转换 + 边界校验 + 预处理绑定，三者缺一不可。
