静态网站的更新与维护机制

你提出了一个非常核心的问题：“dist 里面是静态文件，那每次更新内容都需要重新打包吗？”

简短的回答是：是的，必须重新打包。

但这背后的逻辑和如何让这个过程“自动化”，是现代前端开发中非常重要的一环。

1. 为什么必须重新打包？

要理解这一点，我们需要区分源码和产物。

• 源码 (Source Code)：也就是你在 docs 目录写的 .md 文件和配置文件。它们是给人看的，也是易于编辑的。
• 产物 (Artifacts)：也就是 dist 目录下的 HTML/CSS/JS 文件。它们是给浏览器看的，经过了压缩和优化，很难人工阅读或修改。

VitePress 的工作就像要把“大米”加工成“熟饭”。

• 当你修改了 Markdown 文件（换了种大米），dist 里的 HTML（那锅饭）并不会自动变。
• 你必须再次运行 npm run docs:build（重新煮饭），才能生成新的 HTML 文件。

如果你只改了源码但没有重新打包，直接把旧的 dist 传到服务器，网站上显示的自然还是旧内容。

2. 只有静态网站是这样吗？

是的，这就是静态站点生成器 (SSG) 的特点。

与之相对的是 动态网站（SSR / PHP / Java 等）：

• 动态网站在用户访问时，服务器实时从数据库里拉取内容拼成页面。你改了数据库，用户刷新即见。
• 静态网站（如 VitePress）在构建阶段就把页面生成好了。虽然灵活性不如动态网站，但它的访问速度和安全性是最高的。

3. 每次都要手动运行 build 很麻烦怎么办？

如果在 10 年前，我们确实需要：

1. 写文章
2. 运行 build 命令
3. 打开 FTP 软件
4. 把 dist 文件夹上传覆盖

但现在，如果你觉得“写完文章还要打包再上传”很繁琐，那是因为你还没有使用 CI/CD（持续集成/持续部署）。

自动化部署 (CI/CD)

这是现在最主流的做法。我们通常会把打包和发布的工作交给“机器人”（比如 GitHub Actions, Vercel, Netlify）。

理想的工作流是这样的：

1. 你只管写：在本地写好 Markdown。
2. 推送代码：执行 git push 把源码同步到 GitHub。
3. 自动打包：GitHub 上的监测服务发现你更新了代码，自动启动一个云端服务器，帮你运行 npm run docs:build。
4. 自动发布：云端服务器打包好后，自动把生成的 dist 内容推送到你的网站服务器。

在这个流程中，你确实需要“重新打包”，但这个动作是云端自动完成的，你完全感觉不到它的存在。

总结

• 手动模式：每次更新文章 -> 本地运行 npm run docs:build -> 手动上传 dist 目录。
• 自动模式 (推荐)：每次更新文章 -> git push -> 云端平台自动构建并更新网站。

所以，虽然原理上必须重新打包，但通过工具，我们可以让这个过程对人类“隐形”。