搭这个博客的初衷很简单：我想找一个安静、可控的地方，把平时的工程学习、集成电路和项目复盘整理成容易阅读、也容易长期维护的文章。整个站点真正跑通之后回看，我花心思最多的地方其实不是首页长什么样，而是怎样让内容结构、阅读体验和发布流程像齿轮一样咬合在一起。
先把文章当作内容，而不是页面
在技术栈上，我用了 Astro 来生成静态页面，所有文章都以本地 Markdown 文件的形式保存在仓库里。每篇文章只通过顶部的 frontmatter 描述自己：标题、摘要、日期、分类、标签、语言（zh / en）以及是否为草稿。写作时我完全不需要关心页面布局，Astro 会自动根据这些字段衍生出文章列表、分类页、标签页和 RSS 订阅源。
这套内容模型看起来很轻，但它是后续一切维护体验的基石。因为所有字段都由 Schema 统一校验，哪怕我不小心漏写了日期或填错了语言代码，构建阶段就会立刻报错拦截，而不会把坏页面推到线上；还没写完的半成品只要标上 draft: true，就可以安心留在仓库里随代码一起同步，不会出现在公开列表里。对以写作为核心的个人网站来说，先把内容的契约定清楚，远比先堆砌一堆花哨的页面重要。
让双语和检索融入日常阅读
因为我平时经常在中英文资料和双语项目文档之间切换，所以一开始就把网站做成了双语结构：顶栏导航和界面文案可以随时在中英文之间切换，文章则通过语言字段各自归档。无论是中文复盘还是英文技术梳理，列表、标签、详情页和 RSS 都从同一个内容集合里生成，不需要在两个目录里重复维护逻辑。
站内搜索我也特意保持了克制：直接由浏览器在前端匹配已发布文章的标题、摘要、分类和标签。在目前几十篇文章的体量下，这种零外部依赖的做法响应极快，也省去了维护全文检索服务的成本；等哪天文章数量真正涨到需要分词索引时，再升级也不迟。
静态网站也能塞进个人小工具
除了写文章，我还在这个网站里夹带了一点“私货”——一个给自己平时背单词和练变位用的词汇卡片工具。为了不让这个功能把整个静态博客拖成复杂的后端应用，我把架构拆成了两半：页面骨架依然随 Astro 一起静态生成，而账号登录和词条持久化则直接交给 Supabase Auth 与 Postgres，靠数据库的 RLS（行级安全策略）隔离数据访问。
这次尝试也给我提了个醒：但凡接入外部服务，就必须把“未配置”或“连接失败”的状态设计好。 当环境变量里还没有填入背词服务的密钥时，页面会直接给出清晰的配置说明，而不是留下一块点不动、也不报错的空白区域。以后如果再往博客里加交互实验，我也会坚持这个原则——先把边界和降级状态交代清楚。
视觉细节服务于长文阅读
在视觉上，我用了浅蓝与暖色调的柔和渐变、半透明面板和克制的卡片层次，同时配齐了深色模式。文章页、顶栏导航和交互控件共享同一套 CSS 颜色变量，切换主题时不会出现割裂感；清晰的键盘焦点环和窄屏响应式布局，则保证了无论用电脑还是手机都能顺畅阅读。
对我来说，这些视觉细节不是独立于文字的装饰。技术长文的停留时间往往比普通页面长得多，正文的散文行宽、标题上下的呼吸留白、代码块与表格的横向滚动、以及侧边目录的锚点定位，每一处都会直接影响读者能不能耐心地读完一篇两千字的项目复盘。
发布链路越短，更新越容易坚持
过去很多个人博客之所以荒废，往往是因为“写完文章到成功上线”之间的摩擦力太大。所以我用 GitHub Actions 把发布链路压到了最短：只要本地把修改推送到 main 分支，工作流就会自动安装依赖、跑完 Astro 类型与 Schema 检查、编译出静态的 dist/ 目录，再直接同步到腾讯云服务器上由 Nginx 托管。生产服务器干干净净，既不需要跑 Node.js 服务，也不需要拉取 Git 仓库。
这样一来，“发一篇新博客”在日常操作里就彻底简化成了一次 git push。唯一需要留意的是 GitHub Secrets 里的站点域名（SITE_URL）、服务器 SSH 密钥和 Supabase 配置必须维护准确——如果站点地址配错，生成的 RSS 链接和页面元信息也会跟着偏掉。
这次构建留给我的三点经验
回看整个搭建过程，有几条经验让我印象很深：
- 内容 Schema 是长期写作的基础设施：分类、标签和语言字段越早规范化，后面的归档、搜索和 RSS 就越省心。
- 静态优先不等于拒绝动态交互：把需要持久化的状态剥离给 BaaS 服务，静态博客一样可以舒服地承载个人小工具。
- 构建跑通不代表体验闭环：从提交记录里就能看到，像 Markdown 宽表格溢出、深色模式下的对比度这些细节，都是拿真实长文去排、去读才暴露出来的。
对个人网站来说，最好的技术方案从来不是架构最炫酷的方案，而是让自己愿意常写、让读者能安静读完、每次更新都毫无心理负担的方案。现在地基已经打好，接下来要做的，就是拿一篇篇真实的项目记录去填满它。