零点博客复盘：C# 后端开发中 SQL 注入防护与预处理语句底层拆解
最近在零点博客的 C# 后端开发专栏里，有读者私信问我同一个问题：“为什么我的代码防不住 SQL 注入？” 说实话，很多刚入行的开发者，写代码像是在填空，根本没看懂背后的 SQL 逻辑。今天我就结合实战经验，不整那些虚头巴脑的 AI 套话，直接把 SQL 注入防护 和 预处理语句 的底层逻辑给大家扒开揉碎了讲清楚。
一、 这里的坑，是底层逻辑决定的
很多新手写 C# 后端开发接口时，习惯用字符串拼接 SQL，比如：
string sql = "SELECT * FROM users WHERE username = '" + name + "'";
如果前端传来的 name 是 admin' OR '1'='1，那么最终执行的 SQL 变成了：SELECT * FROM users WHERE username = 'admin' OR '1'='1'。这时候，不管密码对不对，你都被骗进去了。在零点博客的爬虫开发实战里，我也见过因为数据库查询慢（被注入拖垮），导致整个后端服务假死的情况。
二、 真正的硬核：C# 预处理语句
怎么解决？答案是预处理语句。这招的核心在于，数据库只把你的 SQL 当作“代码模板”，而不是“执行命令”。参数和 SQL 是分开传递的。
实战代码案例
看这段我在 零点博客 推出的在线工具开发教程里用过的代码：
string connStr = "Server=...;Database=...;User Id=...;Password=...;";
string sql = "SELECT * FROM users WHERE username = @username";
using (SqlConnection conn = new SqlConnection(connStr))
{
conn.Open();
using (SqlCommand cmd = new SqlCommand(sql, conn))
{
// 关键点：使用参数化查询，数据库会把 @username 当作普通数据，而不是执行代码
cmd.Parameters.AddWithValue("@username", name);
using (SqlDataReader reader = cmd.ExecuteReader())
{
while (reader.Read())
{
// 获取数据
}
}
}
}
注意看，我在 SQL 里只写了 @username，具体的值通过 cmd.Parameters 传进去。哪怕 name 里全是黑客代码，数据库也只会把它当成一个普通的字符串去匹配，绝对不会去解析后面的 OR 语句。
三、 接口开发与 JSON 数据解析的关联
很多同学只关注数据库有没有报错，却忽略了接口返回给前端的 JSON 数据。
如果我们没做好 SQL 防护，数据库直接抛出异常，或者返回了脏数据，前端 JS 在解析 JSON 时就会报错，导致页面白屏。良好的 C# 后端开发规范应该是：
- 所有 SQL 操作必须使用预处理语句。
- 后端捕获异常，返回标准格式的 JSON 错误码，而不是直接抛出内部错误。
四、 正则表达式辅助校验与避坑指南
预处理语句是最后一道防线，正则表达式 可以在前端和后端做第一道过滤。比如用户名只能包含字母和数字：
Regex regex = new Regex(@"^[a-zA-Z0-9]+$");
if (!regex.IsMatch(name)) return Json(new { code = -1, msg = "用户名包含非法字符" });
避坑指南：
- 千万不要相信前端传来的任何数据，哪怕你做了正则校验，后端也必须再查一遍数据库。
- 如果你是写爬虫开发，遇到需要 POST 数据的情况，同理要处理表单数据，防止爬取时被反爬机制检测到 SQL 异常。
- 如果你在用 EMLOG 这类 CMS 搭建博客，尽量使用其提供的 ORM（如 PHP 的 ThinkPHP 或 C# 的 Entity Framework），它们底层已经封装好了预处理语句，比你手写拼接安全得多。
总结一下，后端开发的核心就是安全与稳定。写代码之前，先想想万一有人恶意输入会怎样。希望这篇基于零点博客实战经验的文章，能帮你少踩几个坑，早点搞定那个让你头秃的接口。
评论一下吧
取消回复