个人技术博客为什么适合静态架构

建立个人技术博客时，很容易先想到后台、数据库和在线编辑器。但如果网站的核心需求只是“我写文章，其他人阅读”，动态系统往往不是必要条件。

静态网站会在发布阶段把 Markdown 转换为 HTML。访问者打开网站时，服务器只需返回已经生成好的文件，不必再查询数据库或执行服务端业务逻辑。

更短的发布链路

我的文章都放在项目的内容目录中：

src/content/posts/
├── static-site-architecture.md
├── frontend-performance-checklist.md
└── practical-git-workflow.md

每篇文章由一段结构化信息和 Markdown 正文组成。完成修改后提交到 Git，托管平台就会自动完成构建与部署。

git add src/content/posts
git commit -m "add: new article"
git push

这个流程有几个直接好处：文章和代码一起保留历史记录；写作不依赖某个在线后台；即使以后更换托管平台，内容文件仍然可以继续使用。

更清晰的安全边界

动态网站需要长期维护登录、权限、数据库、上传接口和依赖更新。静态博客没有注册入口和写入接口，公开环境只提供构建后的 HTML、CSS、JavaScript 与图片。

这并不代表静态网站绝对安全，但攻击面会明显缩小。对于只有一位作者的网站，发布权限可以完全交给 Git 仓库和托管平台管理。

功能越少，长期维护时需要关注的状态就越少。个人网站首先要做到的是能够稳定更新，而不是一次性拥有很多功能。

哪些情况不适合

如果网站需要实时评论、多人在线编辑、会员体系、订单或频繁变化的个性化内容，那么后端服务仍然有价值。架构选择应该跟随实际需求，而不是框架的功能清单。

目前这个博客只承担内容展示，所以静态架构已经足够。后续即使增加 RSS、站内搜索或访问统计，也可以优先选择不会改变内容发布权限的方案。

最终选择

这个网站使用 Astro 生成静态页面，文章使用 Markdown 编写，图片随项目一起发布。没有数据库，也没有面向访客的写入入口。

这样的结构并不复杂，但它保留了个人博客最重要的能力：内容归自己管理、发布过程可以追踪、网站能够低成本地长期运行。