php中数据库转义函数不安全且不推荐，应使用pdo或mysqli预处理语句；addslashes无视字符集易致宽字节注入，mysql_real_escape_string已废弃，转义无法防护数字、表名等非字符串上下文。
PHP 中的数据库转义函数（如 mysql_real_escape_string、addslashes）常被误认为是防止 SQL 注入的“万能解”，但实际它们既不安全也不推荐——核心问题在于：转义不是抽象层，不能替代参数化查询。
误区一：用 addslashes 替代专用转义函数
addslashes 仅简单在单引号、双引号、反斜杠和 NULL 字符前加反斜杠，它不感知字符集、不绑定数据库连接，且对多字节编码（如 GBK）存在宽字节注入风险。例如在 GBK 环境下，%A1%5C 可能被解析为一个有效汉字加反斜杠，导致绕过转义。
- 永远不要用
addslashes处理 SQL 查询中的用户数据 - 即使配合
set_charset，也无法保证其与 MySQL 实际解析行为一致 - 该函数设计初衷是用于字符串转义（如输出到 js 或 HTML），而非 SQL 安全
误区二：依赖已废弃的 mysql_* 函数及其转义
mysql_real_escape_string 虽考虑了当前连接的字符集，但它绑定于早已被 PHP 7.0 移除的 mysql_* 扩展。使用它意味着代码无法升级到现代 PHP 版本，且仍需手动拼接 SQL，极易因疏漏引发漏洞。
- 该函数无法防御逻辑型注入（如
1 OR 1=1插入数字字段） - 若未显式调用
mysql_set_charset()，字符集不匹配时仍可能被绕过 - 扩展废弃后，连基础安全修复都不可得
误区三：转义后就等于“SQL 安全”
转义只解决字符串字面值的边界问题，对其他上下文完全无效：数字参数不加引号时无法转义、表名/列名/排序方向（ASC/DESC）等结构化部分根本不能靠转义处理。
立即学习“PHP免费学习笔记（深入）”；
- 例如：
"select * FROM users WHERE id = " . $_GET['id']—— 即使对$_GET['id']转义也无意义，因为数字上下文不需要引号 - 动态表名如
"SELECT * FROM " . $_GET['table']—— 任何字符串转义都无法阻止注入，必须白名单校验或拒绝用户控制 - ORDER BY 后的字段名或关键字（如
$_GET['sort']）需映射到预设枚举值，不可转义
正确做法：用 PDO 或 mysqli 的预处理语句
预处理语句将 SQL 结构与数据彻底分离，由数据库引擎原生解析执行计划，从根本上杜绝 SQL 注入。这是唯一被 OWASP、PHP 官方及主流框架共同推荐的方式。
- PDO 示例：
$stmt = $pdo->prepare("SELECT * FROM users WHERE name = ?"); $stmt->execute([$_GET['name']]); - MySQLi 示例：
$stmt = $mysqli->prepare("INSERT INTO logs (msg) VALUES (?)"); $stmt->bind_param("s", $_POST['msg']); $stmt->execute(); - 所有用户输入一律走参数绑定，不拼接、不转义、不信任任何过滤逻辑
- 如需动态结构（如表名），应严格限制为配置数组中的键名或正则白名单（如
/^[a-z_][a-z0-9_]*$/i）
不复杂但容易忽略：转义函数不是安全机制，而是历史兼容的底层工具；真正的防护来自抽象层级的设计选择——用预处理代替字符串拼接，用白名单代替“清理输入”。