Pierre Computer 5 月 29 日介绍了 @pierre/diffs 的新高层组件 CodeView。它接在 File、FileDiff 之后，目标不是再做一个单文件 diff 视图，而是在浏览器里承载完整代码审查界面。
这件事有意思的地方在反常处：很多人以为大 diff 卡，是 DOM 节点太多。原文真正指向的是三件事叠加——渲染、处理、内存。大 PR、批量生成的测试和快照、AI agent 一次性吐出的实现与配套文件，正在把“看 diff”变成前端基础设施问题。
CodeView 解决的不是一个列表，而是一整块 review surface
Diffs 原来提供 File、FileDiff 这类基础组件。它们更像积木，能展示文件和文件级 diff。Pierre Computer 后来补过 virtualizer，也提供 API，把语法高亮等工作移到 worker 线程。
但作者也承认，这还不够。大规模 diff 会同时压到三条线：页面要少渲染，CPU 要少处理，内存也不能被数据结构拖垮。只盯着 DOM 数量，容易漏掉后两项。
CodeView 的定位因此更高。它要管理文件列表、diff 内容、行级渲染、布局估算和滚动体验。换句话说，它接管的是 review surface，不只是一个代码块。
| 压力点 | 常见做法 | CodeView 的取向 | 对产品的影响 |
|---|---|---|---|
| Rendering | 减少视口外 DOM | 在完整审查面做虚拟化 | 滚动、跳转、定位变成核心体验 |
| Processing | 主线程处理高亮和解析 | 部分工作移到 worker | 文件一多，单次处理成本会被放大 |
| Memory | 依赖浏览器回收 | 控制渲染数据和布局状态规模 | 极端 diff 仍会撞上浏览器和硬件限制 |
这对前端基础设施工程师的影响很直接：不要只问“虚拟列表有没有”。要问它能不能处理行号、语法高亮、评论锚点、split/unified 视图和主题系统的组合成本。
对代码审查工具团队来说，动作更具体。短期可以先观望和试接入 demo，不急着迁移核心 PR 页。中期要评估一件事：采用 CodeView 后，团队是否能少维护一套滚动、定位、布局估算和 worker 管线。
虚拟滚动的空白问题，被大 PR 和 AI 代码放大了
传统虚拟化通常会创建一个接近完整高度的滚动区域，再只渲染视口附近内容。好处是保留原生滚动条、惯性和可访问性。问题是 JavaScript 可能追不上用户滚动。
用户快速拖动滚动条，或者从文件顶部跳到很远的位置，页面可能短暂空白。这个现象在普通列表里已经存在。在 diff 里更刺眼，因为代码审查依赖连续上下文，空一屏就会打断判断。
扩大 buffer 可以缓解 blanking。代价也清楚：更多 DOM、更多布局、更多内存。buffer 越大，虚拟化拿回来的收益越少。
另一条路是用 fixed 或 sticky 容器，再靠 requestAnimationFrame 更新内容。这能减少空白，但会把滚动体验押给 JS 调度。原文也提到，Safari 在高刷新率设备上的 requestAnimationFrame 限制，会让这条路更难做稳。
CodeView 采用作者团队命名的 Inverse Sticky Technique。它不是行业标准，也不是浏览器新能力，而是一个混合方案：保留原生滚动，再用负的 top/bottom sticky offset，让渲染区域在 JS 落后时仍贴住视口边缘。
原文给出的思路是，用类似 (contentHeight - viewportHeight) * -1 的方式计算 sticky 偏移。它的目标不是消灭物理限制，而是减少快速滚动时直接露出空白的机会。
我更在意的是这个取舍：它没有重做滚动，也没有假装普通虚拟列表足够。它承认浏览器滚动合成、JS 调度、布局测量之间有缝隙，然后把工程重点放在“缝隙别让用户马上看见”。
这对工具团队有用，但不能当成任意规模通行证
Pierre Computer 用 DiffsHub.com 展示 CodeView。用户可以把 GitHub 公共 diff 地址中的 github 替换为 diffshub 来试用。这里要分清：它是演示场，不是 GitHub 官方功能，也不是 GitHub PR 页面的官方替代品。
原文没有给 benchmark，也没有给文件数量、内存占用或具体性能数字。所以现在不能把 CodeView 写成“已解决所有大 diff 问题”。更稳妥的判断是：它把大规模 diff 的关键矛盾拆清楚了，并给出了一套可复用实现。
限制也要放在台面上。作者承认浏览器、计算和内存都有物理边界。Safari 在足够激进的滚动下，仍可能露出空白。
对前端基础设施团队，接下来该看三件事：
- 能否稳定嵌入现有设计系统、评论系统和权限逻辑。
- worker 化是否覆盖更多解析、高亮和布局前处理成本。
- Safari、Tauri、低配机器上的边界表现是否可接受。
对代码审查产品团队，决策不该只看 demo 顺不顺。更现实的问题是：接入它以后，能不能少掉一批长期维护项，比如滚动同步、行锚点、懒加载、评论定位和大文件兜底。
如果答案是能，采购或迁移才有意义。如果答案还看不清，就先延后核心链路替换，把它放在旁路页面、内部工具或只读 diff 场景里试。工程里很多坑不是“不能跑”，而是跑进主流程后没人愿意背维护账。