我为什么要写博客，以及这个站点是怎么搭起来的

我在 2025 年下半年做完了自己的简历网站，一个页面就能把技能、项目、获奖情况全部摊开给 HR 看。按理说这件事就到此为止了。但我还是又花了几个晚上，搭了现在这个博客站。原因不复杂，只是简历网站解决不了三个问题。

简历装不下过程

简历的写法天生是结论式的：一行字写“负责前端开发与界面设计”，看起来干净利落，但删掉了所有让我当时头疼的东西。比如图书管理系统里“借阅”这个动作到底要不要扣库存、归还时逾期天数怎么算、中文字段按拼音排序为什么不对——这些细节在简历上不可能写，可它们恰恰是我真正学会的东西。

面试的时候我被问过一次：“你说你做了借阅状态实时更新，那如果两个人同时借同一本只剩一本的书，会怎么样？“我当场答得不太好，因为那个问题我在项目里确实遇到过、也处理过，但从来没写下来，细节已经模糊了。写下来就不一样，写的过程会强迫我把”当时怎么改的“回忆成一条清晰的链路。

写下来才会被检索到

还有一个很现实的理由：我遇到的报错，一定有人先遇到过。我在解决 Gemini 流式返回 JSON 解析失败的时候，搜索引擎把我带到过好几篇别人的博客，那几篇文章救了我至少两个小时。既然我从公开的写作里拿到了好处，那把自己踩过的坑也放出去，是很自然的事。

而且博客是长期资产。简历投出去就沉底了，但一篇讲清楚“SSE 分块响应黏包怎么处理”的文章，可能一年后还会有人搜到。对一个还在读书、没有大厂背书的学生来说，能被搜到本身就是一种低成本的可信度。

为什么选 Astro

我比较过几种方案，最后选 Astro，理由有三个：

第一，它以 Markdown 写作为中心。内容放在 src/content/blog/ 下，一个 .md 文件就是一篇文章，我不需要碰任何组件代码就能发布。用内容集合（Content Collections）还能在构建时校验 frontmatter 字段，写错日期格式会直接构建失败，而不是等到页面上显示成 Invalid Date。

第二，默认零 JavaScript。博客的主体是文字，读者不需要等一个框架 runtime 加载完才能看文章。Astro 会把页面在构建阶段渲染成纯 HTML，只有确实需要交互的组件才会被单独 hydrate。

第三，输出是纯静态文件。这意味着我可以把它托管到 Cloudflare Pages 这类静态托管上，一次构建产出一堆 HTML/CSS，没有服务器要维护，也不存在“半夜数据库挂了”这种事。

站点结构大概长这样

blog/
├── src/
│   ├── content/
│   │   └── blog/          # 所有文章，一篇一个 .md
│   ├── components/        # 卡片、导航、页脚这类复用组件
│   ├── layouts/           # 文章页与列表页的骨架
│   └── pages/             # 路由，index.astro 是首页
├── public/                # 图片等静态资源
└── astro.config.mjs

文章列表页会读取 src/content/blog 下的全部条目，按 pubDate 倒序渲染成卡片，卡片上显示的就是每篇 frontmatter 里的 title 和 description。所以 description 不能糊弄，它是列表视图里唯一一句话的摘要。

我的写作流程

现在流程已经压缩得很短了：

# 1. 新建文件，文件名用英文短横线连接
touch src/content/blog/mysql-index-basics.md

# 2. 写 frontmatter，四个字段：title / description / pubDate / tags
#    日期写裸日期，不加引号；tags 是字符串数组

# 3. 本地起开发服务器预览
npm run dev

# 4. 提交
git add . && git commit -m "post: 新增 MySQL 索引入门"
git push

推送之后托管平台会自动触发构建，几十秒后线上就是新版本。整个过程里我唯一需要认真对待的就是“写内容”这一步。

关于这个站点的更新

这里不会变成一个只发“我今天学习了 X”的流水账。我打算写的都是具体的东西：一个项目从设计到落地的完整过程、一个报错的排查路径、一个我原本理解错后来纠正的概念。目前计划的方向是后端基础（数据库、网络、操作系统）、Python 工程实践，以及每次项目结束后必须做的复盘。

内容会长期更新。如果你是从某篇具体的文章搜过来的，希望它至少帮你省下了我当时花掉的那两个小时。