为什么是 Astro#

Astro 是为内容网站而生的静态站点生成器：文章就是 Markdown 文件，构建时全部渲染成静态 HTML，默认几乎不往浏览器塞 JavaScript（它管这个叫 islands 架构）。对博客来说意味着：打开速度快、SEO 天然友好、内容以纯文本形式永远属于你。写作体验就是在编辑器里写 Markdown，没有后台、没有数据库。

对比过的选项：Next.js（全功能 React 框架，给内容站用是杀鸡用牛刀）、Hugo（构建更快但主题定制不如 Astro 灵活）、Hashnode/Substack（又回到平台号的老问题）。

为什么是 Fuwari#

Astro 官方的 blog 模板极简到寒酸:没有标签、没有搜索、没有暗色模式。我逛了一圈社区主题,发现它们大致分两派:

• 欧美系极简派(AstroPaper、Cactus、Micro 这些):清一色黑白灰、纯文字流,工程师味很浓。功能没毛病,但挂自己的名字总觉得冷冰冰的,少了「个人博客」该有的那种柔和感
• 视觉系(多出自中文/日文社区):卡片式布局、封面图、圆角、动画,一眼「这是个人的地方」

我最后选了视觉系里最成熟的 Fuwari(4700+ stars,中文社区作者) 全文搜索(中英文都能搜)、标签、分类、归档页、暗色模式、可调主题色、文章目录,全部开箱即带,颜值和功能难得两全。备选里还看过 Yukina(更漂亮但社区小,长期维护风险高)和一些多语言 fork(个人 fork 会跟不上原版更新,pass)。

多语言：轻方案胜过重方案#

我写中英双语。常见做法是整站 i18n 路由（/zh/、/en/ 两套页面),但那意味着每篇文章都欠一个翻译债——只有单语版本的文章会在另一套路由里开天窗。

我用了轻得多的方案：frontmatter 里加一个 translationKey 字段，中英两版共享同一个 key，文章页顶部自动出现「阅读中文版 / Read in English」按钮，顺便输出 hreflang 标签给搜索引擎。没有配对的文章什么都不显示，零负担：

1
---
2
title: "Making AI Customer Service Feel Human"
3
lang: en
4
translationKey: ai-customer-service-feel-human   # 中文版填同样的 key
5
---

这个功能 Fuwari 没有自带,是让 Claude 在主题上加的——几十行代码,一次对话的事。同样方式还加了文章系列（series）功能和 canonical URL 支持。

坑 0：一次买几年？#

一年就够,开自动续费。Cloudflare 是成本价注册商,续费价 = 注册价,多买没有折扣。「域名注册年限长有利 SEO」是流传很广的谣言,Google 官方辟过谣。真正的风险是忘续费被抢注——解法是 auto-renew,不是预付十年。

坑 1：Vercel 里,Connect 还是 Redirect？#

在 Vercel 项目的 Domains 页面添加域名时,每个域名要二选一：

• Connect to an environment (Production) = 这个域名直接服务网站
• Redirect to Another Domain = 这个域名只是别名,访问它会跳去别处

规则其实一句话：主域名选 Connect,其余全是 308 Redirect 指向主域名。

我的配置：

两个细节坑：

307 还是 308？ 都是重定向,区别在「临时 vs 永久」。308 Permanent 告诉搜索引擎「记住新地址,权重也转移过去」;307 Temporary 则是「下次还来问我」。别名域名一律 308。

apex 还是 www 当主域名？ Vercel 添加域名时默认勾选「Redirect apex domains to www (recommended)」,我一开始没注意,结果方向反了——变成裸域名跳 www。但我的站点配置（Astro 的 site 字段,决定 sitemap/RSS/hreflang 里的绝对链接）写的是不带 www 的裸域名。两边必须一致,所有 SEO 信号才会统一指向同一个规范 URL。我又回去把方向翻了过来。用哪个当主域名都行,关键是「选定一个,处处一致」。

坑 2：Cloudflare 那一排字段到底是什么#

配置完 Vercel,它会显示「Invalid Configuration」并给你一张表,让你去 DNS 服务商那里添加记录。这时你面对的是 Cloudflare 的 Add record 表单、Name、Content(Target)、Proxy status、TTL——每个字段展开讲:

一条 DNS 记录 = 「谁(Name)+ 什么类型的查询(Type)→ answer 是什么(Content)」,本质是全世界共享电话簿里的一行。

Name 是相对于你域名的前缀:

带不带 www 在 DNS 眼里是两个无关的名字,所以要各配一条——这也回答了「为什么要加两条记录」。

Type 决定这行规则回答什么问题:

Vercel 让你用 CNAME 而不是 A 记录,是有讲究的 指向的是 Vercel 的一个中间名字(形如 xxxx.vercel-dns-017.com),Vercel 以后换 IP、扩容、调度,都在那个名字背后自己完成,你的 DNS 永远不用再动。

Content/Target 就是答案本身。我在这里结结实实踩了一跤:

❌ Content for CNAME record is invalid.

因为我填的是 https://blog-xxx.vercel.app/——一个网址。CNAME 的 target 必须是纯主机名:没有 https://(那是协议),没有结尾的 /(那是路径),而且填的应该是 Vercel 给的专用 DNS 接入点,不是你项目的 .vercel.app 地址。正确姿势是直接点 Vercel 表格里的复制按钮。

**TTL(Time To Live)**是这条记录允许被缓存多久。DNS 是层层缓存的体系(浏览器→系统→路由器→运营商),TTL 就是答案的保质期:太长,你改记录后全世界要等很久才看到新值;太短,缓存老失效、查询变多。选 Auto(Cloudflare 默认约 5 分钟)就好。

坑 3(最反直觉的一个):为什么要关掉 Cloudflare 的 Proxy#

Cloudflare 的招牌功能就是橙色云朵——当你网站的代理,帮你挡攻击、做 CDN、上 HTTPS。DNS 页面还会弹黄色横幅劝你:“Proxying is required for most security and performance features”。

但接 Vercel 时必须选灰云(DNS only),这不是可选项。

原因是角色冲突 本身就是一个全功能边缘平台,自带全球 CDN、自动 HTTPS、DDoS 防护——橙云提供的所有好处,Vercel 已经内置了。开着橙云变成两个中间人打架:

1. HTTPS 证书签发直接卡死(最致命)。Vercel 给你的域名自动签发证书前,要验证「这个域名的流量确实到我这里」。橙云开着,验证请求被 Cloudflare 拦截,永远到不了 Vercel → 证书签不出来 → 域名状态永远 Invalid
2. 重定向死循环风险。Cloudflare 某些 SSL 模式用 HTTP 回源,Vercel 收到又跳 HTTPS,浏览器最终报 TOO_MANY_REDIRECTS
3. 双层缓存。你更新了文章,Vercel 刷新了,Cloudflare 还存着旧版,排查噩梦

一句话:托管在 Vercel/Netlify 这类平台上时,Cloudflare 的正确角色是纯注册商 + 纯电话簿。 那条黄色横幅,自信地无视它。

坑 4:配好了却打不开?可能是「负缓存」#

DNS 记录保存后,我用 dig 查已经解析成功,但浏览器(和 curl)还是报「无法解析主机」。这不是配错了——是我这台电脑在几分钟前查询过这个域名,当时它还不存在,于是系统把**「查无此名」这个答案也缓存了下来**(negative caching)。

处理方式:等几分钟自然过期,或者换无痕窗口/另一台设备验证。判断标准很简单:dig 能解析 = 配置已生效,剩下的只是各级缓存在陆续过期。