addslashes()不能防SQL注入，因其仅简单转义特定字符，不识别SQL上下文、不处理宽字节漏洞、不防范高级注入手法；应使用PDO/MySQLi预处理语句等上下文感知方案。
addslashes() 不是防 SQL 注入的可靠方案，不能单独用于数据库安全防护。它只是在单引号、双引号、反斜杠和 NULL 字节前加反斜杠，不识别上下文、不处理 MySQL 特有转义规则（比如 \x00、\n、\r、\x1a），也不防范 UNION、注释符、编码绕过等高级注入手法。
addslashes 的实际作用范围
该函数仅做基础字符转义，适用于：
- 准备写入文件或日志的字符串（避免破坏格式）
- 拼接进 PHP 代码字符串（如 eval 场景，但应尽量避免 eval）
- 配合 stripslashes() 做临时存储/读取的简单转义还原
- 旧系统中兼容 magic_quotes_gpc 关闭后的手动补位（已废弃）
为什么它不能防 SQL 注入
关键问题在于：SQL 解析器不认 addslashes 的转义逻辑。例如：
- MySQL 客户端协议中，真正的转义需由 mysql_real_escape_string 或 mysqli::real_escape_string 执行，它们会根据当前连接的字符集动态处理
- addslashes 对宽字节漏洞（如 GBK）完全无效，攻击者可用 %A1%27 绕过
- 数字型参数（如 id=123）若未类型转换，直接拼接仍可被注入：WHERE id = $id → WHERE id = 1 OR 1=1
- 它不阻止关键字过滤缺失导致的注入，比如 ORDER BY 后直接拼接 $_GET['sort']
真正有效的替代方案
用现代、上下文感知的方式替代 addslashes 拼接：
立即学习“PHP免费学习笔记（深入）”；
- PDO 预处理语句：$pdo->prepare("SELECT * FROM users WHERE name = ?")->execute([$name])
- MySQLi 预处理：$stmt = $mysqli->prepare("INSERT INTO log(msg) VALUES (?)"); $stmt->bind_param("s", $msg); $stmt->execute()
- 数字参数强制转换：$id = (int)$_GET['id']; // 或 intval($_GET['id'], 10)
- 白名单限定字段名：$allowed_sort = ['name', 'created_at', 'price']; $sort = in_array($_GET['sort'], $allowed_sort) ? $_GET['sort'] : 'id';
如果必须用字符串转义（极少数遗留场景）
仅限明确知道字符集且使用 mysqli 扩展时，搭配 real_escape_string：
✘ 错误写法：$sql = "SELECT * FROM user WHERE name = '" . addslashes($_POST['name']) . "'";
✓ 正确写法（仅作过渡，非推荐）：
$safe_name = $mysqli->real_escape_string($_POST['name']);<br> $sql = "SELECT * FROM user WHERE name = '$safe_name'";
