Building for China with global infrastructure

这是第二篇占位文章，用来验证首页、列表页和文章详情页都能走真实的数据流。

后面接私有内容时，这些占位内容可以整体替换掉。

主 HTML 和静态资源要分开看

如果主域名没有备案，那么大陆访问体验的上限会被首页 HTML 的回源路径限制住。这个问题不能靠前端框架本身解决。

很多时候讨论“中国访问速度”会很容易掉进一个误区，好像只要把框架换掉、把前端资源上 CDN，问题就自然解决了。实际上，对首访体验影响最大的，仍然是最开始那份 HTML 从哪里回来、经过哪些链路、是否有合规和网络路径上的限制。

这也是为什么我会反复强调：不要把“资源加载快”误认为“整个站点访问快”。两者相关，但并不等价。

可以加速的部分

脚本、样式、图片和异步数据接口都可以走已经备案并带 CDN 的域名。

如果拆得足够清楚，很多东西都可以明显受益：

• JS 和 CSS 可以走缓存友好的静态域名
• 图片可以用独立策略托管和压缩
• 评论、阅读量、reaction 这些接口可以独立部署
• 搜索索引、RSS、feed 甚至都能单独服务

从用户角度看，这意味着第二屏、后续点击和附加功能都能更快；从工程角度看，这意味着主站可以始终保持足够简单。

不能假装解决的部分

主页面的 HTML 首包如果还在 bojin.co，那它仍然会决定用户第一次打开时的感知速度。

所以比较诚实的策略不是“宣称整站都在中国加速”，而是明确知道什么能优化，什么暂时不能优化。

我现在更偏向这样的部署原则：

1. 让主站 HTML 尽可能小
2. 让所有非关键功能异步化
3. 让静态资源尽量独立缓存
4. 不让任何动态接口阻塞正文

站点结构应该映射部署现实

如果你的部署边界本来就是分开的，那么页面结构也应该体现这个事实。一个静态优先的网站更容易做到这一点，因为它没有那么多“必须在首屏 SSR 时拿到的数据”。

举例来说，一篇博客文章真正必须在 HTML 首包里出现的，其实只有：

• 标题
• 摘要
• 正文
• 基本 meta

而这些东西都恰好适合提前构建。

把慢的东西挪走

这个思路并不复杂，难的是执行时是否足够克制。比如：

• 阅读量不应该在服务器渲染时顺便 incr
• visitor geo 不应该阻塞页面生成
• activity status 不应该成为首屏依赖
• 评论区可以先渲染骨架或静态预留

如果每个动态功能都遵守这个原则，主站整体会轻很多。

动态模块需要降级能力

当 api.nszero.net 不可达时，页面主体仍然应该完整可读。统计、访客地理和 reaction 都可以延后，不应该拖垮正文。

这不仅是性能问题，也是长期维护问题。个人站的动态模块很少有人 24 小时盯着运维，所以“坏了也不至于影响正文”的设计，比“理论上很先进”的设计更实际。

失败要可接受

一个理想的失败状态应该是：

• 正文照常打开
• 评论区显示暂不可用
• 阅读量缺失但页面没有报错
• 访客地理模块静默降级

而不是：

• 页面挂着 loading
• 组件布局塌掉
• hydration mismatch
• 某个接口失败把首屏打碎

为什么框架不是关键答案

不管你用 Astro、SvelteKit、Next 还是别的，只要首屏必须依赖远端动态数据，或者站点结构没有和部署边界对齐，结果都不会特别理想。

框架真正决定的是：

• 构建和内容组织是否顺手
• 交互模块是否容易后挂载
• 页面是否容易静态化

而不是神奇地替你解决网络现实。

最后会留下的其实是纪律

一套基础设施策略最后能不能成立，往往不是靠某一个高明技巧，而是靠是否愿意持续遵守几个简单纪律：

• 正文优先
• 主 HTML 最小化
• 动态增强后挂载
• 域名职责清楚
• 出错时优先保证可读性

只要这几条不乱，后面无论是补评论、补多语言还是补活动状态，都会轻松很多。