拒绝 SQL 注入！零点博主手把手教你用 C# 预处理语句，这才是底层安全的核心

大家好，我是零点博主。在之前的文章里，我们聊过很多关于 C# 和 PHP 后端开发的套路，也做过不少爬虫和在线工具。但今天，我想跟大家聊一个稍微严肃点的话题：数据库安全。

很多刚开始写接口开发的同学，为了图省事，喜欢把用户输入的变量直接拼接到 SQL 语句里。如果是不懂技术的黑客输入了一个恶意字符，你的数据表可能就瞬间崩了。这就是最臭名昭著的 SQL 注入。

今天，我就结合零点博客之前的实战经验，来聊聊怎么彻底解决它——答案就是：预处理语句。

为什么拼接 SQL 是危险的？

举个简单的例子，在 C# 或者 PHP 中，如果不加处理，直接拼接字符串：

// 危险操作！千万不要这么写
string username = "' OR '1'='1";
string sql = "SELECT * FROM Users WHERE username = '" + username + "'";

这时候执行出来的 SQL 其实已经是畸形了，直接绕过了账号密码验证。这种低级错误在开发初期最容易被忽视，一旦线上环境被扫到，后果不堪设想。

什么是预处理语句？底层原理是什么？

预处理语句的核心思想，是把“SQL 逻辑”和“数据值”分开处理。

打个比方，去银行柜台办事，你不能把钱直接塞进柜台的小窗口里，你需要先填单子（发送 SQL 命令给数据库），单子上的“姓名”和“金额”是空的。等银行柜员确认单子没问题，并把单子打印出来后，你再把具体的数据填进单子里提交。

这种机制让数据库知道：“这是一段定好的代码，你只需要把参数填进去，不要改动代码本身。”

C# 源码实战：如何正确使用预处理语句

下面给大家看一段在 EMLOG 或者独立项目中常用的 C# 代码示例。我们使用 ADO.NET 来演示。

using (SqlConnection conn = new SqlConnection(connectionString))
{
    conn.Open();
    // 1. 先创建命令对象，指定 SQL 模板
    string sql = "SELECT * FROM Articles WHERE CategoryID = @CategoryId AND Status = 1";
    using (SqlCommand cmd = new SqlCommand(sql, conn))
    {
        // 2. 添加参数，使用 @符号标记占位符
        // 注意：这里并没有直接把变量拼进字符串！
        cmd.Parameters.AddWithValue("@CategoryId", categoryId);

        // 3. 执行查询
        using (SqlDataReader reader = cmd.ExecuteReader())
        {
            while (reader.Read())
            {
                // 解析 JSON 数据或者直接读取字段
                string title = reader["Title"].ToString();
                // 这里可以对接我们的在线工具或者前端 JS
            }
        }
    }
}

看到了吗？这就是 预处理语句 的正确打开方式。无论你在 @CategoryId 里面填什么，数据库都会把它当成纯文本处理，绝对不会把字符串解析成 SQL 命令。

对比 PHP PDO：通用思维

其实不只是 C#，像 PHP 的 PDO 扩展也是同样的逻辑。很多站长在维护自己的博客系统时，如果用的是 PHP 写的 EMLOG 插件，一定要确保启用了 prepare() 方法。

在 JSON 数据解析和接口开发中，我们经常需要处理前端传来的参数。如果处理不当，这些参数就会变成 SQL 注入的跳板。所以，养成“用参数绑定代替字符串拼接”的习惯，是每个后端开发者的必修课。

总结与避坑指南

1. 永远不要相信前端传来的数据：无论是用户名还是搜索关键词，在拼装 SQL 之前，必须经过清洗或直接使用预处理语句。 2. 性能优化：预处理语句在执行多次相同 SQL 时，数据库可以复用执行计划，反而比普通拼接的效率更高。 3. 代码规范：在写正则表达式过滤脏数据之前，如果能用预处理语句解决，就优先用预处理语句，这层保护最靠谱。

希望这篇零点博主整理的干货能帮到你。如果你在开发爬虫或者在线工具时遇到更多数据库问题，欢迎在评论区留言，我们下期见！