答案是使用参数化查询。核心思路是避免直接拼接用户输入与SQL语句，通过PDO或mysqli的预处理机制将SQL结构与数据分离，使用户输入始终作为纯数据处理，从而彻底防止SQL注入，安全性远高于手动过滤或转义。
PHP过滤SQL关键字，核心思路并非真的去“过滤”那些敏感词，而是要从根本上改变数据与SQL指令的交互方式，也就是采用参数化查询（Prepared Statements）。这才是防止SQL注入攻击最有效、最推荐的手段。如果非要谈及“过滤”，那也是在特定场景下对特殊字符进行转义，但这与参数化查询的安全性层级完全不同。
解决方案
要安全地处理PHP中的用户输入并防止SQL注入，最稳妥的方案是使用数据库扩展提供的参数化查询（Prepared Statements）功能。无论是
PDO还是
mysqli扩展，都提供了这种机制。
1. 使用PDO进行参数化查询：
PDO（PHP Data Objects）提供了一个轻量级的、一致的接口来访问数据库。
立即学习“PHP免费学习笔记（深入）”；
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); // 设置错误模式为抛出异常
$user_input_id = $_GET['id'] ?? '';
$user_input_name = $_POST['name'] ?? '';
// 示例1：通过占位符绑定参数（推荐）
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id AND name = :name");
$stmt->bindParam(':id', $user_input_id, PDO::PARAM_INT); // 明确指定参数类型
$stmt->bindParam(':name', $user_input_name, PDO::PARAM_STR);
$stmt->execute();
$result = $stmt->fetchAll(PDO::FETCH_ASSOC);
// print_r($result);
// 示例2：通过问号占位符绑定参数
$stmt = $pdo->prepare("INSERT INTO products (name, price) VALUES (?, ?)");
$product_name = 'New Widget';
$product_price = 19.99;
$stmt->execute([$product_name, $product_price]); // 数组形式传递参数
// echo "Affected rows: " . $stmt->rowCount();
} catch (PDOException $e) {
// 生产环境中不应直接输出错误信息，应记录日志
error_log("Database error: " . $e->getMessage());
// echo "An error occurred. Please try again later.";
}
?>2. 使用mysqli进行参数化查询：
mysqli是MySQL数据库的增强版接口，也支持预处理语句。
connect_error) {
die("Connection failed: " . $conn->connect_error);
}
$user_input_email = $_GET['email'] ?? '';
$user_input_status = $_POST['status'] ?? '';
// 示例1：查询
$stmt = $conn->prepare("SELECT username, registration_date FROM members WHERE email = ? AND status = ?");
if ($stmt === false) {
// 错误处理，例如日志记录
error_log("Prepare failed: " . $conn->error);
// die("Prepare failed: " . $conn->error);
}
// 绑定参数，'ss'表示两个参数都是字符串类型
$stmt->bind_param('ss', $user_input_email, $user_input_status);
$stmt->execute();
$result = $stmt->get_result(); // 获取结果集
if ($result->num_rows > 0) {
while ($row = $result->fetch_assoc()) {
// print_r($row);
}
}
$stmt->close();
// 示例2：插入
$stmt = $conn->prepare("INSERT INTO logs (action, timestamp) VALUES (?, NOW())");
if ($stmt === false) {
error_log("Prepare failed: " . $conn->error);
}
$action_log = 'User logged in';
$stmt->bind_param('s', $action_log); // 's'表示一个字符串类型参数
$stmt->execute();
// echo "New record created successfully.";
$stmt->close();
$conn->close();
?>3. mysqli_real_escape_string
(辅助/遗留方案):
虽然强烈推荐使用参数化查询，但在某些极少数情况下（比如处理非SQL语句的数据，或者在极老的代码库中），
mysqli_real_escape_string可以作为一种辅助手段来转义字符串中的特殊字符。它并不能替代预处理语句的安全性。
connect_error) {
die("Connection failed: " . $conn->connect_error);
}
$user_search_term = $_GET['term'] ?? '';
// 在将字符串拼接到SQL语句之前进行转义
$escaped_search_term = $conn->real_escape_string($user_search_term);
// 这种方式依然不推荐，因为它容易遗漏，且不如参数化查询安全
$sql = "SELECT * FROM articles WHERE title LIKE '%" . $escaped_search_term . "%'";
$result = $conn->query($sql);
// ... 处理结果 ...
$conn->close();
?>核心思想是：永远不要直接将用户输入拼接到SQL语句中。 参数化查询将SQL逻辑与数据分离，数据库在执行前就知道哪些是指令，哪些是数据，从而有效阻止了恶意注入。
参数化查询：为何它是抵御SQL注入的终极武器？
在我看来，参数化查询之所以被称为“终极武器”，是因为它从根本上改变了数据库处理查询的方式，而不是简单地在表面上“过滤”或“清洗”数据。我们都知道，SQL注入的本质是攻击者利用应用程序对用户输入处理不当，将恶意的SQL代码注入到原本的数据中，使得数据库在执行时将这些恶意代码当作合法的SQL指令来执行。
参数化查询的工作原理是这样的：你先向数据库发送一个带有占位符的SQL模板（比如
SELECT * FROM users WHERE id = ?），这个模板定义了查询的结构。数据库收到这个模板后，会对其进行解析和预编译，它知道哪里是查询的条件，哪里是将来要接收数据的地方。然后，你再将实际的用户数据作为独立的参数发送给数据库。数据库接收到这些参数后，会严格地将它们视为数据，并填充到之前预编译的SQL模板中。
这意味着什么呢？这意味着即使你的用户输入中包含像
' OR 1=1 --这样的SQL关键字或攻击代码，数据库也只会把它当成一个普通的字符串值，而不是可以执行的SQL指令。它不会去解析这些字符作为SQL语法的一部分，因为查询的结构在数据到来之前就已经固定了。这种“先定结构，后填数据”的模式，彻底切断了攻击者通过数据来改变SQL指令的可能性。
所以，这不是一个“黑名单”或“白名单”的问题，而是一个架构上的防御。它不依赖于你对所有可能攻击模式的了解，因为它从设计上就规避了这种风险。在我看来，任何现代PHP应用，如果涉及数据库交互，都应该无条件地采用参数化查询。
mysqli_real_escape_string
：在现代PHP开发中还有一席之地吗？
说实话，在现代PHP开发中，
mysqli_real_escape_string的地位已经非常尴尬了。它曾经是防止SQL注入的重要工具，尤其是在
mysqli或
mysql（已废弃）扩展时代，当预处理语句还不那么普及或者开发者对其理解不深时。它的作用是转义字符串中的特殊字符，比如单引号（
'）、双引号（
"）、反斜杠（
\）、NULL字符等等，这些字符在SQL语句中具有特殊含义。通过在将用户输入拼接到SQL语句之前进行转义，可以防止这些特殊字符被解释为SQL语法的一部分。
但是，它存在几个明显的局限性：
- 易于遗漏： 你必须手动地、有意识地对每一个可能来自用户输入的字符串进行转义。一旦忘记，就可能留下漏洞。而参数化查询是统一处理的，很难遗漏。
-
仅适用于字符串：
mysqli_real_escape_string
只能处理字符串类型的数据。如果你的查询条件是数字（例如WHERE id = 1
），攻击者依然可以通过注入1 OR 1=1
这样的数字类型注入，因为它不会被转义。当然，你可以先强制类型转换，但那又增加了额外的步骤和出错的可能。 - 与数据库连接相关： 它需要一个活动的数据库连接才能工作，因为转义规则可能因数据库的字符集设置而异。
-
无法防御所有注入： 比如
ORDER BY
子句的注入，或者某些高级的盲注技术，mysqli_real_escape_string
可能就显得力不从心了。
那么，它在现代PHP中还有没有一席之地呢？我觉得，在绝大多数情况下，答案是没有。如果你正在编写新的代码，或者维护一个可以升级的现有项目，那么参数化查询应该是你的首选，甚至可以说是唯一选择。
但凡事没有绝对，我能想到的少数场景可能是：
- 遗留系统维护： 如果你接手了一个庞大且老旧的系统，改造成本巨大，而其中某些非核心、低风险的功能确实难以快速切换到预处理语句，那么作为一种临时或局部的补救措施，它或许还有点用。但这仅仅是权宜之计，并且风险自担。
- 非SQL上下文的字符串处理： 有时候你可能需要对一个字符串进行“安全处理”，但这个字符串最终不是直接拼接到SQL语句中，而是用于其他需要转义特殊字符的场景。这种情况下，它的转义功能可能还有用，但这已经脱离了SQL注入防御的范畴。
总而言之，
mysqli_real_escape_string就像一把老旧的工具，它有它的历史贡献，但面对现代的挑战和更强大的新工具（参数化查询），它的作用已经微乎其微，甚至可以说，它的存在反而可能让一些开发者产生错觉，以为自己已经足够安全了。
避免手动过滤陷阱：黑名单策略为何不可靠？
当我看到一些开发者尝试通过手动过滤SQL关键字来防御注入时，心里总会咯噔一下。这通常意味着他们正在使用一种“黑名单”策略：列出所有已知的恶意SQL关键字（比如
UNION,
SELECT,
OR,
DROP,
DELETE等），然后检查用户输入中是否包含这些词，如果包含就阻止或替换掉。
但为什么这种方法是极其不可靠的呢？
原因很简单：你永远无法穷尽所有可能的攻击变体。这就像一场猫鼠游戏，而攻击者永远是那个更狡猾、更有创造力的“猫”。
-
关键字变体与混淆： SQL语法非常灵活，攻击者可以通过各种方式来混淆关键字，使其不被简单的字符串匹配过滤掉。
-
大小写混淆：
SELECT
vsSELECT
vsSELECT
-
注释：
SEL/**/ECT
,UNI--ON
-
编码： 十六进制编码、URL编码等，例如
%55%4E%49%4F%4E
代表UNION
-
特殊字符：
UNI(ON
(某些数据库会忽略括号内的字符) - 双重转义： 如果你的过滤逻辑在某个环节先转义了，攻击者可能会利用这一点进行双重转义来绕过。
- 空白字符变体： 各种空格、制表符、换行符的组合。
-
大小写混淆：
语义分析的复杂性： 数据库引擎在解析SQL时，会进行复杂的词法和语法分析。你的简单字符串匹配过滤，根本无法达到数据库引擎的理解深度。它可能认为
OR 1=1
是恶意注入，但攻击者可能写成' OR '1'='1
，或者利用其他函数如LENGTH()
、SUBSTRING()
进行盲注，这些并不直接包含明显的“恶意关键字”。过滤不当可能导致合法数据被阻止： 如果你过滤得过于严格，可能会误伤正常的业务数据。比如，某个商品名称中恰好包含了
UNION
这个词，你的过滤就会阻止这个合法的数据。维护成本高昂： 随着新的攻击手法和数据库特性的出现，你需要不断更新你的黑名单，这几乎是不可能完成的任务。你永远都在追赶攻击者的脚步。
在我看来，尝试手动过滤SQL关键字，无异于在堵一个千疮百孔的堤坝，你堵住了一个漏洞，攻击者很快就会在旁边找到另一个。这种策略不仅效率低下，而且给人一种虚假的安全感，最终只会让系统面临更大的风险。
构建安全的数据库交互层，应该遵循“白名单”原则，但这里的“白名单”不是指过滤关键字，而是指只允许明确定义和预期的数据类型和结构进入SQL查询。而参数化查询正是这种“白名单”思维在SQL注入防御上的最佳实践，因为它确保了数据永远作为数据处理，而不是作为可执行代码。
