出海内容站建站框架横评 2026：Astro 5 凭什么把 Lighthouse 干到 100
Astro 5 / Next.js 15 / SvelteKit 2 / Hugo / Eleventy 5 个候选，6 维度对照 + chdh.me 自己迁移的实测数据
出海内容站选 Astro、Next.js 还是 SvelteKit？chdh.me 把自己从 Next.js 15 迁到 Astro 5，Lighthouse 69→100、TBT 800ms→0ms、bundle -72%、HTML -43%。本文用真实迁移数据 + 6 维度横评告诉你不同场景该选哪个框架。
TL;DR · 一句话结论
chdh.me 用了一天把自己从 Next.js 15 迁到 Astro 5，Lighthouse 性能从 69 飙到 100，TBT 从 800ms 干到 0ms。 这不是 Astro 的营销话术，是我们自己跑 PageSpeed Insights 截图实测的数字。
如果你做的是内容驱动型出海站（工具导航、SEO 内容站、博客、官网、Landing Page），结论极其简单：
| 场景 | 推荐 | 理由 |
|---|---|---|
| 工具评测站 / 内容站 / 博客 | Astro 5 | Islands Architecture 让首页 client JS 接近零 |
| DTC 电商前台（含购物车 / 用户态） | Next.js 15 + Shopify Hydrogen | RSC + Server Actions 处理动态交互 |
| SaaS 营销站 + Dashboard | Next.js 15 | 营销页用 RSC SSG + Dashboard 用 client component |
| 极简博客（1 个人维护） | Hugo 或 Eleventy | 零运行时、最小依赖、最长寿命 |
| 追求 Svelte 语法美学 | SvelteKit 2 | 性能与 Astro 接近，生态薄一截 |
下面是 6 维度横评数据 + 实测对照 + 选型决策树。
---
这一节为什么写：建站框架决定了内容站的 SEO 天花板
出海内容站这门生意，90% 流量来自搜索引擎自然搜索。这意味着：
1. Google Core Web Vitals 是排名信号 —— LCP / CLS / INP 直接进 Google 算法 2. 首屏渲染速度决定跳出率 —— 慢 1 秒，移动端跳出率涨 32%（Google 自家数据） 3. HTML 体积影响爬虫预算 —— 大型站点动辄上万 URL，Googlebot 抓取时长有限
但内容站对前端交互复杂度的需求很低 —— 不需要购物车、用户态、复杂表单、实时数据。理论上生成纯 HTML + 极少 JS 就够了。
矛盾点：过去 5 年 React 生态（Next.js 为代表）的设计目标是满足复杂应用，把整套 React runtime（约 45-60 KB gzip）打进首屏 client bundle。对内容站来说这是过度工程。
2024 年起 Islands Architecture（孤岛架构）兴起 —— Astro / Qwik / Fresh 都基于这个理念：默认 0 client JS，只有标记为 "island" 的组件才送 JS。这对内容站是质变性的优化。
chdh.me 编辑部 2026 年 5 月把自己从 Next.js 15 迁到 Astro 5，Lighthouse 桌面性能从 69 直接打到 100。下面把这次迁移的真实数据 + 5 个候选框架的实测横评一起讲清楚。
---
5 个候选框架 + 6 维度横评矩阵
入选标准：
- 支持纯静态导出（不需要 Node runtime 也能跑）
- 截至 2026-05 仍在活跃维护
- 至少有 1 个出海内容站典型案例可查
- 中文社区有可参考文档
入选名单：
1. Astro 5（2024-11 发布 5.x，2026 已迭代到 5.16）—— Islands Architecture 标杆 2. Next.js 15（React 19 + Server Components）—— 全球最流行的 React 元框架 3. SvelteKit 2（2024 发布）—— Svelte 5 runes 加持 4. Hugo（Go 写的静态生成器，10+ 年历史）—— 最快的纯静态生成器 5. Eleventy 3（11ty）—— JavaScript 写的极简静态生成器
横评维度：
维度 1：性能（Lighthouse 移动端典型分数）
| 框架 | 性能 | LCP | TBT | 备注 |
|---|---|---|---|---|
| Astro 5 | 99-100 | < 1.0s | 0ms | Islands 让 client JS 趋零 |
| Hugo | 99-100 | < 0.8s | 0ms | 纯 HTML 输出 |
| Eleventy 3 | 99-100 | < 0.8s | 0ms | 同 Hugo |
| SvelteKit 2 | 95-100 | < 1.2s | 50-150ms | Svelte 编译体积小 |
| Next.js 15 静态导出 | 65-85 | < 1.2s | 200-1000ms | React runtime + hydration 拖累 |
注：以上是同样内容（首页 + 110 个工具 tile）在 5 个框架下的典型分数区间，基于真实部署测试 + 公开 case study 综合。
维度 2：SEO 友好度
| 框架 | SSR/SSG | URL 结构控制 | Meta 灵活度 | Schema.org 支持 |
|---|---|---|---|---|
| Astro 5 | ✅ SSG | trailingSlash 可配 | ✅ 灵活 | ✅ 原生 `<script type=ld+json>` |
| Next.js 15 | ✅ SSG/SSR | trailingSlash 可配 | ✅ Metadata API | ✅ 通过 Next/script |
| SvelteKit 2 | ✅ SSG | 类似 | ✅ +page.ts | ✅ |
| Hugo | ✅ 纯 SSG | 类似 | ✅ Front matter | ✅ |
| Eleventy 3 | ✅ 纯 SSG | 类似 | ✅ Data cascade | ✅ |
5 家在 SEO 控制力上都达标。差异在于默认输出 HTML 干净度： - Astro / Hugo / Eleventy：输出极简 HTML，无任何运行时框架痕迹 - Next.js：HTML 中含 `__NEXT_DATA__` JSON（React hydration 用），约 50-200KB 冗余 - SvelteKit：含 `__SVELTEKIT_DATA__` 类似冗余，比 Next.js 小
维度 3：开发效率 + 学习曲线
| 框架 | 上手成本 | 生态 | TypeScript 支持 |
|---|---|---|---|
| Astro 5 | 中（学新 `.astro` 语法 + Islands 心智模型） | 中（生态年轻但成熟度快速提升） | 极佳 |
| Next.js 15 | 中（React 19 RSC + Server Actions 复杂） | 全球最大 | 极佳 |
| SvelteKit 2 | 中（Svelte 5 runes 改了响应式语法） | 较薄 | 极佳 |
| Hugo | 高（Go template 语法反直觉） | 中（主题市场成熟） | ❌（不写 Go） |
| Eleventy 3 | 低（纯 JS / Markdown 友好） | 较薄 | 一般 |
关键点： - Astro 支持 React / Vue / Svelte / Solid 共存，可以把任何 React 组件直接当 Astro 的 island 用，迁移成本极低（chdh.me 迁移时复用了 90% 的 React 组件） - Next.js 15 的 RSC + Client Components 心智模型对新人不友好（要懂 "use client" / "use server" / Streaming 等） - Hugo 的 Go template（`{{ range }}` / `{{ partial }}`）对前端开发者反直觉 - Eleventy 适合只写 Markdown + 偶尔加点 JS 的场景
维度 4：构建速度 + Bundle 体积
实测 chdh.me 数据（4,065 个静态路由）：
| 框架 | Build 时间 | dist 总大小 | 首页 First Load JS |
|---|---|---|---|
| Astro 5 | 107s | 365 MB | 3 KB（仅 Workspace island） |
| Next.js 15 | 222s（3.7 min） | 1.3 GB | 128 KB |
| Hugo（理论） | ~30s | ~300 MB | 0 KB |
| Eleventy（理论） | ~60s | ~300 MB | 0 KB |
| SvelteKit 2（理论） | ~150s | ~400 MB | 30-40 KB |
Next.js 比 Astro 多 3.5 倍 dist 大小是因为： 1. `_next/data/*.json` 每个页面一份（4,065 个） 2. React 服务端渲染产物 + client bundle 重复 3. ISR / 增量再生成相关元数据
维度 5：维护 + 长期可演进
| 框架 | 当前主版本 | 历史破坏性升级 | 中文社区 |
|---|---|---|---|
| Astro 5 | 5.x（2024-11） | 4→5 较平滑 | 中（增长快） |
| Next.js 15 | 15.x（2024-10） | App Router 引入是重大破坏 | 极大 |
| SvelteKit 2 | 2.x（2024-02） | Svelte 4→5 runes 是大改 | 小 |
| Hugo | v0.135（2026-05） | 缓慢渐进 | 中 |
| Eleventy 3 | 3.x（2024） | 平滑 | 小 |
Next.js 历史上有 3 次重大破坏性升级（Pages Router → App Router、SWC 替换 Babel、React Server Components 引入）。SvelteKit 跟随 Svelte 5 runes 也算一次重大语法变化。
Astro 5 的优势：版本迭代相对克制，对静态导出场景几乎无破坏性。
维度 6：部署兼容性
| 框架 | 部署到 | 自建 VPS + nginx | Cloudflare Pages | Vercel | Netlify |
|---|---|---|---|---|---|
| Astro 5 | static / Node / SSR | ✅ | ✅ | ✅ | ✅ |
| Next.js 15 | 静态导出 / Vercel / Node | ✅ 但限制多 | ⚠️ ISR 等高级特性不支持 | ✅ 最佳 | ✅ |
| SvelteKit 2 | Adapter 制 | ✅ | ✅ | ✅ | ✅ |
| Hugo | 纯静态 | ✅ | ✅ | ✅ | ✅ |
| Eleventy 3 | 纯静态 | ✅ | ✅ | ✅ | ✅ |
Next.js 静态导出有不少限制（不支持 ISR、不支持 Image Optimization、Route Handlers 必须 force-static），如果未来要加动态特性会受限。
---
实测案例：chdh.me 用 1 天从 Next.js 15 迁到 Astro 5
这一节是本文最有价值的部分 —— 不是理论数据，是 chdh.me 编辑部自己 2026-05-25 当天完成的迁移。
迁移前后 Lighthouse 实测
| 指标 | 阈值 | Next.js 15 | Astro 5 | 变化 |
|---|---|---|---|---|
| 性能 | 桌面 ≥ 90 | 69 | 100 | +31 |
| FCP | < 1.0s | 0.5s | 0.4s | -0.1s |
| LCP | < 1.2s | 0.8s | 0.7s | -0.1s |
| TBT | < 200ms | 800ms | 0ms | -800ms |
| CLS | < 0.1 | 0.045 | 0.001 | -0.044 |
| Speed Index | < 1.3s | 1.8s | 0.4s | -1.4s |
| SEO | 100 | 100 | 100 | 持平 |
| Accessibility | ≥ 95 | 97 | 97 | 持平 |
| Best Practices | 100 | 81 | 100（桌面） | +19 |
TBT 800ms → 0ms 是质变。这意味着用户点击 / 输入的响应延迟从"明显卡顿"变成"零延迟"。Google INP 指标（替代旧 FID）现在直接进 Core Web Vitals 排名信号，TBT 0ms 意味着 INP 也会优秀。
实测：迁移工程量
| 类别 | 工作量 |
|---|---|
| 数据层（types / lib / data）复用 | 0 改动（100% 直接复制） |
| React 组件复用（含工位拖拽逻辑） | 90% 直接复用（只需把 `next/link` 用 vite alias shim 到原生 `<a>`） |
| 页面模板（17 个 page.tsx → 17 个 .astro） | 1 day（用 Agent 批量协助） |
| OG 图迁移（2,212 个工具 OG + 站点级 OG） | 2 小时（`next/og` → `@vercel/og`，API 几乎一样） |
| SEO 端点（sitemap / robots / rss / search-index） | 1 小时（改文件位置 + Response 写法） |
| nginx 配置调整（dist/ 替代 out/） | 5 分钟 |
| 部署脚本调整 + 灰度切换 | 30 分钟 |
| 总计 | ~1 个工作日 |
迁移期间 chdh.me 用了双源部署 + symlink 切换策略，零停机，老 Next.js 版本随时可回滚。
实测：Bundle 体积变化
| 指标 | Next.js 15 | Astro 5 |
|---|---|---|
| First Load JS（首页） | 128 KB | 3 KB |
| 首页 HTML | 377 KB | 215 KB |
| dist 总大小 | 1.3 GB | 365 MB |
| Build 时间 | 3.7 min | 107s |
| 静态页路由数 | 4,065 | 4,065 |
First Load JS 从 128 KB 降到 3 KB = 节约 97.7% 客户端 JS。
这是 Islands Architecture 的核心红利：除了交互必需的 1 个 island（chdh.me 的"我的工位"模块用 React 写），其他全部页面 client JS = 0。
实测：迁移踩过的 3 个坑
1. trailingSlash 必须显式配 `'always'` + `build.format: 'directory'`，否则 Astro 默认生成 `/about.html` 而不是 `/about/index.html`，造成 4,065 个 URL 全部 404。
2. OG 图 URL 后缀变了：Next.js 用 `/tools/.../opengraph-image`（无扩展名），Astro 静态导出必须 `.png` 后缀。Twitter / Facebook 缓存中的旧 OG URL 短期内显示失败（1-2 周自动更新），无 SEO 影响。
3. nginx `add_header` 继承陷阱：迁移后发现 7 个安全 header（HSTS / CSP / X-Frame-Options 等）全消失。原因不是 Astro，是 nginx 配置中 location 内有任何 `add_header` 会让 server-level `add_header` 全部失效。修复方案：用 `include snippets/security.conf;` 在每个 location 内复用。
---
逐家深度评测
1. Astro 5 —— 内容站 + Islands 的最优解
核心优势： - 默认 0 client JS，按需挂载 island - React / Vue / Svelte / Solid 共存，迁移成本极低 - trailingSlash + format: directory 完美支持 SEO 友好 URL - Content Collections 原生支持 Markdown / MDX 内容管理 - @vercel/og 兼容 next/og 的 ImageResponse API，OG 图迁移零成本
核心劣势： - 中文社区相对薄（增长很快但不如 Vue / Next.js） - 对复杂客户端交互（拖拽 / 实时数据 / 全局状态管理）不如 React/Vue 生态成熟 - Astro 自己的 `.astro` 语法学习曲线（但只是模板层，业务逻辑用 React/Vue/Svelte）
适合谁： - 工具评测站 / 博客 / 文档站 / 营销站 / Landing Page - 已用 React 组件想保留但减少 client JS 开销 - 追求 Lighthouse 满分 + SEO 极致优化
不适合谁： - DTC 电商前台需要复杂购物车 / 用户态 - SaaS 产品的 Dashboard 部分（大量动态交互） - 团队全部 Vue 开发者且不愿学新语法
2. Next.js 15 —— 复杂应用的事实标准
核心优势： - React Server Components + Server Actions 是当前最成熟的全栈方案 - Vercel 部署体验业内最佳 - 中文社区最大，遇到问题搜得到答案 - next/image 自动 WebP / AVIF + 响应式 - 生态最丰富（Auth / ORM / 国际化等都有官方推荐）
核心劣势： - 静态导出场景性能天然吃亏（React runtime + hydration 必交税） - App Router 心智模型复杂（RSC / Client / Streaming / Suspense） - 升级破坏性大（Pages Router → App Router 是事实上的重写） - 自建 VPS 部署需要绕开很多 Vercel-specific 特性
适合谁： - DTC 电商前台 + 用户态 + 购物车 - SaaS Dashboard + 营销站 + 文档站合一 - 团队已有 React 资深开发者 - 需要 ISR / Edge Runtime / Middleware 等高级特性
不适合谁： - 纯静态内容站（杀鸡用牛刀） - 追求 Lighthouse 满分的内容驱动型站点 - 不能上 Vercel 又想要 ISR 的场景
3. SvelteKit 2 —— 性能优秀但生态短板
核心优势： - Svelte 编译为极小运行时（gzip ~10 KB） - Svelte 5 runes 让响应式语法接近 React Signals - 性能接近 Astro，比 Next.js 强
核心劣势： - 生态比 React/Vue 薄一个量级 - Svelte 5 runes 改了响应式语法，老代码迁移有成本 - 中文社区小，问题搜索体验差 - 不支持 Astro 那样的"多框架 island 共存"
适合谁： - 团队认同 Svelte 哲学且能接受生态短板 - 性能优先 + 不需要丰富 UI 组件库
不适合谁： - 想用现成 React 组件（如 shadcn/ui）的团队 - 中文社区依赖度高的团队
4. Hugo —— 最快但模板反人类
核心优势： - Go 写的，构建速度业内最快（1 万页 < 10s） - 零运行时依赖（一个二进制就跑） - 主题市场成熟 - 10+ 年历史，最稳定
核心劣势： - Go template 语法对前端开发者极不友好（`{{ range $.Pages }}` 这种） - 不支持 JSX / 现代组件化思想 - 数据层管理用 TOML / YAML 较僵硬 - 客户端交互全靠你自己写 Vanilla JS
适合谁： - 1 个人维护的极简博客 / 文档站 - 内容 100% Markdown 没有复杂逻辑 - 接受 Go template 心智模型
不适合谁： - 团队有前端开发者且想用 React/Vue - 需要任何客户端交互（搜索框 / 评论 / 暗色模式切换等）
5. Eleventy 3 —— 极简但功能少
核心优势： - 纯 JavaScript，前端开发者友好 - 数据层灵活（JSON / JS / Markdown 任意组合） - 模板可选（Nunjucks / EJS / Markdown / Liquid 多种）
核心劣势： - 没有原生组件化（不能像 Astro 那样写 `.astro` 组件） - 客户端 JS 需要自己接 esbuild / Vite - 生态薄 - 中文社区几乎为零
适合谁： - 极简静态博客 / 文档站 - 想全 JS 但不想 Astro 那么"重"
不适合谁： - 复杂内容站（多种数据源 + 多种页面模板） - 需要现代组件化心智
---
3 个典型出海站场景的选型决策
场景 A：工具评测站 / 内容站 / 博客（chdh.me 同款）
推荐：Astro 5 ✅
理由： - 内容驱动，对 client JS 要求极低 - SEO 关键，需要 Lighthouse 满分 - 大量动态路由（每个工具 / 文章一个页面）+ Build 时间敏感
如果坚持用 Next.js 15，需要做额外优化（lazy load / RSC / 自定义 Webpack 配置），收益有限。
场景 B：DTC 独立站前台
推荐：Shopify + Hydrogen（Remix-based） 或 Next.js 15
理由： - 购物车 / 结算 / 用户态需要复杂客户端交互 - 库存 / 价格实时数据 - 客户经常需要 SPA 流畅切换
Astro 不适合：它的 Islands 模型针对的是"少量交互"，DTC 前台是"大量交互"。
场景 C：SaaS 营销站 + Dashboard
推荐：Next.js 15
理由： - 营销页可以 SSG 优化性能 - Dashboard 用 Client Component + Server Actions - 同一个 codebase 同一个框架
如果营销站和 Dashboard 完全分离，可以营销站用 Astro + Dashboard 用 Next.js（但运维 + 团队学习成本高）。
---
选型决策树
``` 你的站点主要是？ ├─ 内容驱动（90% 静态文章 / 工具评测 / 文档） │ ├─ 团队懂 React/Vue → Astro 5 │ ├─ 1 个人极简博客 → Hugo 或 Eleventy 3 │ └─ 追求 Svelte 美学 → SvelteKit 2 │ ├─ 应用驱动（购物车 / 用户态 / Dashboard） │ ├─ 复杂全栈 → Next.js 15 │ ├─ 电商前台 → Shopify Hydrogen 或 Next.js │ └─ 不要 React → SvelteKit 2 │ └─ 混合（营销站 + 应用） ├─ 同 codebase → Next.js 15 └─ 分开维护 → 营销站 Astro + 应用 Next.js ```
---
注意事项 + 8 个迁移踩坑
如果你打算从 Next.js 迁到 Astro（chdh.me 同款路径），下面这些坑提前知道能省 1-2 天：
1. trailingSlash 必须显式配置：默认 `'ignore'` 会让 `/about` 和 `/about/` 都返回内容但 URL 不统一，造成 canonical 混乱。设 `'always'` + `build.format: 'directory'`。
2. next/link 用 vite alias shim：写一个 5 行 shim 把 `next/link` 映射到原生 `<a>`，所有 React 组件不用改。
3. `next/og` → `@vercel/og`：API 几乎一样（都是 ImageResponse + JSX）。如果 OG 图用了 React JSX 语法，要在 Astro 里改成 `React.createElement(...)` 形式（因为 Astro endpoint 是 TS 而不是 TSX）。
4. Schema.org JSON-LD：Astro 不像 Next.js 有 `<Script>` 组件，直接 `<script type="application/ld+json" set:html={JSON.stringify(data)} />` 即可。
5. Compare / Tool 等大量 dynamic routes：用 `getStaticPaths()` 替代 Next.js `generateStaticParams()`，返回 `[{ params, props }]` 结构。
6. Astro 默认所有 .tsx 组件是 server-rendered，不需要 `'use client'`。要让组件 client hydrate，在使用处加 `client:load` / `client:idle` / `client:visible` directive。
7. Lib 文件 client/server 分离仍然必要：如果一个 lib 文件 import 了大量数据（如 chdh.me 的 allTools 2,200+ 条），而 client island 又 import 了这个 lib，bundle 会爆。规则同 Next.js：写 client-safe lib 和 server-only lib 两份。
8. nginx add_header 继承陷阱：location 内任何 `add_header` 让 server-level 全部失效。把安全 headers 放进 nginx snippet，每个 location 内 `include`。
---
6 维度横评打分表（最终版）
满分 5，越高越好。
| 维度（权重） | Astro 5 | Next.js 15 | SvelteKit 2 | Hugo | Eleventy 3 |
|---|---|---|---|---|---|
| 性能（25%） | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| SEO 友好度（20%） | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 开发效率（15%） | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
| 生态成熟度（15%） | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |
| 中文社区（10%） | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| 长期可演进（15%） | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 加权总分 | 4.30 | 4.05 | 3.70 | 3.85 | 3.80 |
按出海内容站场景加权下来：Astro 5 排第一，Next.js 15 第二，SvelteKit 2 / Hugo / Eleventy 平手第三梯队。
但如果你的站点不是纯内容站（含购物车 / Dashboard），Next.js 会反超 —— 它的生态优势在复杂场景才能兑现。
---
编辑结论
2026 年做出海内容站，默认选 Astro 5。 这不是因为它"新"或"潮"，是因为它的 Islands Architecture 直接消除了 React/Vue 时代的客户端 JS 税。
chdh.me 自己用 1 个工作日完成迁移，性能从 Lighthouse 69 干到 100，TBT 从 800ms 干到 0ms —— 这种"零代码改动 React 业务逻辑就能拿到性能巨幅提升"的事情，技术圈里不多见。
如果你已经在 Next.js 上跑得舒服，且没有 Lighthouse 跑分焦虑，不用强迫迁移。Next.js 15 + RSC + Server Actions 是一套自洽的方案。
但如果你的站点是纯内容驱动 + Lighthouse 满分焦虑 + 想留 React 组件，Astro 5 是 2026 年最优解。
---
5 个常见问题
Q1：Astro 适合做后台 / Dashboard 吗？
不太适合。Astro 的 Islands 架构是为"少量交互、大量静态内容"设计的。Dashboard 通常是反过来 —— 大量动态数据、复杂状态管理、实时更新。这种场景用 Next.js（React Server Components + Client Components）或者干脆 SPA（React + Vite + TanStack Router）更合适。如果你的应用是 90% 静态营销 + 10% 后台，可以把营销站独立用 Astro，后台独立用 Next.js / Vite。
Q2：从 Next.js 迁到 Astro，已经写的 React 组件能复用吗？
绝大部分能直接复用。chdh.me 迁移时 90% 的 React 组件没改任何代码。关键技巧：
1. 用 vite alias 把 `next/link` shim 到一个 5 行的原生 `<a>` 包装； 2. `next/image` 改成原生 `<img>`（chdh.me 本来就没用 next/image）； 3. 用了 `next/navigation` 的 `useSearchParams` / `useRouter` 改成原生 `window.location` 和 `window.history` API。
Server-rendered React component（不带 'use client'）在 Astro 中默认 SSR 出 HTML 后不送 client JS，等同于 Astro 的 .astro 模板。Client component 在使用处加 `client:load` / `client:idle` 等 directive 就能 hydrate。
Q3：Astro 的 Lighthouse 100 是不是只在桌面端拿到？移动端怎么样？
桌面 100 大多数内容站都能做到。移动端因为 4× CPU 减速模拟，95-100 都正常。chdh.me 的实测桌面 100、移动端预估 95-99（取决于 client island 数量）。如果只追求"主流绿区"（≥ 90），Astro 是最稳的选择。如果非要拼移动端 100，可以进一步用 `client:visible` 替代 `client:load`、把首屏 Critical CSS inline 等极致优化，但边际收益有限。
Q4：纯静态站为什么还需要 OG 图动态生成？直接放静态图不行吗？
可以放静态图，但你会失去每个页面独立 OG 图的 SEO 收益。OG 图是用户在社交媒体（Twitter / Facebook / 微信 / LinkedIn）分享链接时看到的预览图。每个工具 / 文章 / 评测有自己的标题、品牌、关键参数渲染成 OG 图，分享时的点击率会显著提升。chdh.me 用 `@vercel/og`（Astro 兼容）+ Satori 引擎，build 时自动给 2,200+ 工具页生成 OG 图，每张 1200×630 PNG，30-100 KB。
Q5：自建 VPS 用 nginx，迁框架后部署脚本要改多少？
很少。chdh.me 的 `scripts/deploy.sh` 只改了 3 处：build 产物目录 `out/` → `dist/`、文件计数命令、rsync 源路径。其他逻辑（双源同步 / 原子 symlink 切换 / CF 缓存清除 / IndexNow 推送 / Bing / 百度推送）100% 不变。nginx 配置不动（指向 `/var/www/chdh` symlink）。整个 deploy.sh 只有 5 行 sed 替换就跑通了。
