PHP 7.0+ 已移除 mysql_real_escape_string()，应改用 mysqli_real_escape_string()（需有效连接且编码一致）或更安全的预处理语句；后者通过分离SQL结构与数据彻底防范注入，手动转义易受宽字节等攻击。
PHP里用 mysql_real_escape_string 就是错的
这个函数早在 PHP 7.0 就被彻底移除了，现在调用会直接报 Fatal error: Uncaught Error: Call to undefined function mysql_real_escape_string()。它绑定的是已废弃的 mysql_* 扩展，连 MySQLi 都不认它。别查旧教程了，那套逻辑现在纯属踩坑。
真正该用的是：mysqli_real_escape_string()（配合 MySQLi）或更推荐的预处理语句——后者根本不需要手动转义。
- 必须先有有效的
mysqli连接对象，否则mysqli_real_escape_string()会警告并返回false - 字符串编码必须和数据库连接编码一致（比如都设为
utf8mb4），否则可能转义失效或乱码 - 它只处理字符串，对数字、布尔、
null不起作用——但你也不该把非字符串直接拼进 SQL
为什么预处理语句比手动转义更可靠
手动转义本质是“把危险字符加反斜杠”，但绕过它的方法很多：宽字节注入、编码混淆、多字节边界截断……而预处理把 SQL 结构和数据彻底分开，数据库引擎在解析阶段就锁死了参数类型和位置。
哪怕你传入 "'; DROP TABLE users; -- "，它也只会当做一个普通字符串值，不会改变 SQL 逻辑。
立即学习“PHP免费学习笔记（深入）”；
- MySQLi 预处理用
prepare()+bind_param()，PDO 用prepare()+execute() -
bind_param()的类型标识符不能错：s是字符串，i是整数，d是浮点，b是 blob - 不要对表名、字段名做预处理——它们不能参数化，得靠白名单校验或硬编码
哪些场景下还不得不手动转义
极少数情况：动态构建 SQL 片段（比如 ORDER BY ? 中的字段名）、日志拼接、生成 SQL 文件导出等。这些地方无法用预处理，但必须严格限制输入来源。
此时应优先用白名单过滤，其次才是转义；且必须确保连接编码、客户端编码、表字段编码三者统一。
- 检查当前连接编码：
mysqli_set_charset($conn, 'utf8mb4')，别依赖配置文件默认值 - 避免混用
mysqli_escape_string()和addslashes()——后者不识别连接编码，完全不可靠 - 如果用 PDO，
PDO::quote()可以安全转义单个值，但它返回带引号的字符串，需手动拼进 SQL，仍不如预处理干净
常见错误现象和对应检查点
出现中文乱码+转义失效、SQL 报错但看不出哪错了、某些特殊字符（如单引号、反斜杠、%）没被处理……大概率不是函数用错了，而是编码链断了。
- 查连接是否成功：
mysqli_connect_errno()不为 0 就别继续了 - 确认连接后立刻执行：
mysqli_set_charset($conn, 'utf8mb4')，而不是靠my.cnf或SET NAMES - 用
var_dump()看转义后的字符串，确认引号前真多了反斜杠，而不是显示问题 - 如果用 ORM（如 Laravel Eloquent、Doctrine），别自己转义——它们内部已用预处理，重复操作反而破坏参数绑定
真正的难点不在函数怎么写，而在编码一致性、连接生命周期管理、以及分清“哪里能参数化、哪里必须过滤”。漏掉任意一环，转义就形同虚设。
