长文压力测试：静态博客从 0 到 1 的长期运营手册

这是一篇专门用于测试你当前博客系统的长文样例。它的目标不是“写得多文艺”，而是覆盖真实运营中的关键写作场景：

1. 多级标题和超长滚动。
2. 表格、代码、数学公式、图表。
3. 章节切换时目录树高亮的稳定性。

01. 设计目标与边界

你要的博客不是“会跑就行”，而是长期可运营、可迁移、可扩展。这个目标会直接决定技术方案：

• 内容要以 Markdown 为唯一源。
• 输出要是纯静态 HTML。
• 运行时脚本要最少。
• 架构要允许未来迁移到 VPS 直接 git pull + build。

01.1 为什么不是先做复杂后台

很多博客项目失败的原因不是技术太弱，而是前期架构过重。过早引入 CMS、数据库、复杂鉴权，会让维护成本迅速上升。

01.2 长期运营最怕什么

最怕“内容和平台绑定”。当内容跟服务端耦合太深，你迁移一次就要重写一次。

01.3 正确的核心假设

正确假设是：内容生命周期大于平台生命周期。你换服务器、换 CDN、换构建工具，都不应该影响文章本体。

02. 信息架构（IA）

建议把内容分为三层：

• 页面层：首页、归档、标签页、关于页。
• 内容层：文章正文与 metadata。
• 分发层：sitemap、rss、结构化数据。

02.1 URL 约束

URL 一旦发布，不要随意改。推荐格式：

• /posts/{slug}/
• /tags/{tag}/

02.2 Slug 命名建议

• 英文小写 + 连字符。
• 避免中文 slug（可读性高但跨系统处理不稳定）。
• 一旦上线不要改。

02.3 标签体系建议

标签数量不要暴涨。建议控制在 20-40 个稳定主题，避免“每篇都发明新标签”。

03. 性能模型

前端体感延迟可以拆成：

$$T_{user} \approx T_{network} + T_{html} + T_{paint} + T_{js}$$

静态站的优势在于把 T_js 压到很低，让首屏几乎只看网络和 HTML。

03.1 首屏资源预算

可先定一个现实目标：

• 首屏 CSS < 70KB（gzip）
• 首屏 JS < 80KB（gzip）
• LCP < 2.0s（4G 模拟）

03.2 图片策略

• 文章首图用 webp/avif。
• 正文图按列宽导出，不要上传 4K 原图。
• 命名统一：/public/images/posts/{slug}/...

03.3 何时加客户端脚本

只有在交互带来明确价值时再加，比如图表、搜索建议、局部动效。

04. Markdown 渲染能力基线

你的博客目前要求支持：表格、代码、公式、图表。下面逐项压测。

04.1 表格渲染

维度	目标	备注
可读性	高	行高与列宽要舒适
移动端	可横向滚动	不要硬挤压
语义化	保持 table 结构	方便 SEO 和可访问性

04.2 代码块渲染

interface PostMeta {
  title: string;
  slug: string;
  date: string;
  tags: string[];
  draft?: boolean;
}

export function toRoute(meta: PostMeta): string {
  return `/posts/${meta.slug}/`;
}

04.3 数学公式渲染

行内公式示例：$E = mc^2$。

块级公式示例：

$$\text{Score}_{seo} = 0.4 \cdot C + 0.3 \cdot I + 0.3 \cdot U$$

其中：

• $C$ 表示内容质量。
• $I$ 表示索引覆盖。
• $U$ 表示 URL 稳定性。

04.4 ECharts 渲染

05. SEO 基础设施

SEO 不等于堆关键词，核心是“可发现 + 可理解 + 可持续更新”。

05.1 必备技术项

• sitemap.xml
• rss.xml
• canonical
• Open Graph / Twitter Card
• 文章结构化数据（Article）

05.2 内容策略

• 每篇解决一个明确问题。
• 标题不要写成玄学文案。
• 首段给出答案，后文展开。

05.3 主题集群

围绕固定主题写系列文章，比“今天写 A 明天写 Z”更容易积累权重。

06. 多语言策略

你已经决定做全站语言切换，这里建议采用独立内容方案。

06.1 推荐方案

• 每种语言一篇独立 Markdown。
• 通过 translationKey 关联同一篇不同语言。
• 语言切换时跳到对应语言版本。

06.2 为什么不只做前端替换

只替换 UI 文案无法覆盖正文内容，也不利于搜索引擎按语种索引。

06.3 缺失翻译的回退

如果某篇缺少目标语言版本：

• 回退默认语种，并提示“该语种暂未提供”。

07. 目录树（TOC）体验要求

TOC 不是装饰，它是长文的导航系统。

07.1 高亮规则

• 随滚动位置变化。
• 点击目录项后应立即高亮该项。
• 页面缩放后高亮仍正确。

07.2 桌面与移动

• 桌面端右侧 sticky 目录。
• 移动端折叠目录，避免挤压正文宽度。

07.3 视觉节奏

目录应弱化，但 active 章节要明确，避免“高亮存在感过强”。

08. 内容生产工作流

建议把写作流程标准化，这样你不会被工具绑架。

08.1 写作流程

1. 先列 5-8 个小标题。
2. 每段只解决一个点。
3. 写完再统一补图、补链接。

08.2 与 AI 协作

• 你提供结构和观点。
• AI 负责扩写和润色。
• 最终由你审核事实与语气。

08.3 发布前检查清单

• 标题和描述长度是否合理。
• 目录层级是否干净。
• 代码和图表是否可读。
• 移动端是否可浏览。

09. 可维护性与迁移

09.1 为什么静态站易迁移

内容和发布平台天然解耦。构建产物是普通文件，任何 Web 服务器都能托管。

09.2 Cloudflare 到 VPS 的迁移

步骤极简：

1. git pull
2. npm ci
3. npm run build
4. 将 dist/ 挂到 Nginx

09.3 最小运维面

• 减少运行时服务。
• 减少在线依赖。
• 把复杂性放在构建期。

10. 结语

如果你只追求“看起来很强”，项目会越来越重；如果你坚持“可长期运营”，项目会越来越稳。

这篇长文就是给你测目录树和渲染链路用的。你可以直接滚动整篇，重点验证：

• TOC 高亮是否稳定。
• ECharts 是否真实渲染。
• 表格和公式在移动端是否可读。

当这些基础能力稳定后，再继续打磨你首页的粒子漏斗动效，才是正确顺序。