为什么工作室官网最后选择了 static-first

成熟 starter 的价值很明确：当产品真的需要它已经预设好的能力时，可以省下很多时间。

问题出现在另一种情况：一个很小的网站，被迫背上一个比自己大得多的产品架构。

这次工作室官网重建遇到的就是后者。

先问网站到底需要完成什么

V1 官网当前只需要做好几件事：

让第一次访问的人快速理解工作室做什么；
发布真实 Projects 和构建记录；
支持英文默认、简体中文版本；
让搜索引擎和 AI crawler 能直接读到主要内容；
给潜在客户一个简单的联系入口。

它当前不需要账号、订阅、credits、后台、RBAC，也不需要一个数据库驱动的应用 runtime。

旧模板之所以包含这些东西，是因为它的目标是快速启动 SaaS。那些能力本身没有问题，只是和这个网站当前的工作不匹配。

迁移前，先看线上到底是什么

我们没有先去找旧源码，而是先把线上能观察到的事实记录下来。

旧 production 仍然返回 Next.js / OpenNext 相关响应。/blog 和 /showcases 都是 200，但内容明显还是模板占位；sitemap 甚至仍指向 https://your-domain.com/，页面也存在重复 canonical。

与此同时，随机不存在的 URL 返回的是真实 404。

这些都应该被记录。迁移不是为了证明“旧站很差”，而是准确知道什么需要保留、什么不值得继承。

我们把“业务迁移”和“运行时迁移”拆开了

这两个概念经常被混在一起。

业务迁移关注的是：旧 URL、可能存在的搜索权益、已经公开的内容和历史事实，哪些还有价值。

运行时迁移关注的是：旧 framework、依赖和部署方式，要不要继续保留。

前者可能有业务价值；后者必须有证据证明值得。

对于这个网站，没有证据说明继续背负旧 runtime 会带来价值，所以新基线收敛成：

Astro static-first + Markdown/MDX + Cloudflare Workers Static Assets。

不做旧兼容层，不默认 SSR，也不为了“以后可能需要”先放一个数据库。

先在隔离环境证明它够用

新站没有直接接到 production domain。

我们先建立独立 repo，实现真实双语 URL，生成静态 HTML，再部署到单独的 workers.dev staging。

真正容易悄悄出错的地方都被做成了验收项：

核心页面是否返回真实 200；
缺失 URL 是否返回真实 404；
非规范 trailing-slash URL 是否正确归一；
每页是否只有一个 canonical；
EN/ZH hreflang 与 x-default 是否互相对应；
staging 是否保持 noindex；
sitemap 是否使用真实 staging hostname；
主要正文是否直接存在于 raw HTML；
Googlebot、Bingbot、OAI-SearchBot 和普通浏览器 UA 是否都能访问。

同时还用真实 device metrics 检查 390px 和 1440px 下的页面宽度，确认没有横向溢出。

一次有价值的测试误判

第一次移动端截图看起来像是页面仍然被裁切：Header Menu 消失了，标题右侧也像被截掉。

最后发现不是 CSS 还没修好，而是 macOS Chrome headless 对 layout window 有最小宽度限制。请求 390px，并不代表真实 viewport 就一定是 390px。

改用 Chrome DevTools Protocol 的 device emulation 后，实际测得：

innerWidth = 390
document.scrollWidth = 390

这件事提醒我们：截图只有在测试环境本身满足条件时，才算证据。

架构决定要看它能不能经受后续变化

最初选择 static-first 时，网站还很简单。

后来首页加入了可逆的滚动叙事，内容变成完整双语结构，也增加了首批 Project evidence。产品 surface 明显变复杂了，但这些变化仍然没有产生引入 SSR、数据库、auth 或更重 runtime 的真实理由。

这比最初的 framework 对比更有说服力：产品变大了，架构仍然可以保持小。

这之后，真正重要的问题已经换了

到了上线准备阶段，主要不确定性已经不再是“这个网站需不需要更强的 runtime”。

在那个上线前阶段，更重要的问题转向产品和 release 边界：首批 Projects / 构建记录是否已经足够建立信任、潜在客户怎样用最低摩擦开始对话、英文和中文怎样在共享事实的同时各自保持自然，以及旧 production binding 和 redirect 怎样在一个有边界的 rollback window 内安全切换。

这些都不是继续给官网增加框架能力的理由。后续 production cutover 也验证了这一点：apex 切到独立 Static Assets Worker，旧 Worker 只在切换与早期 post-launch acceptance 阶段保留；新 production 路径稳定后，旧 Worker 与其专用 D1 database 已退役，而网站架构本身无需升级。