Safari 长文 MDX 压力测试#

第 1 章：长文渲染基线#

这一节围绕“长文渲染基线”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“长文渲染基线”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 1.2： 快速滚动经过“长文渲染基线”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“长文渲染基线”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“长文渲染基线”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“长文渲染基线”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“长文渲染基线”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“长文渲染基线”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 2 章：原生滚动与惯性#

这一节围绕“原生滚动与惯性”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“原生滚动与惯性”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 2.2： 快速滚动经过“原生滚动与惯性”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“原生滚动与惯性”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“原生滚动与惯性”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“原生滚动与惯性”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“原生滚动与惯性”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“原生滚动与惯性”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 3 章：文本排版与换行#

这一节围绕“文本排版与换行”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“文本排版与换行”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 3.2： 快速滚动经过“文本排版与换行”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“文本排版与换行”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“文本排版与换行”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“文本排版与换行”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“文本排版与换行”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“文本排版与换行”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 4 章：目录观察与锚点#

这一节围绕“目录观察与锚点”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“目录观察与锚点”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 4.2： 快速滚动经过“目录观察与锚点”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“目录观察与锚点”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“目录观察与锚点”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“目录观察与锚点”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“目录观察与锚点”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“目录观察与锚点”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

1
let scheduledFrame: number | null = null;
2
export function scheduleArticleUpdate(update: () => void) {
3
  if (scheduledFrame !== null) return;
4
  scheduledFrame = requestAnimationFrame(() => {
5
    scheduledFrame = null;
6
    update();
7
  });
8
}

第 5 章：代码高亮节点#

这一节围绕“代码高亮节点”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“代码高亮节点”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 5.2： 快速滚动经过“代码高亮节点”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“代码高亮节点”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“代码高亮节点”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“代码高亮节点”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“代码高亮节点”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“代码高亮节点”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 6 章：数学公式排版#

这一节围绕“数学公式排版”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“数学公式排版”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 6.2： 快速滚动经过“数学公式排版”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“数学公式排版”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“数学公式排版”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“数学公式排版”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“数学公式排版”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“数学公式排版”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

行内公式示例：当每帧预算约为 $16.67\,ms$ 时，可将一次更新成本记为 $T = T_{style} + T_{layout} + T_{paint} + T_{script}$。本页不追求公式复杂度，只用于覆盖 KaTeX 节点参与长文滚动的场景。

第 7 章：表格横向布局#

这一节围绕“表格横向布局”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“表格横向布局”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 7.2： 快速滚动经过“表格横向布局”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“表格横向布局”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“表格横向布局”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“表格横向布局”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“表格横向布局”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“表格横向布局”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 8 章：引用与提示块#

这一节围绕“引用与提示块”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“引用与提示块”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 8.2： 快速滚动经过“引用与提示块”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“引用与提示块”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“引用与提示块”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“引用与提示块”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“引用与提示块”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“引用与提示块”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

1
let scheduledFrame: number | null = null;
2
export function scheduleArticleUpdate(update: () => void) {
3
  if (scheduledFrame !== null) return;
4
  scheduledFrame = requestAnimationFrame(() => {
5
    scheduledFrame = null;
6
    update();
7
  });
8
}

第 9 章：列表层级结构#

这一节围绕“列表层级结构”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“列表层级结构”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 9.2： 快速滚动经过“列表层级结构”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“列表层级结构”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“列表层级结构”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“列表层级结构”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“列表层级结构”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“列表层级结构”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 10 章：图片占位与尺寸#

这一节围绕“图片占位与尺寸”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“图片占位与尺寸”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 10.2： 快速滚动经过“图片占位与尺寸”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“图片占位与尺寸”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“图片占位与尺寸”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“图片占位与尺寸”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“图片占位与尺寸”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“图片占位与尺寸”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 11 章：主题切换重绘#

这一节围绕“主题切换重绘”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“主题切换重绘”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 11.2： 快速滚动经过“主题切换重绘”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“主题切换重绘”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“主题切换重绘”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“主题切换重绘”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“主题切换重绘”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“主题切换重绘”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 12 章：路由切换恢复#

这一节围绕“路由切换恢复”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“路由切换恢复”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 12.2： 快速滚动经过“路由切换恢复”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“路由切换恢复”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“路由切换恢复”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“路由切换恢复”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“路由切换恢复”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“路由切换恢复”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

