SSR内联样式必须在渲染阶段压缩去重，而非依赖HTML后置压缩；需标准化空格、单位、属性顺序并基于最终CSS字符串哈希去重，避免体积膨胀与缓存失效。
服务端渲染（SSR）中直接往 HTML 字符串里写 style 属性，不压缩、不去重，等于把样式逻辑从 CSS 文件里“抄错题”到 DOM 上——体积膨胀、缓存失效、维护崩溃。
为什么 SSR 内联样式必须压缩，而不是只靠 HTML 工具扫一遍
HTML 压缩工具（如 html-minifier-terser）默认不会触碰 style 属性值里的空格和分号；它只处理标签间空白、注释、冗余属性。而 SSR 动态拼出的 style="margin: 0 ; padding : 1rem ; color: #333" 这类字符串，内部空格、空格+冒号+空格、多余分号全被原样保留，一万个元素就多出几十 KB。
- 必须在 SSR 渲染阶段就对每个
style值做标准化：合并空格、删分号末尾空格、转小写单位（px→px不变，但REM→rem）、移除重复声明（如color: red; color: blue留后者） - 不能依赖构建时的 HTML 压缩后置处理，因为此时样式已混入 HTML 字符串，无法安全识别哪些是用户写的、哪些是 SSR 注入的
- 若用正则粗暴替换
style="[^"]*"再压缩，会误伤<script>const s = 'style="..."'</script>这类合法字符串
内联样式去重必须基于计算后的最终值，而非原始 JS 对象
很多人在 SSR 中对样式对象做 JSON.stringify 去重，结果发现没用——因为 { margin: '0', padding: '1rem' } 和 { padding: '1rem', margin: '0' } 字符串不同，但最终生成的 style 属性值完全一样。
- 去重键应为标准化后的 CSS 字符串，例如
"margin:0;padding:1rem;"（注意结尾分号） - 需统一属性顺序：按字母序排列（
background在color前），避免因 JS 对象遍历顺序差异导致重复 - 忽略浏览器前缀差异：把
-webkit-transform和transform视为等价？不，它们语义不同，不能合并；但display:-webkit-box+display:flex应只留后者（现代浏览器已支持） - 慎用自动 vendor prefix 补全：SSR 时补的前缀可能和客户端 hydration 后实际生效的不一致，建议交由 CSS-in-JS 库（如 Emotion）或构建时 PostCSS 处理
服务端渲染中 style 属性压缩与去重的实际代码路径
以 Node.js + React SSR 为例，关键不是“怎么写”，而是“在哪一刻介入”。你不能等 ReactDOMServer.renderToString() 完了再全局正则替换，那样不可靠；必须在组件生成 props 阶段拦截。
立即学习“前端免费学习笔记（深入）”；
- 封装一个
useStyle或styled工具函数，在组件内部调用时就返回标准化后的style字符串，并缓存其哈希值（如xxHash32） - 用 Map 存已生成的样式字符串 → ID 映射，例如
"margin:0;padding:1rem;" → "s1"，然后输出style="s1"并注入全局<style>块——但这已不属于内联，属于 CSS-in-JS 的服务端提取方案 - 更轻量的做法：在
renderToString前，用parse5或cheerio解析中间 HTML 字符串，定位所有含style属性的标签，逐个清洗并去重，最后序列化回字符串——适合已有 SSR 框架不愿改组件逻辑的场景 - 避坑点：
cheerio.load(html, { xmlMode: false, decodeEntities: false })必须关掉实体解码，否则&变&，再序列化又变&，无限套娃
真正难的不是压缩算法，而是让 SSR 框架允许你在 style 属性落地前插一脚——多数框架把属性拼接锁死在内部 render 函数里。这时候，与其硬改源码，不如把内联样式控制权收归组件层，用纯函数生成 style 字符串，并强制走统一标准化管道。否则，你压得再狠，只要有一个 div style={randomStyle()} 漏网，整页压缩收益就归零。
