必须用pdo::prepare()+execute()替代所有字符串拼接sql，禁用addslashes()等手动转义；因后者不防字符集绕过、不护结构部分，且php7中仅此方案能真正切断注入链路。
直接上结论：必须用 PDO::prepare() + execute() 替换所有字符串拼接 SQL，且不能依赖 addslashes() 或手动转义。这是 PHP 7 中唯一被广泛验证、跨数据库兼容、且能真正切断注入链路的方案。
为什么 addslashes() 在 PHP 7 里根本挡不住 SQL 注入
addslashes() 只对单引号、双引号、反斜线和 NULL 字节加反斜线，但它完全不感知字符集、不处理多字节编码绕过（比如 GBK 双字节截断），也不适配 MySQL 8.0+ 的严格 SQL 模式。更关键的是：它只作用于字符串值，对数字型参数、ORDER BY 字段、表名等动态位置毫无防护力。
- 常见错误现象：addslashes($_GET['id']) 传给 "SELECT * FROM users WHERE id = $id"，攻击者仍可用 id=1 UNION SELECT password FROM users 直接执行任意查询
- 真实用法限制：仅可作为“最后防线”配合其他机制，绝不可单独用于 SQL 构造
- PHP 7 已明确弃用 mysql_*()，但 addslashes() 仍在，容易让人误以为“用了就安全”
如何把旧代码迁移到 PDO::prepare()
核心是两步：改写 SQL 模板（去拼接）、绑定变量（不插值）。重点不是“怎么写 PDO”，而是“怎么不动逻辑地替换掉危险代码”。
- 找到原始语句，例如：$sql = "SELECT * FROM users WHERE username = '" . $_POST['user'] . "' AND status = " . $_POST['status'];
- 改为命名参数模板：$sql = "SELECT * FROM users WHERE username = :user AND status = :status";
- 创建预处理并绑定：$stmt = $pdo->prepare($sql); $stmt->bindValue(':user', $_POST['user'], PDO::PARAM_STR); $stmt->bindValue(':status', $_POST['status'], PDO::PARAM_INT); $stmt->execute();
- 注意：数字参数必须用 PDO::PARAM_INT，否则仍可能被当字符串解析（如 1 OR 1=1 进入 WHERE status = '1 OR 1=1'）
- 不要混用问号占位符和命名参数，PHP 7 中虽支持，但可读性差、易绑错顺序
哪些地方最容易漏掉、导致 PDO 失效
PDO 预处理只保护“值”，不保护 SQL 结构本身。以下三类场景即使用了prepare() 依然高危：
- 动态表名/字段名："SELECT * FROM " . $_GET['table'] —— 必须用白名单校验，如 in_array($_GET['table'], ['users', 'orders'])
- 动态 ORDER BY / LIMIT："ORDER BY " . $_GET['sort'] —— 允许的字段需硬编码映射，例如 $sort_map = ['name' => 'username', 'time' => 'created_at']; $order = $sort_map[$_GET['sort']] ?? 'id';
- JSON 或数组参数未解构：$_POST['filters'] = ['status' => 'active', 'type' => 'admin']，若直接 json_encode() 插入 SQL，仍可能触发注入 —— 应逐个键做白名单 + 类型绑定
- 错误配置陷阱：PDO 默认不抛异常，$pdo = new PDO($dsn, $u, $p) 后没设 PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，会导致错误静默失败，掩盖绑定失败问题
上线前必须验证的三个动作
修复不是改完代码就结束，尤其在 PHP 7 的遗留项目里，运行时环境和历史数据常埋雷： - 用真实攻击 payload 测试：提交用户名admin' OR '1'='1，确认返回空结果或报错，而不是登录成功
- 检查日志中是否出现 PDOException，特别是 SQLSTATE[HY093]（参数绑定数量不匹配）这类错误，说明某处 bind 漏了或 SQL 模板写错了
- 验证字符集一致性：确保 PDO 连接时指定了 ;charset=utf8mb4，且数据库表默认字符集也是 utf8mb4，否则宽字节注入仍可能发生
最常被忽略的一点：PDO 安全的前提是“整个查询路径都受控”。如果某个函数返回拼接好的 SQL 字符串，而你只是把它丢给 prepare()，那等于把炸弹包进防爆箱再扔进火堆——箱子没炸，火早烧穿了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
