内联样式在动态计算场景下确实有性能优势，但仅限于极少数明确条件——不是“写了就快”，而是“写对了才快”。
什么时候style属性比class切换更快？
当样式值由 JS 实时计算、且每次结果都不同（比如 canvas 坐标映射、拖拽实时偏移、滚动视差 offset）时，element.style.left = x + 'px' 比 element.className = 'pos-' + x 少一次 class 查找 + CSSOM 重排开销。
- 浏览器对
style属性的赋值是直接写入渲染树节点，跳过选择器匹配 - 如果用 class 控制，就得提前预定义几十上百个 class（如
.left-0到.left-1000），或靠 JS 动态注入<style></style>，后者触发 CSSOM 重建，开销更大 - 注意：仅适用于单属性高频更新；多个属性同时变（如
top、transform、opacity）建议合并用transform+will-change，而非堆style赋值
style属性在 SSR 或邮件模板里为什么必须用？
服务端渲染时无法保证客户端已加载 CSS 文件，而邮件客户端（如 Outlook、Apple Mail）普遍不支持 <link> 或 <style></style>，只认 style 属性。
- SSR 场景下，若首屏关键样式（如 loading 占位色、骨架图尺寸）依赖外部 CSS，网络延迟会导致 FOUC（Flash of Unstyled Content）；内联可确保首帧即渲染
- 邮件中写
<div style="font-size:14px;color:#333"> 是唯一可靠方式；<code>@media和伪类完全无效，别试 - 别把整页样式都塞进
style——只放首屏必需的、不可被 JS 替代的那几条 - 避免在循环或动画帧中混用：写用
element.style.transform = 'translateX(10px)'，读用element.getBoundingClientRect().x（不触发重排） -
element.style是一个 CSSStyleDeclaration 对象，它只存“显式设置”的值，不包含继承或计算结果 - 想批量读取多个布局信息？用
getBoundingClientRect()或offsetTop等单一属性，别反复调getComputedStyle
为什么element.style.xxx读取会强制重排？
读取 element.style.left 只返回你手动设过的值（如 "20px"），但读取 getComputedStyle(element).left 会触发 layout 计算——这是最常被忽略的性能陷阱。
真正决定快慢的不是“用了没用内联”，而是“有没有让浏览器少走一步 layout 路”。动态场景下，style 是工具，不是解药；滥用它反而会让 repaint 更频繁。
