聊聊如何渲染代码 Diff
文章摘要
Pierre Computer Company 发布了 CodeView，一个”虚拟化优先”的组件，目标是在任意规模下都能流畅渲染代码 diff。这篇文章记录了在浏览器里高效展示大型代码变更所遇到的技术难题以及对应的解决方案。
核心问题在于：渲染 diff 看似简单，但一旦上规模就变得复杂。语法高亮、行号、评论、主题等功能都会带来额外的处理开销。当这些操作在成千上万个文件上重复时，”那些孤立来看很快的工作，重复几千次后就会变得昂贵”。文章归纳出三大技术挑战：渲染（DOM 复杂度快速增长，导致滚动时卡顿）、处理（在大型变更集上的重复操作成本呈指数级叠加）、内存（大文件消耗大量浏览器内存，频繁触发垃圾回收）。
文章给出的关键解决方案包括：
反向 sticky 技巧：与其在滚动时把内容钉在视口顶部，CodeView 反过来用负 sticky 偏移（计算为 (contentHeight - viewportHeight) * -1），让内容在滚过后钉在视口底部。这既保留了浏览器原生滚动，又避免了快速滚动时出现空白区域。
可扩展布局：系统用 lineHeight * totalLines 加上 hunk 分隔符高度来廉价地估算布局尺寸。一套 checkpoint 机制让”确定要渲染哪些行”时可以用二分查找取代昂贵的线性查找。滚动锚定（scroll anchoring）则在 DOM 变更前记录锚点、变更后协调位置，保持视图稳定。
内存优化：团队解决了三个内存问题——字符串分离（强制让解析后的字符串脱离源 patch，避免意外保留整个上 GB 的输入文件）、DOM 池化（复用容器外壳而非反复创建，减少分配抖动）、共享配置状态（把配置状态集中管理，而非在成千上万个实例间重复）。
延迟高亮：语法高亮在 worker 线程中异步运行，允许先渲染纯文本再渐进增强，并用 LRU 缓存避免重复高亮相同代码。
文章也坦承了遗留难题：激进滚动时 CSS 布局和绘制成本占主导；worker 序列化在超大文件上会成为瓶颈；横向滚动和超长行尚未虚拟化，会拖累 DOM 性能。在平台层面，Safari/WebKit 尤其麻烦：sticky 定位性能落后于 Chrome/Firefox，开发者工具缺乏足够的性能可见性，requestAnimationFrame 即便在高刷新率屏幕上也被限制在 60Hz，深度滚动还有影响 slot 容器注入的 bug。
HN 评论精华
布局与可读性：讨论一开始，cipherself 就为文章左对齐的排版给出了实用的修正建议。chrismorgan 指出这种设计如今已不常见，并认为更大的问题在于字号（12px）和等宽字体影响了可读性。adrian_b 解释说，左对齐内容在现代宽屏显示器上尤其碍眼——偏离中心的文字被甩到离视觉中心很远的地方，”会更加让人难受”。
核心技术之争：关于”虚拟化是否必要”出现了实质性的分歧。charcircuit 认为现代电脑资源充足，不需要这些”复杂的技巧”就能处理大型 diff；而 mrkcsc 反驳说浏览器原生根本没有为此优化，所以这些变通手段是必需的。作者随后演示了支持超过 3600 万行的 diff。
替代思路：nerdypepper 建议语义/AST 级别的 diff 比单纯的渲染性能更有价值。作者（amadeus）承认已规划语义 diff 支持，但强调无论 diff 多大，优化都能减轻用户负担。
移动端性能：akdor1154 反馈说尽管文章强调流畅滚动，在移动设备上仍有卡顿，作者认为这是建设性的反馈。多位评论者还提到浏览器搜索和原生虚拟化的不足，并建议修复浏览器本身可能让整个 Web 生态都受益。