内容回归测试笔记

内容改动不是低风险改动，它只是更容易让人放松警惕。

内容回归经常被低估。很多人觉得“只是改几篇文章”，但 MDX 文章会参与构建，会影响列表排序，会生成目录锚点，也可能因为一个标签或代码块把页面撑爆。

我现在把内容改动分成两类：数据变更 和 排版变更。前者看 frontmatter，后者看详情页渲染。

先检查数据层

每篇文章最先要确认的是 slug、title、excerpt、updatedAt 和 tags。这些字段如果写错，页面还没来得及好看，构建就先炸了。

我会按这个顺序看：

1. slug 是否等于文件名。
2. updatedAt 是否是合法日期。
3. tags 是否是非空字符串数组。
4. 摘要是否能在列表页独立说明文章价值。

比如一篇新文章的 frontmatter 可以先这样对齐：

title: "内容回归测试笔记"
slug: "content-regression-notes"
updatedAt: "2026-06-09T18:35:00.000Z"
tags: ["content", "testing", "workflow"]

排序是最容易漏的地方

列表页通常按 updatedAt 倒序排。新增文章如果日期太旧，验收时找不到；旧文章如果全改成今天，又会把历史顺序冲乱。

再检查页面渲染

排版回归主要看真实页面，不要只看编辑器。浏览器里打开文章详情页，检查标题、段落、列表、链接、代码块和提示块是否都在正确节奏里。

• h2 和 h3 应该出现在目录里。
• 外链比如 Next.js 文档 应该有外链图标。
• 代码块应该在容器内滚动。
• Callout 应该只强调提醒，不要连续堆满屏。

最后跑自动检查

内容改完以后，我会固定跑三条命令：

bun run lint
bunx tsc --noEmit
bun run build

这三步能覆盖大部分低级错误。build 尤其重要，因为 MDX 语法、frontmatter 校验和页面生成都会在这里一起暴露问题。

不要让测试变成表演

测试的目的不是证明“我改完了”，而是证明“读者打开页面时不会遇到烂摊子”。内容站点越小，越要把这套流程固定下来。

回归覆盖表

• 先跑 bun run build。
• 用 Cmd + L 快速切换验收路由。
• 把 未覆盖视口 写进剩余风险，而不是假装全测了。