实战复盘：基于 C# + EMLOG 的在线工具开发底层原理与安全避坑指南

大家好，我是零点博客的博主。最近在整理过去两年做EMLOG二次开发的一些沉淀，很多老粉私信问我，从PHP转战C#做博客插件或在线工具到底要注意什么？其实最大的坑不在于语法，而在于安全和底层逻辑。今天我们就通过一个“简易爬虫”在线工具的改造案例，聊聊C#开发EMLOG扩展时必须要懂的避坑指南。

一、绕不开的 SQL 注入：预处理语句才是王道

在之前的PHP开发中，大家习惯了直接拼接SQL字符串，但在C#中，如果你不切换思维，EMLOG的后台管理极大概率会变成黑客的后花园。这是我踩的第一个大坑。

在开发EMLOG插件时，我们需要查询数据库获取用户配置。错误的写法是这样的（千万别学）：

string sql = "SELECT * FROM emlog_options WHERE name = '" + optionName + "'";

这种写法在输入未过滤时，直接导致SQL注入漏洞。正确的避坑指南是使用 SqlCommand 和参数化查询：

using (SqlConnection conn = new SqlConnection(connString))
{
    string sql = "SELECT * FROM emlog_options WHERE name = @Name";
    using (SqlCommand cmd = new SqlCommand(sql, conn))
    {
        cmd.Parameters.AddWithValue("@Name", optionName);
        conn.Open();
        using (SqlDataReader reader = cmd.ExecuteReader())
        {
            while (reader.Read()) { ... }
        }
    }
}

注意：参数化查询能有效防止SQL注入，这比简单的字符串过滤要靠谱得多。

二、前后端交互：JSON 解析别再用正则乱炖

很多初学者为了省事，喜欢用正则表达式去解析JSON字符串，或者直接用反射硬解。这在处理爬虫获取的API数据时，代码会变得极其难以维护。

我们需要做一个在线工具，将抓取到的网页数据解析出来。面对复杂的JSON数据，C#的 `Newtonsoft.Json` 库才是我们的救星。

避坑点： 除非数据结构极其简单且难以通过反序列化处理，否则不要用Regex去匹配JSON字段。反序列化后是强类型的对象，你还需要判断字段是否为空，比正则写起来快得多，且不容易出现空指针异常。

三、爬虫开发的坑：编码与异步请求

我们的需求是爬取其他博客的XML数据，然后解析入库。在写爬虫时，我遇到过两个严重的避坑问题。

1. 编码陷阱：很多网站不明确声明Content-Type，导致用C#读取到的数据全是乱码。必须显式设置请求头 `Accept-Charset` 并在读取流时指定编码。

2. 同步阻塞：HttpClient如果不配合 `using` 使用，连接池耗尽会导致程序卡死。务必使用 `async/await` 异步编程模型。

四、底层实现：从源码看数据流

为了让这个工具跑在EMLOG上，我们需要写一个Web API接口。前端通过Ajax发送请求，后端C#处理后返回JSON。

这里的关键在于处理好C#的MySQL连接超时问题。爬虫任务耗时较长，如果连接数设置得太少，EMLOG后台操作都会卡死。

代码片段：异步爬取示例

public async Task<string> FetchDataAsync(string url)
{
    using (var client = new HttpClient())
    {
        client.DefaultRequestHeaders.UserAgent.ParseAdd("Mozilla/5.0...");
        var response = await client.GetAsync(url);
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync();
    }
}

总结

从PHP转C#开发EMLOG扩展，不仅仅是换了个语言，更是思维模式的转变。防御SQL注入、正确处理JSON与XML、规范使用异步编程，这些都是高亮输出。希望这篇基于零点博客实战经验的避坑指南，能帮大家少走弯路。源码已在仓库开源，欢迎star交流！