只读属性竟成性能杀手？
速览
文中指出的一个常见误区是只读属性也可能引发严重性能问题。通过分析读写开销和编译器优化，解释了为何看似无害的只读访问实际上可能拖慢程序。该发现对日常代码性能调优具有参考意义。
AI 深度解读
背景
Hacker News 上一篇文章揭露了一个容易被忽视的前端性能陷阱。作者在排查 Letta Desktop 的性能问题时，发现随着使用时间增长，产品越来越慢。起初他以为只是某个长循环或未优化的代码导致的，但最终的罪魁祸首却是一个看似无害的只读属性：scrollHeight。
核心内容
作者为了让 UI 在收到新消息时自动滚动到底部，使用了极其简单的 JavaScript 代码：
el.scrollTop = el.scrollHeight;
这段代码看起来很合理，scrollHeight 是只读属性，按常理应该很高效。然而实际表现恰恰相反——当大量消息持续流式输入时，每次设置 scrollTop 都会触发性能下降。
问题的根源在于 scrollHeight 并非静态的“纯只读”属性。根据 Chromium 引擎的实现（见原文中引用的 Element::scrollHeight() 代码），每次访问 scrollHeight 都会强制调用 Document::UpdateStyleAndLayoutForNode(this)，即触发完整的样式计算和布局刷新。这意味着每一条新消息到来时，浏览器都要重新计算整个文档的布局，而不仅仅是读取一个缓存值。
作者一开始假设“只读属性总是高性能的”，但这个假设被打破。他建议的解决方案是：用一个足够大的固定数值（如 1000000）代替精确的 scrollHeight，因为浏览器会自动将 scrollTop 限制在可滚动的范围内，从而避免每次计算布局的开销。
关键要点
- 只读属性 ≠ 静态属性：很多 DOM 只读属性（如
scrollHeight、offsetHeight、clientWidth等）在读取时会触发“强制同步布局”（forced synchronous layout），导致性能开销。 - 性能陷阱常见于高频触发场景：当消息流持续涌入时，每次设置
el.scrollTop = el.scrollHeight都会引发一次布局计算，累积下来会显著拖慢 UI。 - 替代方案更优：使用一个超大的固定数值（如
el.scrollTop = 999999），浏览器会自然将其截断为实际可滚动的最大值，避免每次动态计算。 - 不要盲目信任直觉：开发中很容易对“显而易见的简单属性”放松警惕，但底层实现可能完全不同。
意义与影响
这篇文章提醒我们，前端性能优化往往隐藏在看似基础的知识点中。许多开发者（包括资深工程师）都会默认“只读属性”是零成本的，但实际上 DOM 属性的读取可能触发昂贵的重排（reflow）操作。随着 Web 应用越来越重（如实时聊天、流式 AI 响应、大列表等），这种隐式开销的累积效应不容忽视。
解决方案（用固定大数代替精确值）虽然简单粗暴，但在“只求滚动到底部”的场景下完全可行，且能显著减少布局触发的次数。更深层的启示是：在追求性能时，不仅要关注自己写的逻辑，还要理解浏览器 API 的真实行为——尤其是那些看起来无害的只读属性。
最后，作者在文末列出了两个相关链接（"Less: Deleting code in the AI age" 和 "Moar: You need a webring!"），感兴趣的同学可以进一步探索。