从一个域名开始：搭建可持续更新的个人博客

最近完成的一项工作，是把一个只有域名的想法变成真正可以持续更新的个人博客。

一开始最容易低估的问题是：上线一个页面并不难，难的是建立一条长期可维护的链路。内容放在哪里、代码如何更新、域名怎么解析、动态功能在哪里运行、密钥怎样保存，这些决定共同构成了博客真正的基础。

不迁移代码，只迁移需求

最初有一个功能较完整的博客可供参考，包括文章、碎片、相册、项目、时间轴、友链、天气、音乐和智能助手。但直接迁移会把原作者的视觉语言、个人数据和历史包袱一起带过来。

最后采用的方式是只整理功能清单，然后从零重构：

• Next.js 与 TypeScript 负责页面和路由；
• Markdown 负责文章内容；
• 本地数据文件负责碎片、相册、项目和时间轴；
• 静态生成承担大部分公开页面；
• 服务端 API 只保留真正需要动态运行的能力。

这种做法比复制后大改更慢一些，但边界清楚。内容属于自己，代码结构也能围绕后续写作方式生长。

让内容和界面分开

所有文章都放在 content/posts 中，每篇文章是一个 Markdown 文件。标题、日期、分类、摘要、封面和标签写在 frontmatter 中，正文保持普通 Markdown。

---
title: "文章标题"
date: "2026-08-20"
category: "随笔"
excerpt: "一段摘要"
cover: "/images/posts/hello.webp"
tags: ["记录"]
featured: false
---

个人身份、域名、头像和天气城市则集中在 data/site.ts。这样修改城市或站点名称时，不需要到多个组件里逐个查找。对个人项目来说，集中配置比引入复杂后台更合适：简单、透明，也便于 Git 追踪。

GitHub 与 Vercel 的分工

GitHub 保存源码和内容，main 分支代表正式版本。每次提交推送后，Vercel 自动拉取代码、执行生产构建并更新线上站点。

这条链路把发布动作缩短成三步：

git add .
git commit -m "更新博客内容"
git push

部署平台曾考虑 GitHub Pages，但项目包含服务端 API。Pages 更适合纯静态产物，而 Vercel 可以直接运行 Next.js 的动态路由，因此最终选择后者。

域名配置里也遇到了一个典型误区：自定义 DNS 解析不等于修改 NS。实际只需要按 Vercel 给出的实时记录配置根域名和 www，删除原先指向 Pages 的冲突记录。DNS 验证通过后，Vercel 会继续签发 SSL 证书；看到 Generating SSL Certificate 时，等待即可，不应继续反复修改解析。

把助手接到 DeepSeek

右下角的助手最初接入另一套模型接口，后来改为 DeepSeek。前端仍然只请求站内的 /api/assistant，真正的模型请求由服务端完成。

这样设计有两个原因：

1. API Key 不会出现在浏览器代码和网络请求参数中；
2. 以后更换模型时，只需要修改服务端适配层，不必重写聊天窗口。

密钥使用 DEEPSEEK_API_KEY 环境变量保存。本地放在 .env.local，线上放在 Vercel Environment Variables，仓库里只提交空的 .env.example。服务端还限制了历史消息数量、单条长度、最大输出和请求时间，避免一次聊天无限消耗上下文。

这次工作的收获

这次建站让我重新确认了三件事。

第一，部署不是开发结束后的附加步骤，而是产品的一部分。只有更新路径足够短，博客才真的会被持续使用。

第二，独立博客的核心不是功能数量，而是内容所有权。先把文章和个人数据放进清楚、可迁移的结构，再考虑花哨功能。

第三，所有外部能力都应该通过明确边界接入。DNS、部署平台和模型 API 都可能变化，但只要边界稳定，更换其中一项就不会牵动整个项目。

博客已经上线，但它不会有一个真正的“完成”时刻。下一阶段比继续堆功能更重要的，是把占位内容逐步换成真实记录，让它从一个可用的网站变成属于自己的长期档案。