不用框架不等于乱堆代码。

这个博客虽然没有任何第三方依赖，但内部仍然按「入口—控制器—模型—视图」分层，用 PHP 自带的 spl_autoload_register 串起来。这篇文章记录为什么这样设计，以及为什么不干脆裸写到底。

整体结构。

入口层是 public/index.php 和 public/admin.php，它们非常薄：启动、加载、交给控制器，不写业务逻辑。

控制器层是 src/Controllers 下的 FrontController 和 AdminController，负责路由、参数、权限，然后调用模型、选择视图。

模型层是 src/Models 下的 Post、Category、Comment、User 等，所有 SQL 都集中在这里，并且全部使用预处理语句。

视图层是 src/views 下的 PHP 模板，只负责把数据渲染成 HTML，不直接写 SQL。

基础过程式模块是 db、session、csrf、auth、content 这些，负责单一的、明确的能力。

为什么不做成完整框架。

因为没有那个必要。框架的价值是应对复杂度和多人协作，而这个项目的复杂度是有限的、可控的、我一个人维护的。引入框架反而带来版本升级、配置约定和一层我并不需要的抽象。

为什么又不能裸写。

因为完全裸写的代价是「三个月后看不懂」。早期版本所有逻辑都塞在 index.php 和 admin.php 里，一个文件几十 KB，改一个功能要翻半天。分层以后，任何一个需求都知道该去哪一层改：文章列表去 Post 模型，页面渲染去 views，权限去 auth，互不干扰。

正文渲染：刻意放弃 Markdown。

我一度加过完整的 Markdown 渲染甚至数学公式支持，后来全部删掉了。原因是：我真正需要的只是「段落、换行、图片、链接」，Markdown 带来的语法复杂度、XSS 面和几百 KB 的前端库，对我是负收益。

现在的方案是最轻量的纯文本：按空行分段，网址自动转链接，图片用后台上传按钮插入一行固定语法，渲染时先转义 HTML 再处理。能力够用，攻击面很小。

为评论扩展预留结构。

comments 表的 user_id 可空，匿名评论时为空，未来开放注册时填上用户 ID；这就是「匿名 / 注册用户双路径」的结构基础。评论有独立的审核状态、限速表和蜜罐字段，后台有审核页。开放注册是以后的事，但表结构不需要推倒重来。

我的原则是：结构为真实的演进留空间，不为想象的需求过度设计。

这套结构让我满意的地方，不是它多先进，而是它的「可解释性」：任何一个请求进来，我都能清楚说出经过了哪几层、每个文件负责什么。一个三年后能自己维护的系统，比一个当下时髦的系统更重要。