单纯用addslashes、mysqli_real_escape_string无法彻底防sql注入，因其设计目标仅为语法层面引号转义，而非安全防护；数字型参数拼接时完全失效，宽字节编码下更易被绕过，唯一可靠方案是全程使用预编译占位符并严格校验标识符白名单。
单纯用 addslashes、mysqli_real_escape_string 这类函数做字符串转义，无法彻底防住 SQL 注入——不是你用得不对，是它们的设计目标就不是“防注入”，而是“在特定上下文里让引号不破坏 SQL 字符串语法”。
数字型参数拼接时，转义函数完全失效
当 SQL 语句里写的是 WHERE id = $id（没加引号），攻击者传 id=1 OR 1=1，整个表达式变成 WHERE id = 1 OR 1=1。此时 mysqli_real_escape_string 对空格、OR、等号这些字符不做任何处理，转义白加。
- 必须给数字字段也套占位符，比如
WHERE id = ?，再用bindValue绑定 - 别图省事写
"WHERE id = " . (int)$_GET['id']，类型强转虽能挡注入，但会把非法输入（如id=abc）静默转成 0，掩盖业务异常 - 如果框架允许手写原生 SQL（如 Laravel 的
DB::select()），确认它底层是否调用PDO::prepare；否则得自己封装
宽字节编码下，转义可被“吃掉”
MySQL 连接字符集设为 gbk，但 PHP 没执行 SET NAMES gbk 或没调用 mysqli_set_charset($conn, 'gbk')，mysqli_real_escape_string 就按默认 latin1 转义，导致 %df%27 解码后变成一个汉字 + 单引号，后者裸露执行。
-
addslashes更危险——它根本不看字符集，纯按字节操作，%df%5c直接被识别为汉字，%27逃逸 - 预编译语句（
PDO::prepare）绕过这个问题：SQL 模板在服务端编译时结构已固定，后续传参不经过 SQL 解析器，单引号、分号、--全部失去语法意义 - 检查连接字符集是否生效：执行
SELECT @@character_set_client, @@collation_connection，确保和 PHP 设置一致
标识符（表名、列名、排序方向）根本不能参数化
像 ORDER BY $_GET['sort'] 或 SELECT * FROM $_GET['table'] 这种场景，连 ? 占位符都不支持。有人退而求其次拼接 + 转义，但 mysqli_real_escape_string 对空格、分号、点号毫无作用，sort=name; DROP TABLE users-- 照样执行。
- 这类字段必须走白名单校验：
in_array($_GET['sort'], ['name', 'email', 'created_at'], true) - 避免动态表名；真要支持多表，用配置映射（如
$tables = ['user' => 'users', 'order' => 'orders']），而不是直取用户输入 - ORM 中慎用
raw()、FromSqlRaw()这类方法，它们等于主动放弃参数化保护
真正难的不是写对一条 prepare，而是所有用户输入进入 SQL 的路径都得被覆盖——包括日志模块里读出数据再拼条件、报表导出时动态构建 WHERE 子句、甚至缓存键生成逻辑里偷偷塞了字段值。只要有一处漏掉，整条链路就断了。
