内联style严重损害CSS的层叠性、复用性与可维护性，仅在邮件模板或极简静态页等极少数场景下可接受。
内联style会让CSS失去层叠和复用能力
直接在 <div style="color: red; margin: 0"> 里写样式，等于把本该由CSS规则统一控制的逻辑，硬塞进HTML结构里。浏览器渲染时，style 属性的优先级高于外部样式表和 <style> 块，但这种“高优先级”是失控的——它无法被 !important 以外的方式覆盖，更没法用媒体查询、伪类或属性选择器动态调整。
常见错误现象：hover 效果失效、响应式断点不触发、主题切换时颜色卡死；使用场景多见于CMS后台生成的富文本、老项目紧急 patch、或新手直觉式编码。
- 所有
style属性值都是字符串，无法继承父级计算后的值（比如em、rem、var(--color)在部分旧版 IE 中完全不生效） - 每次修改都要找 HTML 源码，无法用 CSS 预处理器变量、PostCSS 插件或构建时压缩优化
- React/Vue 等框架中，
style={{ color: 'red' }}看似可控，但若颜色来自 props 或状态，极易引发重复重绘，且无法利用 CSSOM 缓存
JavaScript 动态改 style 是唯一合理例外
只有当样式值必须实时响应 DOM 尺寸、滚动位置、用户拖拽等不可预知状态时，element.style.xxx = value 才是正当用法。比如实现一个跟随鼠标移动的 tooltip，或根据容器宽度动态设置 transform: translateX()。
但要注意：这类操作应封装成独立函数，避免在事件回调里反复读写 offsetWidth 或 getComputedStyle，否则触发强制同步布局（Layout Thrashing）。
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 优先用
requestAnimationFrame批量处理样式变更 - 能用 CSS 自定义属性（
setProperty('--x', val)）替代直接写style.left，便于后续用 CSS 过渡动画衔接 - 绝对不要在循环中对多个元素逐个赋值
style.color，改用 class 切换 + CSS 规则更高效
Vue/React 里用 :style 和 style={{}} 的陷阱
这些语法看似“合法”，实则放大了内联样式的缺陷。Vue 的 :style="{ opacity: isLoaded ? 1 : 0 }" 和 React 的 style={{ opacity: loading ? 0.5 : 1 }} 本质仍是运行时拼字符串，导致样式无法提取、压缩、缓存，且服务端渲染时可能因环境差异产出不同结果。
性能影响明显：每次 state 变化，JS 引擎都要构造新对象，再由框架 diff 后映射为 DOM 操作；而 class 切换只需比对字符串，V8 优化更成熟。
- 复杂条件建议抽成 computed（Vue）或 useMemo（React），但最终仍推荐转为 class 名控制，例如
:class="{ 'is-loaded': isLoaded, 'is-error': hasError }" - 动画相关样式（
transition,transform）若需 JS 控制，请用requestAnimationFrame+transform，而非频繁改top/left - SSR 场景下，
style={{}}中的表达式若依赖浏览器 API（如window.innerWidth），会导致 hydration 不一致报错
真正需要 inline style 的极少数情况
只有两类场景值得破例：邮件模板（多数客户端只认内联）、超轻量静态页（无构建流程、无复用需求、全站就 3 个页面）。即便如此，也建议用构建脚本自动内联 CSS，而不是手写 。
容易被忽略的点：CSS-in-JS 库（如 Emotion、Styled Components）虽然也生成 style 标签或内联样式，但它们通过哈希类名、服务端提取、样式作用域隔离等机制规避了传统内联 style 的问题——这和直接写 style="..." 是两回事。
真正在 HTML 标签里敲 style 属性，基本等于主动放弃样式系统的全部基础设施。不是不能用，是用了之后，后面的人得花三倍时间把它揪出来、拆干净、再重写一遍。
