mysql_real_escape_string已彻底失效，必须迁移到PDO预编译+参数绑定；它仅做字符串转义，无法防护非字符串上下文注入、宽字节绕过，且PHP 7.0+已移除。
直接说结论：mysql_real_escape_string 已彻底失效，不能靠它防注入；必须迁移到 PDO 预编译 + 参数绑定，否则任何“加固”都是假安全。
为什么 mysql_real_escape_string 无法真正防 SQL 注入
这个函数只做字符串层面的转义，不区分上下文、不识别数据类型、不与数据库交互。只要用户输入出现在非字符串位置（比如 ORDER BY 字段名、LIMIT 偏移量、IN 列表），它就完全无效。
常见翻车场景：
- 数字型参数未加引号：
$id = mysql_real_escape_string($_GET['id']); $sql = "SELECT * FROM users WHERE id = $id";—— 输入1 OR 1=1直接穿透 - GBK 双字节绕过：当 MySQL 连接字符集设为
gbk，攻击者用%df%27构造宽字节截断，让转义符被吞掉 - 函数已从 PHP 7.0 起完全移除，继续调用会报
Fatal error: Uncaught Error: Call to undefined function mysql_real_escape_string()
迁移到 PDO 预编译的最小可行改法
不是简单替换函数，而是重构查询逻辑：SQL 模板和数据必须分离。以下是最简迁移路径：
立即学习“PHP免费学习笔记（深入）”；
- 把原来拼接的 SQL 字符串拆成两部分：
prepare()传模板，execute()传数据 - 所有用户输入，无论是否经过
mysql_real_escape_string处理过，全部扔进execute()或bindValue()，不再拼进 SQL 字符串 - 连接必须显式声明字符集：
mysql:host=localhost;dbname=test;charset=utf8mb4，否则PDO::ATTR_EMULATE_PREPARES可能被自动启用，退化为模拟预处理（即又变回字符串拼接）
对比示例：
// ❌ 旧写法（危险）
$id = mysql_real_escape_string($_GET['id']);
$sql = "SELECT * FROM posts WHERE id = $id";
$result = mysql_query($sql);
<p>// ✅ 新写法（安全）
$stmt = $pdo->prepare('SELECT * FROM posts WHERE id = ?');
$stmt->execute([$_GET['id']]);
$result = $stmt->fetchAll();
命名占位符 vs 问号占位符：选哪个？
两者都安全，但适用场景不同，选错会导致维护成本陡增或隐性 bug：
- 用
?占位符：适合简单、参数少、顺序固定的操作，如单条件查询、INSERT固定字段。性能略高，因为省去键名解析开销 - 用
:name占位符：适合多参数、需复用、或参数来自不同来源（如部分来自 POST、部分来自 session）。可避免顺序错乱，也方便调试时快速定位字段 - 注意：
:name中的 name 不能是 SQL 关键字（如:order、:group），否则 prepare 会失败；也不能含空格或特殊符号
最容易被忽略的三个细节
很多迁移后仍出问题，往往卡在这三处：
-
PDO::ATTR_EMULATE_PREPARES默认为true（尤其在旧版 PHP 或某些 Docker 镜像里），导致看似用了预处理，实则还是本地拼接 —— 必须显式关掉：$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false) - 字符集声明必须写在 DSN 里，不能只靠
SET NAMES utf8；否则中文可能乱码，且宽字符绕过风险重现 - 批量操作（如
INSERT ... VALUES (?, ?), (?, ?)）中，每个?都要单独绑定；不能传一个二维数组期望自动展开
真正的难点不在语法，而在于把“拼 SQL”的思维彻底清零 —— 只要还想着“我先 escape 一下再塞进去”，就还没完成迁移。
