内联style属性在万级表格中显著增加内存占用，因浏览器为每个元素单独创建cssstyledeclaration对象并强制计算样式，而class可复用同一cssrule；实测6万行下内存差达32–45mb。
直接给每行加 style 属性（比如 <tr style="background-color: #f5f5f5;">）在万级行表格中会显著抬高内存占用，不是因为样式本身重，而是触发了浏览器对每个元素的独立计算与样式缓存机制。
<h3>为什么 <code>style 属性比 class 多占内存
浏览器对内联 style 的处理是“逐元素解析+强制计算”，而非复用。哪怕两行样式完全一样，<tr style="color:red"> 和 <code><tr style="color:red"> 也会生成两个独立的 CSSStyleDeclaration 对象，各自持有完整的计算属性树；而 <code>class="row-red" 共享同一份 CSSRule，DOM 节点只存一个 className 字符串引用。
实测：6 万行表格中，全部用 style 设置背景色，V8 堆中 CSSStyleDeclaration 实例数 ≈ 60,000；全改用 class 后，该类实例数 ≤ 10（来自样式表规则），内存下降约 32–45MB（Chrome 126，Windows x64）。
- 内联
style会阻止浏览器对相同样式的合并优化，哪怕只是color或opacity这种单一属性 - DevTools 的 Memory 面板中，搜索
CSSStyleDeclaration可直观看到数量膨胀 -
getComputedStyle(el)调用频率越高，内联样式带来的开销越明显——它必须为每个元素重新走一遍计算流程
哪些场景下仍不得不写 style？怎么控损
真实业务中确实存在动态、单次、不可预知的样式需求，比如按后端返回的状态码实时着色、临时高亮某几行、或根据用户偏好切换深色/浅色单元格。这类无法提前定义 class 的情况，不能硬套 class 模式，但可以规避最差实践：
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 禁止在循环中拼接完整
style="..."字符串（如tr.style = 'background:' + color），这会强制触发重排并创建新对象 - 改用
el.style.setProperty('background-color', color)，它复用已有 StyleDeclaration，不新建对象 - 对批量操作，先收集所有需着色的
tr元素，再统一调用el.style.setProperty，避免反复触发样式计算 - 若仅需控制一两个属性（如
opacity或filter），优先用transform或will-change触发 GPU 加速层，减少主线程样式计算压力
table-layout: fixed 配合内联样式时的隐藏陷阱
很多人以为加了 table-layout: fixed 就能稳住性能，但若同时大量使用 style 修改 width、min-width 或 padding，反而会破坏 fixed 布局的提前列宽计算逻辑，导致浏览器退回到 auto 布局模式，重新扫描全部 td 内容来测量——这时内存和 CPU 开销会指数级上升。
- 列宽应严格由
<col>或thead th的 CSS width 控制，禁止在tr或td上用style覆盖宽度相关属性 - 如果某列内容需要“弹性撑开”，用
width: auto配合white-space: normal，而不是靠内联style动态设min-width - 检查 DevTools 的 Layout 面板，若看到 “Layout Invalidated” 频繁出现且来源是
tr或td，基本可判定是内联样式干扰了 fixed 布局
真正难调的不是“有没有用 style”，而是“有没有让浏览器反复为同一类样式做重复工作”。只要内联样式出现在高频渲染路径里，哪怕只改一个 color，它就不再是轻量操作——得把它当成 DOM 更新的一部分来设计生命周期。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