1
let scheduledFrame: number | null = null;
2
export function scheduleArticleUpdate(update: () => void) {
3
  if (scheduledFrame !== null) return;
4
  scheduledFrame = requestAnimationFrame(() => {
5
    scheduledFrame = null;
6
    update();
7
  });
8
}

行内公式示例：当每帧预算约为 $16.67\,ms$ 时，可将一次更新成本记为 $T = T_{style} + T_{layout} + T_{paint} + T_{script}$。本页不追求公式复杂度，只用于覆盖 KaTeX 节点参与长文滚动的场景。

第 13 章：可见区组件水合#

这一节围绕“可见区组件水合”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“可见区组件水合”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 13.2： 快速滚动经过“可见区组件水合”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“可见区组件水合”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“可见区组件水合”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“可见区组件水合”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“可见区组件水合”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“可见区组件水合”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 14 章：主线程任务切分#

这一节围绕“主线程任务切分”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“主线程任务切分”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 14.2： 快速滚动经过“主线程任务切分”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“主线程任务切分”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“主线程任务切分”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“主线程任务切分”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“主线程任务切分”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“主线程任务切分”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 15 章：样式计算范围#

这一节围绕“样式计算范围”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“样式计算范围”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 15.2： 快速滚动经过“样式计算范围”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“样式计算范围”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“样式计算范围”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“样式计算范围”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“样式计算范围”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“样式计算范围”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 16 章：绘制与合成边界#

这一节围绕“绘制与合成边界”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“绘制与合成边界”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 16.2： 快速滚动经过“绘制与合成边界”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“绘制与合成边界”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“绘制与合成边界”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“绘制与合成边界”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“绘制与合成边界”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“绘制与合成边界”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

1
let scheduledFrame: number | null = null;
2
export function scheduleArticleUpdate(update: () => void) {
3
  if (scheduledFrame !== null) return;
4
  scheduledFrame = requestAnimationFrame(() => {
5
    scheduledFrame = null;
6
    update();
7
  });
8
}

第 17 章：内存与设备温度#

这一节围绕“内存与设备温度”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“内存与设备温度”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 17.2： 快速滚动经过“内存与设备温度”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“内存与设备温度”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“内存与设备温度”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“内存与设备温度”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“内存与设备温度”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“内存与设备温度”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 18 章：触摸手势响应#

这一节围绕“触摸手势响应”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“触摸手势响应”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 18.2： 快速滚动经过“触摸手势响应”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“触摸手势响应”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“触摸手势响应”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“触摸手势响应”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“触摸手势响应”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“触摸手势响应”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

行内公式示例：当每帧预算约为 $16.67\,ms$ 时，可将一次更新成本记为 $T = T_{style} + T_{layout} + T_{paint} + T_{script}$。本页不追求公式复杂度，只用于覆盖 KaTeX 节点参与长文滚动的场景。

第 19 章：快速往返滚动#

这一节围绕“快速往返滚动”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“快速往返滚动”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 19.2： 快速滚动经过“快速往返滚动”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“快速往返滚动”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“快速往返滚动”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“快速往返滚动”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“快速往返滚动”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“快速往返滚动”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 20 章：深色模式对比#

这一节围绕“深色模式对比”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“深色模式对比”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 20.2： 快速滚动经过“深色模式对比”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“深色模式对比”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“深色模式对比”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“深色模式对比”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“深色模式对比”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“深色模式对比”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

1
let scheduledFrame: number | null = null;
2
export function scheduleArticleUpdate(update: () => void) {
3
  if (scheduledFrame !== null) return;
4
  scheduledFrame = requestAnimationFrame(() => {
5
    scheduledFrame = null;
6
    update();
7
  });
8
}

第 21 章：窄屏阅读体验#

这一节围绕“窄屏阅读体验”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“窄屏阅读体验”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 21.2： 快速滚动经过“窄屏阅读体验”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“窄屏阅读体验”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“窄屏阅读体验”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“窄屏阅读体验”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“窄屏阅读体验”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“窄屏阅读体验”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 22 章：桌面宽屏目录#

这一节围绕“桌面宽屏目录”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“桌面宽屏目录”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 22.2： 快速滚动经过“桌面宽屏目录”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“桌面宽屏目录”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“桌面宽屏目录”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“桌面宽屏目录”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“桌面宽屏目录”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“桌面宽屏目录”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 23 章：回归记录方法#

