百万行PR也能顺滑滚动，GitHub靠的不是再加一层虚拟列表

超大代码评审卡顿，通常不是“行数太多”这么简单。GitHub公开的极限样本包含2200个文件、超过100万行改动和400多条行内评论。它真正难处理的是评论高度会随图片、折叠块和回复框变化。GitHub的核心判断很值得复用：确定高度与未知高度不该共用一套几何。

发生了什么

GitHub在9月23日发布工程复盘，说明Copilot应用如何重建PR差异页面。官方事实包括：代码行只渲染视口附近节点；评论用稳定键绑定到文件、行和左右侧；后端数据增量进入；页面内置结构化探针，并由无人值守流程反复滚动、展开、回复和缩放窗口。

这不是一次“AI把页面优化好了”的宣传。AI或自动化代理可以驱动测试和排序瓶颈，但可验证的健康信号、布局不变量和架构边界仍由工程团队定义。

技术原理：一张页面，两套坐标

代码行高度固定，可提前计算前缀和：第N行的纵向位置是前N-1行高度之和。评论却是动态块，Markdown换行、details展开、图片加载都会改变高度。若把新测量值写回一张总偏移表，下面所有内容会移动，用户看到的就是滚动跳跃。

GitHub将总高度拆为“确定代码高度 + 动态块有效高度 + 滚动留白”。动态块先用估计值占位，渲染后再测量；修正时以用户正在看的内容为锚点，补偿滚动位置，而不是让锚点跟着页面漂移。宽度也按区间记录，普通窗口抖动不会让所有测量失效。

最小实践：动态块变高时守住锚点

下面的JavaScript模拟一条评论从80像素变为140像素。若它在当前锚点之前，滚动位置同步增加60像素，用户看到的代码就不跳。无需依赖，保存为anchor.js，运行node anchor.js。

const blocks = new Map([
  ["comment:a", { top: 120, height: 80 }],
  ["comment:b", { top: 560, height: 100 }],
]);

let scrollTop = 500;
const anchorY = 500;

function measureBlock(id, measuredHeight) {
  const block = blocks.get(id);
  const delta = measuredHeight - block.height;
  block.height = measuredHeight;

  for (const [otherId, other] of blocks) {
    if (otherId !== id && other.top > block.top) {
      other.top += delta;
    }
  }

  if (block.top < anchorY) scrollTop += delta;
  return { id, delta, scrollTop };
}

console.log(measureBlock("comment:a", 140));
console.assert(scrollTop === 560, "anchor moved");
console.assert(blocks.get("comment:b").top === 620, "offset stale");

本次已用Node.js 22实际运行，两条断言通过，输出修正量60和新滚动位置560。真实产品还需处理并发测量、删除、宽度桶与浏览器绘制时序；这个例子只验证锚点补偿的核心不变量。

把它接进浏览器时，应在requestAnimationFrame内批量消费测量结果，避免一次评论变化触发多次同步布局。稳定键也不能使用数组下标：评论被插入或线程重新排序后，下标会改变，旧高度就会套到错误节点。比较可靠的键应包含文件、行、左右侧和评论线程标识，并在内容或展开状态变化时更新高度指纹。

为什么数据管线与探针同样重要

页面再快，若必须等所有文件和评论到齐才显示，用户仍会觉得慢。官方做法是先取得轻量拓扑，再流入Diff与评论，并保留已经完成的工作。更关键的是，他们没有依赖临时console.log，而是在生产代码里长期回答几件事：当前挂载多少行、每帧提交几次测量、修正幅度多大、Observer是否卸载、滚动后是否仍插入未知评论。

这些信号被写成端到端预算。自动流程打开冷页面和热页面，深度滚动、展开折叠、打开回复框并调整窗口；只有全程无空洞、无空白评论且真实线程挂载，样本才算健康。这里AI最合适的角色不是“凭感觉改代码”，而是消费稳定指标，重复执行变化—测量—排序。

团队可以从一条简单基线开始：固定滚动路径与窗口大小，记录最大挂载节点数、最长主线程任务、最大锚点修正和最终Observer数量。每个指标都要设失败阈值，并把冷缓存与热缓存分开。这样即使某次优化让平均帧率变好，也不会掩盖深处文件出现空白或监听器泄漏。