服务端渲染时style属性只是字符串，不参与CSSOM构建、不被Critical CSS工具提取，也无法复用或审计；应优先使用类名替代，或谨慎使用CSS变量并确保安全转义。
服务端渲染时 style 属性根本不会被“提取”
HTML 的 style 全局属性（即 <div style="color: red">）在 SSR 阶段只是字符串，浏览器解析器不从中“提取”样式规则，也不生成 CSSOM 节点。它直接绑定到 DOM 元素的 element.style 对象上，属于内联样式的最底层实现。所谓“CSS 提取”，是开发者用工具从 <style> 标签或外部 CSS 文件中收集规则的行为，style 属性本身不在这个流程里——它没有选择器、不参与层叠计算、不被 document.styleSheets 管理。
style 属性内容无法被 extractCritical 或 critters 捕获
主流 Critical CSS 提取工具（如 critters、penthouse）依赖 CSS 解析器遍历 document.styleSheets 和匹配的 DOM 元素，但 style 属性中的声明不进入任何 CSSStyleSheet 实例。它们只存在于元素的 style 属性和计算样式树中，工具看不到原始字符串，更无法做选择器匹配或媒体查询分析。
- 如果你在 SSR 输出中写
<p style="margin: 0; font-size: 14px">Hello</p>，extractCritical(html, { css: ... })不会把它纳入关键 CSS - 即使你用
getComputedStyle(p).cssText在客户端读出结果，SSR 环境里没有 layout，getComputedStyle返回空对象或默认值 - 想让这类样式进 Critical CSS，唯一办法是提前把它们定义成类名，再通过真实 DOM 渲染后提取——比如用
class="text-sm m-0"替代style="font-size: 14px; margin: 0"
SSR 中动态 style 属性的真正风险不是提取失败，而是 FOUC 和水合错位
服务端输出带 style 的 HTML，客户端 hydration 时若 JS 重设了同一元素的 style，可能触发两次样式重计算：一次是 SSR 渲染时的初始值，一次是 hydration 后 JS 覆盖。尤其当 JS 使用 el.style.cssText = '...' 时，会清空服务端写的全部内联样式，造成视觉跳变。
- 避免在组件中同时使用 SSR 输出的
style和客户端useEffect(() => { el.style.cssText = ... }) - 改用
el.style.setProperty('--color', value)，它不覆盖已有声明，且服务端可预设style="--color: #333" - 若必须动态插值，确保服务端和客户端生成完全一致的
style字符串，否则 React/Vue 会标记为 mismatch 并强制重绘
真正该关注的是 style 属性里的 CSS 变量是否被 SSR 正确传递
服务端可以安全地输出 <div style="--theme: dark; --spacing: 1rem">，这些变量在客户端无需 JS 即可生效。但要注意：
立即学习“前端免费学习笔记（深入）”；
- 变量名必须是合法标识符（不能含
/、%、空格），否则服务端字符串会被浏览器静默忽略 - 不要在
style属性里混用 CSS 声明和变量：style="color: red; --size: 24px"是合法的，但style="--size: 24px; color: var(--size)"中的var()在 SSR 阶段不计算，客户端 hydration 前不会生效 - 如果变量值来自用户输入或未 sanitize 的数据，需转义分号、引号和括号，防止 XSS 注入（如
--user-value: "red"; background: url(javascript:alert(1))）
style 属性的操作，本质是字符串拼接和信任边界控制——它不参与 CSS 构建流程，也不受任何样式提取工具影响。最容易被忽略的，是把它当成“轻量 CSS”来用，却忘了它绕过了所有样式管理机制，既无法复用、也无法审计、更难做响应式适配。 
