过滤SQL注释可提升安全与代码整洁，主要通过正则移除--、#和/ /类注释，但根本解决方案是使用预处理语句，确保参数被当作数据而非代码，从而彻底防止注入攻击。
PHP里处理SQL注释，主要目的无非是两个：一是确保你执行的SQL语句是干净、可控的，没有不必要的“噪音”；二是更关键的，防止一些恶意注入利用注释来绕过你的安全检查。最直接的办法，通常是利用正则表达式把这些注释给“洗掉”，但更推荐、也更安全的做法，是回归到预处理语句（Prepared Statements）的使用上，这才是从根本上解决问题的思路。
解决方案
要处理SQL注释，我们可以从两个层面入手。最直观的是在PHP代码层面，通过字符串操作，特别是正则表达式，来识别并移除SQL语句中的各种注释符号。这包括单行注释（如
--和
#，后者在MySQL中常见）以及多行注释（
/* ... */）。
具体的处理逻辑是，你需要构建一个能够匹配所有这些注释类型的正则表达式，然后使用
preg_replace函数将它们替换为空字符串。这听起来简单，但正则表达式的编写需要考虑周全，比如注释可能出现在字符串内部、或者注释本身包含特殊字符等情况，虽然一般用途下，一个相对通用的模式就能覆盖大部分场景。
然而，话说回来，仅仅依靠正则表达式过滤注释，其实只是一个“治标不治本”的策略。真正的安全保障，应该放在使用数据库预处理语句（Prepared Statements）上。当你使用预处理语句时，SQL查询的结构和数据是分开传输的。数据库在执行前会先编译SQL模板，然后将你的参数作为纯粹的数据绑定进去，这样一来，即使你的参数中包含了SQL注释，甚至恶意代码，它们也只会被当作数据，而不会被解析为SQL指令的一部分。这就像是给你的SQL语句穿上了一层“防弹衣”，从根本上杜绝了注释可能带来的解析问题或注入风险。
立即学习“PHP免费学习笔记（深入）”；
为什么我们需要在PHP中过滤SQL注释？
说实话，这事儿吧，有时候我们可能觉得SQL注释就是个无害的“小玩意儿”，用来做做标记、方便调试。但从安全的角度看，它们远非那么简单。我个人觉得，需要过滤SQL注释，主要有这么几个原因：
首先是安全隐患。虽然注释本身不直接构成SQL注入，但它们常常被攻击者用来绕过WAF（Web Application Firewall）或者一些简单的关键词过滤。比如，攻击者可能会在SQL语句中插入注释来分割关键词，让你的过滤器失效，或者利用注释来隐藏恶意代码，使其在被拼接后执行。想象一下，如果一个用户输入
' OR 1=1 /*，你的程序没过滤掉
/*，那后面的查询可能就直接被注释掉了，导致意想不到的结果。
其次，是解析问题和预期行为。有时候，一些不规范的SQL解析器或者特定数据库版本，可能会对注释的处理方式有所不同，导致你的SQL语句在不同环境下表现不一致。虽然这种情况比较少见，但作为一个严谨的开发者，我们总是希望SQL语句的执行是确定且可控的。过滤掉注释，能让你的SQL语句更“纯粹”，减少这种不确定性。
再者，就是代码整洁和维护。虽然这个理由不那么“硬核”，但一个干净的SQL语句，没有用户输入的各种奇奇怪怪的注释，阅读起来也更舒服，对调试和维护都是有好处的。毕竟，我们希望在数据库日志里看到的，是真正执行的SQL逻辑，而不是一堆用户可能无意或恶意添加的“噪音”。
使用正则表达式过滤SQL注释的具体实现方法是什么？
要用正则表达式在PHP里过滤SQL注释，我们得先搞清楚SQL里常见的注释类型。主要有三种：
-
单行注释
--
: 比如SELECT * FROM users -- 这是单行注释
-
单行注释
#
: MySQL特有，比如SELECT * FROM users # 这是MySQL单行注释
-
多行注释
/* ... */
: 比如SELECT * FROM users /* 这是多行注释 */
我们需要一个能把它们一网打尽的正则表达式。我个人比较喜欢用一个组合模式，这样一次
preg_replace就能搞定。
这段代码里，我把多行和单行注释的匹配分开了，先处理多行注释，再处理单行。这是因为多行注释内部可能包含类似
--或
#的字符，如果先用单行注释的正则去匹配，可能会把多行注释的内容误删一部分。
[\s\S]*?这个模式很关键，它能匹配包括换行符在内的任何字符，而且
?是非贪婪模式，确保只匹配到最近的
*/。
不过，这里有个小小的“坑”得提一下：如果你的SQL语句中，字符串字面量（比如
'这是一个包含 -- 的字符串'）里也出现了注释符号，上面的正则表达式也会把它们当成注释给删掉。虽然在大多数情况下，我们不会在用户输入里直接处理这种极端复杂的SQL，但如果你真的需要一个能完美区分字符串内部和外部注释的解析器，那恐怕就不是一个简单的正则表达式能搞定的了，你可能需要一个真正的SQL解析器库。但对于日常的、防御性的注释过滤，这个方法已经足够实用了。
除了正则表达式，还有哪些更安全、更推荐的SQL处理策略？
嗯，我前面也提到了，光靠正则表达式过滤注释，就像是给一个漏水的桶打补丁。虽然能暂时止住，但更根本的解决之道，是换一个不漏的桶。在SQL处理这块，那个“不漏的桶”就是预处理语句（Prepared Statements）。
我个人觉得，这是PHP里处理SQL最核心、最安全的方式，没有之一。它的原理很简单，但效果却非常强大：
-
分离SQL结构和数据：当你使用预处理语句时，你先定义一个SQL模板，比如
SELECT * FROM users WHERE id = ? AND name = ?
。这个模板里的?
就是占位符。 - 数据库编译模板：数据库会先接收并编译这个SQL模板，它知道哪些地方是SQL命令，哪些地方是未来要填充的数据。
-
绑定数据：然后，你再把实际的数据（比如
id=10
，name='张三'
）通过参数绑定的方式传给数据库。 -
数据即数据，代码即代码：此时，数据库会严格地将你传入的参数视为纯粹的数据值，而不是SQL代码的一部分。所以，即使你的数据里包含了
' OR 1=1 --
这样的字符串，它也只会被当成一个名字叫' OR 1=1 --
的用户，而不会被执行为SQL指令。
PHP中，无论是使用PDO（PHP Data Objects）还是MySQLi扩展，都提供了强大的预处理语句支持。
PDO 示例：
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$user_id = 1;
$user_name = "John Doe' OR 1=1 --"; // 恶意输入，但会被当作数据
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ? AND name = ?");
$stmt->execute([$user_id, $user_name]); // 数据通过数组绑定
$user = $stmt->fetch(PDO::FETCH_ASSOC);
if ($user) {
echo "Found user: " . $user['name'] . "\n";
} else {
echo "User not found.\n";
}
} catch (PDOException $e) {
echo "Error: " . $e->getMessage() . "\n";
}
?>MySQLi 示例：
connect_error) {
die("Connection failed: " . $mysqli->connect_error);
}
$user_id = 1;
$user_name = "John Doe' OR 1=1 --"; // 恶意输入
$stmt = $mysqli->prepare("SELECT * FROM users WHERE id = ? AND name = ?");
if ($stmt) {
$stmt->bind_param("is", $user_id, $user_name); // "is" 表示第一个参数是整数，第二个是字符串
$stmt->execute();
$result = $stmt->get_result();
if ($result->num_rows > 0) {
$user = $result->fetch_assoc();
echo "Found user: " . $user['name'] . "\n";
} else {
echo "User not found.\n";
}
$stmt->close();
} else {
echo "Error preparing statement: " . $mysqli->error . "\n";
}
$mysqli->close();
?>你看，在这两个例子里，即使
$user_name包含了看起来像SQL注入的字符串，它也只是被当作一个普通的字符串值来匹配，而不会改变查询的结构。这就是预处理语句的魔力。
除了预处理语句，还有ORM（Object-Relational Mapping）框架，比如Laravel的Eloquent、Doctrine等。这些框架在底层也大量使用了预处理语句，并且提供了更高级、更面向对象的数据库操作方式。它们不仅能帮你构建安全的查询，还能大大提高开发效率。
所以，我的建议是：正则表达式过滤注释，可以作为一道额外的防线，尤其是在处理一些非结构化的文本输入时。但对于任何与数据库交互的SQL语句，请务必、优先使用预处理语句。这才是最根本、最可靠的SQL安全实践。
