把个人博客从想法做到可用：YoungBlog 的第一个闭环

很多博客项目都停在“准备开始”。

域名想好了，页面也画过几版，但真正进入写作之前，总会卡在一个问题上：它到底是不是一个可以长期使用的系统。

YoungBlog 的这一版，不再把重点放在漂亮的概念图上，而是先把最小可用闭环搭出来。现在它已经不是静态样板，而是一套真的可以发布内容、管理文章、维护站点信息的博客 MVP。

为什么重新搭一套

我想要的博客，不只是一个文章列表页。它应该同时满足三件事：

• 读者进入首页时，能立刻理解这个站点在写什么
• 管理端写文章时，不需要每次都去手改数据库或源码
• 结构从一开始就清楚，后面继续扩内容、扩功能时不会推倒重来

所以这次我把它拆成了三层：

• blog：面向读者的前台，负责首页、分类、标签、关于页和文章阅读体验
• admin：面向管理的后台，负责文章编辑、封面上传、分类维护和站点设置
• server：面向数据和接口的后端，负责登录、内容读写、文件上传和持久化

这样的拆分有一个很直接的好处：以后无论是改界面、加字段，还是换数据库，都有明确落点。

TypeScript 和 Python 在这里各做什么

前台和管理端统一用 TypeScript，是因为它很适合把界面状态、接口返回值和表单数据串成一条稳定的链路。尤其是文章编辑这种场景，字段一多，类型一旦混乱，后续维护会很痛苦。

后端选择 Python 和 FastAPI，则是因为这一层更看重接口组织速度、模型表达能力和后期扩展。文章、分类、标签、站点配置这些资源都比较标准，用 FastAPI + SQLAlchemy 可以很快把边界理顺。

这次做下来，我越来越确定一个判断：

前端的重点是“交互组织得顺不顺”，后端的重点是“数据边界清不清楚”。

现在这个 MVP 已经能做什么

第一版先不追求复杂，而是把真正会天天用到的能力做扎实：

• 首页可以直接展示文章流，并支持置顶文章
• 分类、标签、关于页已经能独立进入
• 后台可以登录、创建文章、编辑旧文章、删除文章
• 文章支持 Markdown 编辑和实时预览
• 图片可以通过文件选择器上传，而不是手填 URL
• 封面图支持裁剪后再上传，前台卡片会按固定视觉比例展示
• 站点标题、首页文案、背景图、作者信息都可以在后台修改

这些能力放在一起，意味着这个博客已经从“能展示”走到了“能持续写”。

数据库驱动为什么重要

这次最关键的一个变化，是把内容真正落进数据库。

文章不再只是写死在内存里的几条假数据，而是通过 SQLAlchemy 模型进入 SQLite 持久化。这样一来，前台、后台、接口三端才真正说的是同一份内容。

数据库驱动带来的变化不只是“能保存”，而是很多后续功能终于有了基础：

• 文章编辑后刷新页面不会丢
• 新分类可以在后台创建并立即生效
• 站点设置修改后，首页和侧栏会同步变化
• 后面接 PostgreSQL、评论、搜索、统计时，不需要再换思路

MVP 看起来像是一个小版本，但只要底层是对的，它就已经具备继续长大的能力。

我最在意的不是功能数量，而是写作感受

博客最终还是为内容服务。

所以这一版开发里，我特别在意两种体验：

第一种是写作体验。
后台不能像在填表，而要像在真正整理一篇准备发布的文章。标题、摘要、正文、封面、分类和标签，应该是同一个工作流，而不是散落在几块互不相干的设置里。

第二种是阅读体验。
首页不是单纯把文章堆出来，而是让层次清楚、节奏稳定；文章卡片可以整块点击，封面图在需要时进入版式，而不是打断阅读。

我希望它读起来像一个长期更新的个人站点，而不是一套临时拼装出来的后台系统。

这篇文章之后，博客才算真正开始

到这里为止，YoungBlog 的第一阶段其实已经完成了最重要的一步：它能承接内容。

接下来再继续补更多能力，无论是评论、搜索、归档页，还是更成熟的摄影展示模块，都会是建立在这个闭环之上的扩展，而不是重新开始。

对我来说，这篇文章像一个路标。它不是宣布“项目做完了”，而是在说：这个博客终于可以认真写下去了。