零点博客实战：C#与MySQL结合开发RESTful接口，从防注入到正则清洗的全流程拆解

最近在折腾零点博客的二期开发，重点是想把传统的 PHP 静态页面交互起来。作为一个老前端转全栈，我也算是个典型的技术折腾党。这次的目标很明确：后端接口开发实战。我们要用 C# 搭建一套基于 .NET Core 的 Web API，去调用底层的 MySQL 数据库，给前端提供数据，顺便还得整几个在线小工具爬取点数据。过程那是相当曲折，今天把这些底层拆解和踩过的坑都复盘一下。

一、 接口设计与 JSON 数据流转

做接口开发，第一步永远是定义好交互协议。我们用标准的 RESTful 风格，比如获取文章列表，接口地址就是 `/api/article/list`。这里有个细节很容易被忽略：前端传参和后端接收，数据格式要统一。

在 C# 中，我们主要依赖 `Newtonsoft.Json` 库来处理 JSON/XML 数据解析。上次因为序列化字段名的大小写问题，导致前端 JS 调用时报错 400，排查了半天才发现是 PascalCase 和 camelCase 的事。建议大家在接口返回时统一使用 `camelCase`，这样 JS 接收时最舒服。

二、 避坑指南：SQL注入防护与预处理语句

写后端最怕什么？不是Bug，是安全漏洞。以前写 PHP 的时候，直接字符串拼接 SQL 经常提心吊胆。这次用 C# 重写，我强制自己只用预处理语句。

比如我们要根据 ID 查文章：

// ❌ 错误示范（绝对不要这样）
string sql = "SELECT * FROM emlog_article WHERE id = " + articleId;

// ✅ 正确示范（使用参数化查询）
string sql = "SELECT * FROM emlog_article WHERE id = @id";
SqlCommand cmd = new SqlCommand(sql, conn);
cmd.Parameters.AddWithValue("@id", articleId);

这里必须强调一下 SQL注入防护。很多初学者图省事，把用户输入的 URL 参数直接拼进 SQL 里。黑客只要传个 `1 OR 1=1`，数据库就崩了。预处理语句会先把 SQL 结构定好，把参数当成纯粹的值传进去，哪怕里面包含恶意字符，数据库也只会把它当字符串读，绝不会执行。

三、 结合正则表达式与爬虫开发实战

既然要做爬虫开发和在线工具，正则表达式（Regex）就是我们的外挂。这次我们在零点博客里加了一个“代码高亮预览”的接口，需要从 GitHub 上抓取一些字体图标库的数据。

在处理 HTML 字符串去噪时，正则简直太好用了：

string htmlContent = "...大段HTML源码...";
Regex regex = new Regex(@"<img[^>]+src="([^"]+)"[^>]*>", RegexOptions.IgnoreCase);
MatchCollection matches = regex.Matches(htmlContent);
foreach (Match match in matches)
{
    // 提取 src 属性里的图片地址
    string imgUrl = match.Groups[1].Value;
    // 这里就可以进行后续的 HTTP 请求了
}

通过这个例子可以看到，正则结合 HTTP 请求，就能轻松写出一个简单的网页内容解析器。不过爬虫开发一定要加延时，否则 IP 被封了就惨了。

四、 前端交互与 MySQL 慢查询优化

接口写好了，还得跑得快。我们在开发中发现，当查询数据库的 MySQL数据库 数据量超过 10 万条时，接口响应时间直接飙到 2 秒。这肯定不行。

经过底层拆解，发现是 where 条件里的字段没有加索引。于是我们在 SQL 语句操作层面，给 `emlog_article` 表的 `create_time` 和 `uid` 字段都加了索引。加上索引后，同样的查询语句，响应速度直接变成了 50ms。这个经验一定要记下来：接口性能瓶颈往往出在 SQL 语句没写好，而不是 C# 代码本身。

五、 总结

这次从 C# 后端到 MySQL 数据库，再到正则爬虫和前端 JS 调用的全流程实战，让我对 后端接口开发实战 有了更深的理解。核心就三点：1. 接口协议要规范（RESTful）；2. 安全永远第一位（预处理防注入）；3. 关注性能（索引优化）。

如果你也在搞零点博客源码或者其他类似的 CMS 开发，希望这些干货能帮你避开弯路。源码部分我会单独整理一个压缩包，就在留言区置顶。