GitHub 重构了 GitHub Copilot 应用中的拉取请求查看界面，以处理一种极端情况：一个包含 2,200 个文件、超过一百万行变更以及 400 多条内嵌审查评论的拉取请求。目标不仅是加快大型差异的显示，还要在对话本身为文档增加可变尺寸后，保持滚动和审查的可用性。
传统的大型差异界面依赖虚拟化加载，即只保留靠近视口的可见元素，并在滚动过程中复用 DOM 元素。当每个元素都是高度已知的代码行时，这种模型相对容易奏效。但评论不具备这一特性；其高度会随着 Markdown 换行、<details> 区块展开、回复编辑器出现、图片、建议更改以及不同交互状态而变化。
两种几何结构，而不是单一高度表
GitHub 为代码行保留了固定几何结构，使用预先计算的位置和高度，并且不会在评论发生变化时重建这些结构。另一方面，它将评论、回复编辑器和动态区块放入独立索引中。每个区块都有一个与文件、行和侧面关联的稳定键，以及内容指纹、区块展开状态和最近一次测量宽度。
当测量有效时使用测得的高度；当指纹和宽度仍然匹配时使用缓存值；否则界面使用临时估算值。这样，单条评论的扩展不会导致数百万行的几何结构重新计算。
在滚动路径之外进行测量
GitHub 放弃了一种初始设计：为每个区块单独使用 ResizeObserver，并直接将测量结果写入布局。这种模式可能产生反馈回路，因为布局变化会再次触发监测；同时，随着复合区块数量增加，其成本也会升高。
公司最终采用的设计使用一个与空闲时段以及滚动结束后相关联的统一测量周期。通常只测量位于视口约 2,400 像素范围内的区块，而远处区块继续使用估算值，直到它们接近视口。可见元素的测量结果会一次性读取，以避免反复触发重排。
监测器仍然用于检测图片加载或回复编辑器中输入等变化，但它们会标记区块，以便下一次测量周期重新读取，而不是直接修改高度。例外情况是可见区块中的用户触发变化，例如展开区块或回复编辑器；此时可以在同一帧中应用一次同步校正，从而避免评论扩展与其下方代码移动之间出现可见跳步。
校正布局而不丢失阅读位置
当实际高度与估算值不同时，界面不会仅根据像素数量校正位置。它会保存用户正在阅读的元素标识，无论该元素是代码行还是评论区块，并确定其内部偏移量，然后应用高度差异，重新计算同一元素的位置。这样，被固定的元素大致能够保持在原来的位置。
通常不会在用户滚动或惯性滚动期间进行校正，也不会使用由屏幕下方内容产生的调整来移动视图。团队曾遇到一个错误：由面板宽度变化引起的编程滚动被误判为用户滚动，导致校正丢失，并使正在阅读的文件逐渐偏移。该问题通过区分用户交互和界面自身引起的变化得到解决。
数据流与自动化测试
响应速度并不只依赖虚拟化显示。差异结构和文件数据会首先发送，使文件树和元数据能够在文档其余部分加载期间显示；而语法高亮和详细 Markdown 构建等工作则推迟到元素接近视口时进行。界面还会临时保留最近使用的少量差异，并清除超出范围的内容，以降低内存消耗。
为了发现只有在深度滚动时才会出现的缺陷，GitHub 增加了持续的测量信号和自动化测试，用于监测行数和复合区块数量、帧耗时、滚动校正幅度、监测器泄漏以及是否存在未填充的空白区域。团队在桌面应用和实际渲染引擎中运行自动化流程，覆盖展开区块、启动回复编辑器、调整窗口大小以及在大型文件列表中导航等情况。
为什么这一设计很重要？
公布的结果是，一个包含一百万行和数百条评论的拉取请求，其表现可以像普通拉取请求一样：评论会完整显示，而不是被截断在嵌套滚动条中；展开区块会使其下方代码移动，而不会随机跳动；返回拉取请求时也可以保留阅读位置。最重要的工程价值在于，GitHub 没有试图让所有内容都具有同一种性质；相反，它保留了确定性部分的速度，并将其与无法在显示前确定尺寸的内容分离。
不过，本文并未声称所有大型拉取请求在理解或风险管理方面都变得容易审查。它解决的是显示界面的性能，以及界面在测量和变化过程中的行为。此外，这些结果与 GitHub Copilot 应用及其内部设计相关，并未提供关于内存消耗的独立数据，也未提供跨不同设备和渲染引擎的性能指标。