这一节围绕“回归记录方法”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“回归记录方法”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 23.2： 快速滚动经过“回归记录方法”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“回归记录方法”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“回归记录方法”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“回归记录方法”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“回归记录方法”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“回归记录方法”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

第 24 章：发布前验收#

这一节围绕“发布前验收”构造连续的中文正文。测试的重点不是阅读结论，而是让浏览器面对真实文章常见的段落长度、标点密度、粗体强调、行内代码和链接节点。滚动时应观察文字是否出现闪烁、重排或短暂模糊，触摸手势是否能立即接管页面，以及停止滑动后设备是否仍持续高负载。若同样内容在其他浏览器流畅而 Safari 明显掉帧，应优先检查全局过渡、滚动容器和同步布局读取，而不是简单删除正文。

长文章的性能往往由许多看似微小的规则叠加而成。一个段落只有几十个节点时，全局 transition 几乎无法被察觉；当代码高亮、公式和组件把节点数量扩展到数千甚至上万时，浏览器需要维护的状态会急剧增加。测试“发布前验收”时，应分别记录首次打开、缓慢阅读、快速甩动、目录跳转和主题切换后的表现，避免只凭一次顺畅滚动就认定问题已经解决。

观察点 24.2： 快速滚动经过“发布前验收”段落时，正文、目录和页面背景应保持稳定，不应出现连续闪烁、跳位或触摸延迟。

本页刻意保留较长句子和多种中文标点，用来模拟教程、课程笔记与技术分析中的真实排版。Safari 对字体栅格化、粘性元素、阴影、透明度和复杂后代选择器的组合较为敏感，因此排查“发布前验收”不能只看 JavaScript 执行时间。还要观察样式重算、布局、绘制与合成各阶段是否持续占用主线程，并确认页面静止后相关活动能够迅速下降。

稳定的修复方案必须保留内容结构和交互能力。为了让基准具有长期价值，本章节不会使用人为缩短文章、隐藏大段内容或关闭目录等规避方式。正确目标是在完整保留标题、段落、列表、表格、代码块和公式的前提下，让“发布前验收”场景依旧能够依赖浏览器原生滚动顺畅工作，并让首屏之外的交互组件延迟到真正进入视口时再水合。

• 检查“发布前验收”相关节点是否被全局动画选择器命中。
• 检查滚动事件是否在同一帧重复读取布局。
• 检查首屏外组件是否遵循可见区水合。
• 检查路由离开后观察器和动画帧是否被释放。

回归测试应尽量使用固定步骤：从页面顶部开始连续向下滚动三次，在中段快速改变方向，通过右侧目录跳转到远处标题，再切换一次明暗主题，最后返回顶部。针对“发布前验收”，记录是否出现目录高亮滞后、锚点定位偏移、滚动动画互相竞争、组件提前激活或控制台 hydration 报错。只有这些路径都通过，才能说明优化没有用功能退化换取表面帧率。

在移动设备上，发热通常是持续计算的外部表现，而不是单独的故障。若“发布前验收”测试中页面已经停止滚动，但温度和能耗仍快速上升，应检查是否存在未取消的 requestAnimationFrame、重复创建的观察器、持续运行的平滑滚动或大量未销毁的客户端实例。组件卸载、Swup 页面切换和前进后退都必须释放旧状态，否则多次访问长文后问题会比第一次打开更严重。

1
let scheduledFrame: number | null = null;
2
export function scheduleArticleUpdate(update: () => void) {
3
  if (scheduledFrame !== null) return;
4
  scheduledFrame = requestAnimationFrame(() => {
5
    scheduledFrame = null;
6
    update();
7
  });
8
}

行内公式示例：当每帧预算约为 $16.67\,ms$ 时，可将一次更新成本记为 $T = T_{style} + T_{layout} + T_{paint} + T_{script}$。本页不追求公式复杂度，只用于覆盖 KaTeX 节点参与长文滚动的场景。

测试结束记录#

完成滚动后，请记录设备型号、Safari 版本、页面打开方式、是否经过 Swup 路由、滚动方向切换次数、主题切换结果和异常截图。若修改性能代码，应保留本页结构并重复相同步骤，以便对比改动前后的主观流畅度与客观性能轨迹。