@github：渲染百万行的差异视图倒是容易。评论才是让它出问题的原因。评论的高度取决于 Markdown 的换行，……

渲染百万行的差异视图其实是容易的部分。👀

真正让它出问题的是评论。评论的高度取决于 Markdown 换行、展开的详情、打开的回复框，以及仍在加载的图片（这些都只有渲染后才能知道）。

下面聊聊我们是如何重构 GitHub Copilot 应用中的 PR 视图的 🧵

代码行的高度是已知的。你可以预先计算整个布局的几何信息，之后无需修正。

评论的高度却无法预测。所以，我们不再强行让同一套几何布局同时服务于两者，而是将文档拆分为两个独立的高度区域。

在最初的设计中，我们为每个动态块配置了一个 ResizeObserver，将测得的高度写回布局。

我们实现了它，然后否决了它。观察器如果把高度写回自己正在观察的布局，就可能再次触发自身，而且开销会随着每个已挂载的块而增长。

最终上线的方案是周期性执行测量，仅在空闲时运行，范围限定在视口周围约 2400px 的区域。已挂载块的实际尺寸才是依据。观察器通常只负责标记需要在这一轮测量的块，而不会自行写入高度。

有一个例外：如果可见块因用户操作而改变尺寸，可以在绘制前同步修正一次。这样既能让评论及其下方的代码一起移动，也不会重新开启反馈循环。

曾经阻碍我们推进的一个 bug 来自“滚动时不要修正”这条规则。它通过时间戳来拦截修正，而我们自己通过程序触发的滚动也会更新这个时间戳。

切换侧边栏后，差异面板的宽度会改变。换行内容重新排布，界面在稳定下来的过程中会触发一次小幅滚动。拦截逻辑将其误判为你的输入，跳过了本该用于保持阅读位置的修正。于是，你正在阅读的文件就移出了屏幕。

任何判断“用户是否正在交互”的检查，都必须区分真实的用户输入和自身副作用引发的滚动。

打开你手头最棘手的拉取请求，试试看 👇