前言：零点博客的一次深夜复盘

大家好，我是零点博客的开发者。昨天在优化 EMLOG 系统的一个第三方插件时，我差点因为一个低级错误导致数据库被拖库。虽然平时强调过 SQL注入 的危害，但在实际编码中，为了图快直接拼接字符串，往往是最容易被忽视的坑。今天就用这段真实的踩坑经历，结合 C# 代码，手把手教大家如何用预处理语句和参数化查询做底层防护。

问题还原：危险的字符串拼接

很多初学者在写代码时，喜欢用字符串拼接的方式来构建 SQL。比如在 PHP 或原生 JS 调用后端接口时，如果没经过严密的校验，黑客只需在输入框输入 ' OR 1=1 --，就能轻松绕过验证。虽然我们在 EMLOG 开发中常用 C# 或 PHP，但原理都是一样的。

错误的写法示例：

string userId = Request.QueryString["id"];
string sql = "SELECT * FROM emlog_user WHERE uid = " + userId;
// 此时一旦传入 ' OR 1=1 --，整个数据库将无所遁形

解决方案：参数化查询与预处理语句

要彻底根治 SQL注入，必须拒绝动态拼接 SQL 语句。我们要利用数据库驱动程序的预处理功能。在 C# 中，这是通过 SqlCommand 配合 SqlParameter 来实现的。

正确的防御代码：

using (SqlConnection conn = new SqlConnection(ConnString))
{
    conn.Open();
    string sql = "SELECT * FROM emlog_user WHERE uid = @UserId";

    // 使用参数化，数据库引擎会自动将 @UserId 当作普通字符处理，而不是代码执行
    using (SqlCommand cmd = new SqlCommand(sql, conn))
    {
        cmd.Parameters.AddWithValue("@UserId", userId);

        using (SqlDataReader reader = cmd.ExecuteReader())
        {
            while (reader.Read())
            {
                // 处理数据，比如转为 JSON 返回给前端
                userJson.Add(new { name = reader["name"].ToString() });
            }
        }
    }
}

底层逻辑与避坑指南

为什么要这么做？底层原理其实很简单：预处理语句会将 SQL 语句先发送给数据库编译，参数会被封装在边界符内，数据库将其视为数据而非可执行指令。这就好比我们要填表，不是自己写一张完整的表，而是把要填的内容交给了表格的专门填空位。

除了代码层面的防护，我们在开发 EMLOG 插件或通用接口时，还必须注意：

• 输入过滤： 在拿到 JSON 数据或表单数据时，先用正则表达式过滤非法字符。
• 最小权限原则： 普通用户权限不要赋予 DROP TABLE 等高危操作。
• 数据清洗： 对于爬虫抓取的数据，入库前务必进行 SQL 转义处理。

总结

无论是做 C# 后端还是 PHP 开发，SQL注入 都是建站开发的头号杀手。希望大家能把这个 预处理语句 的习惯刻进肌肉记忆里。源码案例已经放到了零点博客，大家可以直接下载对比学习。关注我，带你少踩坑，做懂底层的开发者。