必须使用mysqli::prepare()配合bind_param()，禁用模拟预处理，显式设置utf8mb4字符集，并对标识符（如表名、ORDER BY字段）严格白名单校验，才能彻底防SQL注入；单靠mysqli_real_escape_string无法防御宽字节、十六进制编码等绕过攻击。
mysqli::prepare() 必须配合 bind_param()，不能只 escape
单靠 mysqli_real_escape_string() 防不住宽字节、十六进制编码或注释符组合的注入，比如 %df%27 在 gbk 字符集下会绕过转义。真正起作用的是服务端预处理：MySQL 先编译 "SELECT * FROM users WHERE id = ?" 这个模板，再把参数当纯数据塞进去——哪怕用户传 "1 OR 1=1 -- "，它也只是一串字符串，不会参与语法解析。
常见错误是拼接 SQL 后再调用 escape，或者对整条语句做 str_replace()。这些操作都在 PHP 层，数据库根本没机会介入校验。
- 必须用
$mysqli->prepare()创建语句对象，不是写完 SQL 就query() -
bind_param()的第一个参数是类型字符串（如"is"），后面只能跟变量名，不能是表达式或字面量：$stmt->bind_param("s", $_GET['name'])是非法的 - 绑定的是变量引用，不是值快照；循环中复用
$stmt时，每次execute()前必须更新变量值
字符集不设 utf8mb4，预处理也会失效
即使用了 prepare() 和 bind_param()，如果连接字符集不是 utf8mb4，宽字节注入仍可能成功。MySQL 在解析阶段依赖客户端声明的字符集来切分字节流，gbk 或 latin1 下的多字节边界错位，会让 %df%27 被识别为一个合法字符加单引号，从而逃逸。
必须显式设置：
立即学习“PHP免费学习笔记（深入）”；
$mysqli->set_charset('utf8mb4');同时确认 MySQL 服务端配置中 character_set_client、character_set_connection、character_set_results 全部为 utf8mb4，对应表字段的 collation 也得是 utf8mb4_unicode_ci，否则索引可能失效，emoji 存储异常。
ORDER BY、表名、LIMIT 偏移量不能用 ? 占位
? 和命名占位符只能替换值，不能替换标识符（列名、表名、关键字）。写 "SELECT * FROM ?" 或 "ORDER BY ?" 会直接报错，或被驱动静默忽略——这不是 bug，是协议限制。
这类动态结构必须走白名单校验：
- 排序字段：
in_array($sort, ['created_at', 'status', 'score'], true) - 表名：
in_array($table, ['users', 'orders', 'logs'], true) - LIMIT 偏移量：低版本 MySQL 不支持
LIMIT ?, ?中的第一个参数，稳妥做法是(int)$offset加范围检查：if ($offset 10000) die('invalid offset');
PDO 模拟预处理默认开启，mysqli 不会退化但要注意类型匹配
PDO 默认启用模拟预处理（PDO::ATTR_EMULATE_PREPARES = true），此时 prepare() 只是 PHP 自己拼 SQL + 转义，MySQL 根本没收到预处理指令，防护形同虚设。必须显式关闭：
$pdo = new PDO($dsn, $user, $pass, [
PDO::ATTR_EMULATE_PREPARES => false,
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
]);mysqli 没有模拟模式，但 bind_param() 的类型标识必须严格匹配变量实际类型："i" 对应整数、"s" 对应字符串、"d" 对应浮点。类型不匹配不会报错，但可能导致绑定失败、查不到数据，甚至隐式转换漏洞（比如把字符串 "1 OR 1=1" 当整数传进去，变成 1）。
最易被忽略的一点：动态 SQL 中的 LIKE 模式需在 PHP 层拼通配符，不能塞进占位符右侧。正确写法是 $search = "%{$_GET['q']}%"; $stmt->execute([$search]);，而不是 "WHERE name LIKE ?%"。
