零点博客开发实录：C#与EMLOG结合下的后端架构与前端避坑指南

大家好，我是零点。这次折腾的“零点博客”系统，技术栈比较杂，核心用C#做后端，配合EMLOG做前端渲染，外加一些Python爬虫做数据清洗。以前总觉得开源的CMS（内容管理系统）随便改改就能用，真到自己动手架构的时候才发现，坑真的不少。今天就把这次开发中遇到的各种“拦路虎”和解决方案整理出来，算是一份真实的避坑指南。

一、选型误区：为什么我们要在C#里揉进EMLOG？

刚开始做项目时，我想着既然PHP的EMLOG轻量，就直接用PHP写；但考虑到后台管理要复用我们现有的C#管理系统，最终决定用C#提供API接口，前端渲染交给EMLOG。这一步看似省事，其实埋下了不少隐患。

在实际开发中，C#和PHP的接口开发经常出现数据格式对不上的情况。EMLOG返回的是PHP风格的数组，而我们的C#后端期望的是标准的JSON/XML。如果直接用JavaScript的`eval()`或者旧版解析器，很容易因为数据类型丢失导致程序崩溃。我后来直接写了一套JSON解析的中间层，才彻底解决了这个问题。

二、数据库安全：最容易被忽视的SQL注入防护

很多博主在写文章时喜欢生成SQL语句拼接，但在零点博客的开发中，我是坚决反对直接拼接的。因为这次项目深度结合了MySQL数据库与SQL语句操作，一旦写错字段名，整个表结构都会乱。

踩到的最大坑就是SQL注入。一开始为了图快，我用字符串拼接去查用户登录信息，结果被红队测试直接绕过登录了。痛定思痛，我重写了数据访问层，强制使用预处理语句。

这里分享一个C#的代码片段，这就是我用来做SQL注入防护的核心：

string sql = "SELECT * FROM user WHERE username = @Username";
using (SqlCommand cmd = new SqlCommand(sql, connection))
{
    cmd.Parameters.AddWithValue("@Username", inputUsername);
    // ...执行查询
}

这行代码加进去后，哪怕输入的字符串里带了单引号或者注释符，数据库也只会把它们当成普通字符处理，不会再去解析我们的SQL逻辑。这个习惯一定要养成，这是Web开发的底线。