使用 mysqli_prepare + bind_param 或 PDO 预处理语句可有效防止 SQL 注入，但必须正确设置类型、禁用模拟预处理、避免在非字符串上下文使用 escape，并对动态表名列名采用白名单校验。
用 mysqli_prepare + bind_param 替代拼接字符串
直接把用户输入塞进 SQL 里（比如 "SELECT * FROM users WHERE id = $_GET['id']"）等于给攻击者递刀。PHP 原生支持预处理语句，核心是把 SQL 结构和数据彻底分开。
实际操作中，必须分两步走：
- 先调用
mysqli_prepare($conn, "SELECT * FROM users WHERE name = ?")，问号占位，不带任何用户数据 - 再用
mysqli_stmt_bind_param($stmt, "s", $name)把变量单独绑定进去，“s” 表示字符串类型，类型声明不能错 - 注意：
bind_param第一个参数是语句句柄，不是连接句柄；第二个参数是类型字符串，必须和后续变量个数、顺序严格一致 - 如果变量是整数，类型要用
"i"，浮点数用"d"，否则可能绑定失败但不报错，查不到数据还一脸懵
PDO 的 prepare 和 execute 更简洁，但别漏掉 PDO::ATTR_EMULATE_PREPARES => false
PDO 写法更短，$stmt = $pdo->prepare("INSERT INTO logs (msg) VALUES (?)"); $stmt->execute([$user_input]); 看似安全——但默认开启模拟预处理（emulate_prepares = true），此时 PDO 会在客户端“假装”预处理，实际还是拼 SQL，遇到特殊编码或 MySQL 配置就失效。
必须显式关掉模拟：
立即学习“PHP免费学习笔记（深入）”；
- 创建 PDO 实例时加配置：
new PDO($dsn, $user, $pass, [PDO::ATTR_EMULATE_PREPARES => false]) - 不设这个选项，
prepare对某些 MySQL 版本（如旧版 5.6）或含多语句的查询完全不起作用 - 另外，
execute接收数组，键名要和命名占位符（如:email）严格匹配，否则静默忽略，查不到数据
过滤函数如 mysqli_real_escape_string 不是万能解药
它只对单引号、反斜杠等做转义，前提是连接字符集设置正确，且只能用于字符串上下文。一旦用在数字字段、ORDER BY、表名、列名等位置，立刻失效。
典型翻车场景：
-
"ORDER BY " . mysqli_real_escape_string($conn, $_GET['sort'])——real_escape_string对空格、逗号、ASC/DESC 完全没约束，可轻松注入id ASC, (SELECT password FROM users LIMIT 1) - 如果数据库连接没设好字符集（比如没执行
SET NAMES utf8mb4），攻击者可用宽字节绕过（如 %df%27），real_escape_string就形同虚设 - 它无法防御二次注入：数据先存进数据库，之后取出来再拼 SQL，这时逃逸过的字符串又变成“原始输入”
所有用户输入都得过一遍预处理，包括 URL 参数、POST 数据、Cookie、HTTP 头
有人只防 POST 表单，却忘了 $_GET['page'] 可能被用来控制 LIMIT 偏移量，$_SERVER['HTTP_REFERER'] 可能写进日志表——只要进 SQL，就是风险点。
实操建议：
- 不要写“这个参数肯定是数字”，一律走
bind_param或execute；真要校验，用filter_var($x, FILTER_VALIDATE_INT)配合范围检查，再传给预处理 - 动态表名/列名无法用占位符，必须白名单硬匹配：
in_array($table, ['users', 'orders'], true)，别试图“过滤”或“截断” - 错误信息别暴露 SQL 结构，
mysqli_error()或PDO::errorInfo()只该记日志，绝不返回给前端
预处理不是开关一开就万事大吉，类型声明错、模拟预处理开着、非字符串上下文乱用 escape、动态结构没白名单——任何一个环节松动，防护就塌半边。最常被跳过的其实是 Cookie 和 HTTP 头的校验，它们和 GET/POST 一样直通数据库。
