59 lines
3.8 KiB
Markdown
59 lines
3.8 KiB
Markdown
---
|
||
title: "打造一个全新的 Blog 系统"
|
||
date: 2026-05-17
|
||
description: "从 WordPress 到 Typecho，再到 Astro + Bun + Git——讲述我如何构建一个轻量、现代、以 Git 为驱动的全新 Blog 系统。"
|
||
category: "tech"
|
||
tags: ["blog", "astro", "bun", "git", "markdown"]
|
||
pinned: true
|
||
author: "ddmt"
|
||
---
|
||
|
||
## 前言
|
||
|
||
前段时间，我关停了大量过时的站点，其中就包括 blog.ddmt.top。原因很简单：它们采用的技术已经严重落后，主要依赖大量归档文章作为阅读内容，早已无法满足需求。但当时我并没有急于重建，因为我还没有找到一个既高级又轻量、既前沿又兼顾读者阅读体验和作者写作体验的 Blog 方案。
|
||
|
||
在过渡期，我尝试了一种新的记录方式——在 Gitdts 上单独创建了一个仓库，通过 README.md 来更新服务器维护记录。这为后续搭建新站点提供了重要启发，直到一个全新的技术方案映入眼帘。
|
||
|
||
|
||
|
||
## 创作动机
|
||
|
||
我使用过的 Blog 程序不少，说实话，有些体验令人苦不堪言。
|
||
|
||
**Typecho** 是我最早使用的 Blog 程序，它着实令人着迷——强大的自定义插件、丰富灵活的模板，直到现在我仍然会推荐别人去尝试。但我最终放弃了它，原因也很简单：作为一个 Blog 站点，写作体验至关重要，而 Typecho 极其简陋的编辑器实在让人提不起写作欲望。
|
||
|
||
**WordPress** 毫无疑问是目前最强大的 Blog 程序，它拥有非常出色的编辑器，写作体验相当不错。但它实在过于庞大，每次加载都是对服务器的巨大考验，卡顿的页面同样让人难以提起编写欲望。
|
||
|
||
## 技术方案
|
||
|
||
我最终选择了一套全新的技术栈：**Astro + Bun + Git**，由 AI 辅助构建。
|
||
|
||
### 没有传统意义上的后端
|
||
|
||
这里的 Bun 在页面创作中主要参与开发和编译环节。正如渡一教育的老师对 Node 的见解——「Node 对于前端的意义是更大的」。Node.js 虽然是面向后端设计的 JavaScript Runtime，但在实际使用中，它更多地加速了前端框架的构建。Bun 在这个项目中的意义也类似：它主要充当一个自动化构建器的角色，监听来自 Gitdts 的 Webhook，通知 Bun 何时应该拉取最新代码并自动完成构建。构建完成后，仅做静态托管。
|
||
|
||
### 没有数据库
|
||
|
||
所有内容完全来自 Gitdts 仓库中的 Markdown 文件。正因为没有数据库，我可以借助全球最顶尖的内容数据源——Git。利用其原生的版本控制、分支管理、同步等能力，使内容可以在任意地方进行编辑和管理。
|
||
|
||
### 没有网页编辑器
|
||
|
||
正因为没有网页编辑器，我可以直接使用全球最优秀的文本编辑器——VSCode。它对 Git 的支持非常好，无需再额外开发一个网页编辑器。我无法想象那会是多大的工程量：必须考虑多端适配，甚至多人协同编辑，否则编辑器不好用，实在难以下笔。
|
||
|
||
## 构建架构
|
||
|
||
这套系统主观上采纳了 PHP 和 Pages 的优秀设计理念，使其在构建时如同 PHP 一样优雅，在上线后轻量到 Pages 即可稳定运行。
|
||
|
||
整体构建流程如下：
|
||
|
||
1. 在本地编写 Markdown 文件并推送到 Git 仓库
|
||
2. Gitdts 通过 Webhook 通知 Blog 服务器
|
||
3. 服务器验证签名，拉取最新内容，触发 Astro 全量构建
|
||
4. 新的静态文件立即生效
|
||
|
||
从代码推送到站点更新，整个过程仅需数秒。
|
||
|
||
## 总结
|
||
|
||
这是一个非常令我满意的作品。它用最前沿的框架、最先进的工具链，构建了一个轻量、高效、以 Git 为驱动的现代 Blog 系统。没有臃肿的数据库，没有复杂的后台，只有 Markdown、Git 和一个快速的构建流水线。
|