对于一名在职设计师来说，作品集网站处于一个尴尬的中间地带。它既要看起来精致，又要加载迅速，还得保持更新，同时不能占用过多的计费工时。我以前的方案是使用 Webflow，它在拖拽式构建器和专业输出之间找到了比大多数工具更好的平衡点。但当收到 300 英镑年费的续费通知时，我不得不问自己一个尖锐的问题：我是在为价值买单，还是仅仅为了方便？

我决定从零开始重建。新的技术栈是 Astro 和 Sanity。在使用了一段时间后，以下是具体的经验总结：哪些行之有效，哪些行不通，以及它与我之前使用的工具相比处于什么位置。

为什么作品集要用 Astro？

大多数现代 Web 框架都是先推送 JavaScript，然后再考虑其他问题。Astro 则颠覆了这一假设。它在构建时生成纯静态 HTML，只有当特定的组件确实需要时，才会向浏览器发送 JavaScript。他们称之为“孤岛架构”（islands architecture），但实际效果更简单：我的作品集页面几乎不占什么体积。

路由是基于文件的，因此创建一个新页面就像把文件丢进文件夹一样简单。如果你接触过 React、Vue 或 Svelte，你会发现组件的语法非常熟悉。每当我想要添加一个项目案例研究时，都不需要去学习新的范式。

话虽如此，我不会使用 Astro 来构建复杂的 Web 应用程序。如果你正在编写身份验证逻辑、管理全局状态或处理实时数据，你会发现是在与框架作斗争。但对于营销网站、博客和作品集来说，它非常省心。页面感觉很快，因为它们确实很快。不存在为了渲染一个标题或一段文字而等待“水合”（hydration）的开销。

从 WordPress 转向 Sanity

在这次重建之前，我的备选方案总是 WordPress 搭配 Advanced Custom Fields (ACF)。ACF 让 WordPress 拥有了超能力，但你仍然是在别人的房子里做配置。Sanity 的工作方式则恰恰相反。你通过代码编写 Schema，精确定义你的内容模型是什么样的，然后 Sanity 会围绕你的决策构建编辑界面。

我利用这种控制力，利用可复用的模块构建了一个简单的页面构建器。我定义了一次 Hero 区域，定义了一次客户证言轮播图，定义了一次卡片网格。现在，我可以按任何顺序堆叠这些模块来组装新页面，而无需编写新代码或触碰页面模板。

思维方式的差异至关重要。使用 WordPress 时，我经常觉得自己在与一个只想做博客的工具搏斗。而使用 Sanity 时，我觉得自己是在构建软件。内容变成了干净的结构化数据，而不是混合了短代码（shortcodes）的带样式的 HTML。我的项目描述变成了可移植的对象，如果我想，我可以将它们接入移动应用或新闻通讯中。

保持简洁的部署工作流

我以前的 WordPress 工作流是一团糟：FTP 上传、测试环境子域名，以及总是在最糟糕的时刻崩溃的插件更新。为了仅仅修复一个拼写错误，我都要在脑子里过一遍检查清单。

现在的工作流非常简短：

  • 我在本地进行更改并立即看到效果。
  • 当代码写好后，将其提交到 GitHub。
  • Vercel 接收推送并自动部署网站。

没有 FTP 客户端，不需要同步测试数据库。代码仓库就是单一事实来源（source of truth）。

内容的处理方式也是如此。当我在 Sanity 中发布或更新文章时，一个 webhook 会通知 Vercel 重新构建网站。静态页面会带着最新的内容重新生成，CDN 会自动更新，而我无需触碰任何服务器。一切都能保持同步，无需手动复制、导出，也不用祈祷插件数据库迁移真的成功了。

通过 Token 将设计与代码结合起来

这次重建中一个较小的突破是建立了一套完善的 Token 系统。我维护着一个单一的 JSON 文件，它掌控着网站中的每一个颜色、字号阶梯和间距值。这个文件就是“老大”。

我使用 Token Studio 将这些值直接引入 Figma。当我的设计文件显示 surface-default 时，它指向的数值与代码中使用的完全一致。一个简单的脚本会在构建时将 JSON 转换为 CSS 自定义属性，因此我的样式表引用的是像 --color-surface-default 这样的变量，而不是硬编码的十六进制颜色码。

这在实践中非常重要。如果我发现品牌红在移动端屏幕上显得过于激进，我只需修改 JSON 文件中的一个值。Figma 库会更新，CSS 会更新，全站的所有实例都会随之更新。我不需要使用 grep