浏览器不认拼接字符串，因其绕过CSS引擎优化，将样式计算强塞JS引擎执行，导致重排重绘频繁、无法复用规则、缺失类型检查与原生特性支持。
因为浏览器不认你拼出来的字符串，它只认解析后的样式规则；更关键的是，这种写法绕过了CSS引擎的全部优化能力，把本该由C++层处理的样式计算，硬塞进JS引擎里反复执行。
为什么element.style.cssText = 'color: red; font-size: 14px;'不是好主意
这行代码看似简洁，实际在频繁触发重排重绘。每次赋值，浏览器都要重新解析整段字符串、构建样式声明、合并继承值、计算最终像素——而这些本可由CSS引擎一次性批量完成。
- 无法利用CSS变量、
@media查询、伪类等原生特性 - 字符串拼接极易出错，比如漏掉分号、引号嵌套混乱，错误只在运行时暴露
- 没有类型检查，
font-szie: 12px这种拼写错误不会被IDE或TS捕获 - 无法复用，相同样式在多个地方重复拼写，改一个就得全局搜
style对象直接赋值 vs class切换：性能差在哪
写el.style.color = 'blue'看起来比字符串安全，但它依然绕过样式层缓存。浏览器对class切换做了大量底层优化：比如同一class多次应用，只会计算一次；而JS逐属性赋值，每次都是全新计算路径。
- class切换走的是DOM属性变更+样式表匹配，浏览器能复用已解析的规则树
- 直接操作
style对象强制触发内联样式计算，且无法被CSS预处理器、PostCSS等工具链处理 - 响应式场景下，
matchMedia监听+class切换可自动生效；JS手动改style则要自己监听、自己重算、自己重设
CSS-in-JS库（如styled-components）是不是例外
不是。它只是把字符串拼接从手写搬进了模板字符串，本质仍是运行时生成样式规则。虽然加了哈希类名、服务端渲染支持，但核心问题没变：样式逻辑和JS执行耦合，无法静态分析，打包后仍需JS解析才能注入
- 服务端渲染时，
styled-components必须同步执行组件JS才能提取CSS，阻塞首屏 - Tree-shaking对样式无效，未使用的
styled.div仍会生成对应CSS规则 - 调试困难：Chrome开发者工具里看到的是随机哈希类名，找不到源码位置
真正难的是把“动态样式”这件事想清楚：到底是真需要JS参与计算（比如根据滚动位置实时调整opacity），还是只是懒——图省事跳过CSS变量、:has()、锚点定位这些2026年已广泛支持的原生能力。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
