PHP 8.3+ 防SQL注入核心仍是PDO/mysqli预处理+禁用模拟预处理，动态标识符须白名单校验，输入验证与异常模式缺一不可。
PHP 8.3+ 环境下，防 SQL 注入的核心没变：必须用 PDO::prepare() 或 mysqli::prepare() 配合真实参数绑定，且禁用模拟预处理。任何绕过这层的写法——包括字符串拼接、addslashes()、mysqli_real_escape_string() 单独使用、ThinkPHP 的 raw() 或 exp() ——在当前 MySQL 配置（尤其是 Docker 默认配置或低版本 MySQL）下都可能被绕过。
为什么 PDO::ATTR_EMULATE_PREPARES => false 不可省略
PHP 8.2 起，PDO 默认仍启用模拟预处理（PDO::ATTR_EMULATE_PREPARES => true），这意味着即使你写了 prepare()，底层仍是字符串拼接。一旦遇到 MySQL 的 sql_mode 包含 NO_BACKSLASH_ESCAPES，或连接字符集未显式设置为 utf8mb4，攻击者就能用宽字节或特殊编码触发注入。
- 必须在 PDO 构造时显式关闭：
new PDO($dsn, $u, $p, [PDO::ATTR_EMULATE_PREPARES => false]) - 验证是否生效：执行
$pdo->getAttribute(PDO::ATTR_EMULATE_PREPARES)，返回false才算成功 - Docker 中常见坑：MySQL 容器未挂载
my.cnf或未在连接串中指定;charset=utf8mb4，会导致set_charset()失效，进而使EMULATE_PREPARES=false退化
mysqli bind_param() 的类型和引用陷阱
mysqli_stmt::bind_param() 对参数类型和变量引用极其敏感，错一个字符或漏一个 & 就会静默失败或截断数据。
- 类型字母必须严格匹配：
i（int）、s（string）、d（double）、b（blob），传's'给数字字段可能导致隐式转换失败 - 所有变量必须传引用：
$stmt->bind_param('is', $id, $name)错；正确是$stmt->bind_param('is', $id, $name)——但注意$id和$name必须是变量，不能是表达式如(int)$_GET['id'] - 解决办法：先赋值再绑定：
$id = (int)$_GET['id']; $name = $_POST['name'] ?? ''; $stmt->bind_param('is', $id, $name);
框架里哪些写法看着安全实则危险
ThinkPHP 6.3 / Laravel 11 等主流框架默认开启绑定，但开发者仍常踩坑。
立即学习“PHP免费学习笔记（深入）”；
-
where("status = " . input('status'))：字符串拼接，完全跳过绑定，等同裸奔 -
where(['order' => ['exp', 'RAND()']])：exp接口直接插入原生 SQL，白名单校验形同虚设 -
Db::query("SELECT * FROM user WHERE id IN (" . implode(',', $ids) . ")")：IN 子句不支持数组参数，必须手动生成?占位符串并绑定数组 - 排序字段动态传入：
order(input('sort') . ' ' . input('dir'))必须白名单硬校验：in_array(input('sort'), ['id', 'created_at']) && in_array(input('dir'), ['ASC', 'DESC'])
表名/字段名/ORDER BY 无法参数化的硬限制
预处理语句只允许绑定「值」，不允许绑定标识符（identifier）。这意味着 FROM ?、ORDER BY ?、GROUP BY ? 全部语法错误，PDO 或 mysqli 会直接报错。
- 唯一安全做法是白名单校验：
$table = in_array($_GET['table'], ['users', 'posts', 'comments']) ? $_GET['table'] : 'users'; - 字段名同理：
$field = preg_match('/^[a-zA-Z_][a-zA-Z0-9_]*$/', $_GET['field']) ? $_GET['field'] : 'id';（正则仅作基础过滤，仍需白名单兜底） - 别信“转义字段名”的奇技淫巧——MySQL 不支持对标识符做参数化，任何所谓“安全转义”都是自欺欺人
最易被忽略的一点：错误信息暴露。哪怕绑定全对，只要 PDO::ATTR_ERRMODE 没设成 PDO::ERRMODE_EXCEPTION，或生产环境未关闭 display_errors，一条 SQLSTATE[42S22]: Column not found 就可能泄露表结构。安全闭环的最后一环，永远是不让数据库说真话。
