仅靠密码正则过滤特殊字符（如单引号、等号）并非防sql注入的正确方式；真正可靠的做法是使用pdo预处理语句，彻底隔离sql逻辑与用户输入。
仅靠密码正则过滤特殊字符（如单引号、等号）并非防sql注入的正确方式；真正可靠的做法是使用pdo预处理语句，彻底隔离sql逻辑与用户输入。
在Web开发中，常有人误以为“禁止密码中出现 '、" 或 = 就能防止SQL注入”，这种思路存在根本性误区。SQL注入的本质不是输入内容“危险”，而是用户输入被当作SQL代码执行。即使密码本身不含任何特殊符号，若拼接进SQL查询时未做参数化处理（例如用字符串拼接 WHERE pass = '$pass'），攻击者仍可能通过其他字段（如用户名、邮箱）或配合二次注入等方式达成攻击。
✅ 正确方案：始终使用 PDO预处理语句（Prepared Statements）
PDO通过将SQL结构与数据分离，在数据库层面完成参数绑定，从根本上杜绝SQL语法混淆：
// ✅ 安全：使用占位符 + execute() 绑定参数
$stmt = $pdo->prepare('SELECT id, username FROM users WHERE email = ? AND password_hash = ?');
$stmt->execute([$email, $hashedPassword]); // 自动转义 & 类型安全
$user = $stmt->fetch(PDO::FETCH_ASSOC);
⚠️ 注意事项：
- 不要自行用 preg_replace() 或 str_replace() 过滤 '、=、-- 等“可疑字符”来“防注入”——这既不全面（如宽字节注入、编码绕过），又破坏密码策略的合理性（现代系统应允许用户使用任意Unicode字符作为密码）；
- 密码字段本身不应明文存储或直接参与SQL比较，务必使用 password_hash() 加密后比对（如 password_verify($input, $hash)）；
- 上述正则 /^(?=.*\d)(?=.*[A-Za-z])[0-9A-Za-z!@#$%]{8,12}$/ 存在多个问题：
- 允许字符集过窄（排除中文、emoji、更多合法符号）；
- 强制仅含 !@#$%，却遗漏常用符号如 ^&*()_+-=[]{}|;:,.?；
- 长度上限 12 限制不合理（NIST推荐最小8位，无硬性上限）；
- 未考虑Unicode兼容性（如 mb_ 函数族缺失）。
? 总结：
密码验证的目标应是提升账户安全性（如强制大小写字母+数字+符号、最小长度、拒绝常见弱口令），而非充当SQL防火墙。而防御SQL注入的唯一可靠手段，是全程使用参数化查询——无论输入来自表单、URL、Cookie还是文件，只要进入SQL上下文，就必须走预处理流程。将安全责任推给“密码格式限制”，不仅无效，还会误导开发者忽视真正关键的防护机制。
