百万行PR也能顺滑滚动，GitHub靠的不是再加一层虚拟列表
内容提要
GitHub 重建 PR 差异页以应对百万行改动：代码行高度固定，评论高度动态。方案将总高度拆为确定代码高度、动态块有效高度和滚动留白；动态块先估后测，修正时以视口锚点补偿滚动，避免跳动。数据增量流入，并内置探针长期监控挂载行数、测量次数、修正幅度与 Observer 泄漏，用端到端预算验证。核心是把性能优化单位从组件升级为可验证的不变量。
延伸解读
固定高度与动态高度为何要分开处理
文章指出，代码行高度固定，可提前计算前缀和快速定位；评论高度却会因图片、折叠块和回复框变化。若把动态测量值写回同一张总偏移表，下方内容会整体移动，导致滚动跳跃。GitHub将总高度拆为确定代码高度、动态块有效高度和滚动留白，本质是让两类几何互不干扰。这种拆分是后续锚点补偿和增量渲染能成立的前提。
锚点补偿：动态块变高时如何不跳动
当一条评论从80像素变为140像素，若它位于当前视口锚点之前，滚动位置需同步增加60像素，用户看到的代码才不会跳。文章给出的最小示例验证了这一不变量：修正量60，新滚动位置560。真实产品还需处理并发测量、删除、宽度桶和绘制时序，并应在requestAnimationFrame内批量消费测量结果，避免一次变化触发多次同步布局。
稳定键与探针：长期可验证比临时优化更重要
评论键不能使用数组下标，因为插入或重排后旧高度会套到错误节点；可靠键应包含文件、行、左右侧和线程标识，并在内容或展开状态变化时更新高度指纹。同时，文章强调不能依赖临时console.log，而要在生产代码中长期监控挂载行数、每帧测量次数、修正幅度和Observer是否卸载，并用端到端预算验证冷热页面、深度滚动和窗口调整下的健康状态。
适用边界与落地起点
这套方法适合代码Diff、日志查看器、长文批注、时间线和表格加详情面板，不适合内容很少或高度完全固定的页面。文章提醒，能打开百万行PR不等于人应该一次评审百万行，业务拆分仍不可替代。落地时可选最痛的真实页面，固定极端夹具，先埋三个永久信号：挂载节点数、最长帧时间和最大滚动修正，再谈重构。
Q&A
GitHub 的 PR 差异页为什么不能只用虚拟列表来解决百万行滚动卡顿？
因为代码行高度固定，而评论高度是动态的，会随图片、折叠块和回复框变化。如果只用虚拟列表，把动态高度写回总偏移表会导致下方内容移动，用户看到滚动跳跃。GitHub 将总高度拆为确定代码高度、动态块有效高度和滚动留白，动态块先估后测，修正时以视口锚点补偿滚动。
GitHub 如何解决动态评论高度变化导致的滚动跳动？
动态块先用估计值占位，渲染后测量真实高度。修正时以用户正在看的内容为锚点，补偿滚动位置：如果动态块在锚点之前变高，滚动位置同步增加相应差值，避免锚点漂移。宽度也按区间记录，普通窗口抖动不会让所有测量失效。
在浏览器中实现锚点补偿时需要注意哪些工程细节？
应在 requestAnimationFrame 内批量消费测量结果，避免一次评论变化触发多次同步布局。稳定键不能使用数组下标，因为评论插入或线程重排序后下标会变，旧高度会套到错误节点。可靠的键应包含文件、行、左右侧和评论线程标识，并在内容或展开状态变化时更新高度指纹。
GitHub 为什么要在生产代码中内置性能探针？
为了长期监控关键健康信号：当前挂载多少行、每帧提交几次测量、修正幅度多大、Observer 是否卸载、滚动后是否仍插入未知评论。这些信号被写成端到端预算，自动流程打开冷热页面，深度滚动、展开折叠、打开回复框并调整窗口，只有全程无空洞、无空白评论且真实线程挂载，样本才算健康。
这套方法适合哪些场景，不适合哪些场景？
适合代码 Diff、日志查看器、长文批注、时间线和表格加详情面板等高度混合的场景。不适合内容很少或高度完全固定的页面，那时普通分页更简单。它也不能替代业务上的拆分：能打开百万行 PR，不等于人应该一次评审百万行。
文章提出的核心性能优化理念是什么？
前端性能优化的单位应从“组件”升级为“可验证的不变量”。“滚动很顺”无法进 CI，而“锚点位移不超过阈值、视口外节点受控、Observer 零泄漏”才可以。立即可执行的做法是选最痛的真实页面，固定一个极端夹具，先埋三个永久信号：挂载节点数、最长帧时间和最大滚动修正，再谈重构。
