内联CSS和第三方SDK动态注入的样式会以高权重（1000）覆盖normalize.css等基础规则，导致按钮圆角消失、input高度突变等；唯一可靠防御是使用closed模式Shadow DOM隔离样式作用域。
内联CSS直接覆盖normalize.css基础规则
第三方 SDK（比如埋点、广告、客服组件）常在运行时动态插入 <style></style> 标签到 document.head，或直接给元素写 style 属性。这类内联样式权重为 1000，远高于 normalize.css 中的 button { margin: 0.5em; }（权重仅 1）。一旦加载，宿主页面的按钮边距、输入框行高、标题字体粗细等基础表现立刻被重置——不是“没生效”，是被暴力压垮了。
常见现象包括：button 圆角消失、input 高度突变、h2 字体变细、ul 列表项缩进归零。打开 DevTools 的 Computed 面板，点开任意元素，如果 margin 或 font-weight 显示来自 SDK 注入的 <style></style> 块，就坐实了这点。
全局选择器无前缀 + !important = 宿主无法防御
SDK 内联样式往往用泛化选择器配合 !important，例如：
div.text { color: #666 !important; }
* { box-sizing: border-box !important; }
body { line-height: 1.4 !important; }
这些规则不依赖 class 名，也不挑环境，只要 DOM 存在，就命中。宿主页面哪怕用了 BEM 或 CSS Modules，也拦不住 div.text 这种通配式打击——因为它是基于标签和属性匹配的，不是类名。
立即学习“前端免费学习笔记（深入）”；
- 宿主写
.my-card__title { color: #333; }→ 无效（权重 10 - 宿主加
!important→ 仍无效（同权重下后声明者胜，SDK 总是后注入） - 宿主改用
div.my-card__title→ 依然无效（权重 11
Shadow DOM 是唯一能切断传播链的原生机制
想真正阻止 SDK 的内联样式影响，不能靠“写得更狠”，而要让它根本“找不到目标”。attachShadow({ mode: 'closed' }) 创建的影子根，天然阻断外部样式穿透，也防止内部样式逃逸。SDK 即使往 document.head 插 <style></style>，也进不了 shadowRoot；它给宿主元素写的 style="color:red"，对影子树里的 <p></p> 也完全无效。
关键点：
- 必须用
mode: 'closed'，open模式下外部脚本仍可读取并篡改shadowRoot - 不要把 SDK 的 HTML 直接塞进
shadowRoot.innerHTML，否则其中的<style></style>仍会注入全局——应先解析模板，把<style></style>节点单独appendChild到shadowRoot，确保作用域锁定 -
:host { all: initial; font-family: inherit; color: inherit; }必须显式设置，否则宿主的body字体、颜色会继承进来
构建期无法拦截运行时注入，只能靠运行时防御
Webpack/Vite 的 css-loader 或 postcss-prefixwrap 对 SDK 运行时动态插入的样式完全无效——它们只处理构建时已知的 CSS 文件。你打包时再怎么加前缀、套 scope，也管不住 SDK 在用户点击后才执行的 document.head.appendChild(styleEl)。
所以，别寄希望于“构建工具能兜底”。真实对抗发生在浏览器里：
- 若 SDK 提供挂载容器 API（如
init({ container: el })），就把这个el设为 Shadow DOM 容器 - 若 SDK 只接受 ID 字符串（如
container: '#widget'），需提前创建带 shadowRoot 的元素并设好 ID - 绝对避免用
document.getElementById('widget').innerHTML = sdkHtml—— 这等于主动开门放火
最易被忽略的是：很多团队以为加了 <style scoped></style> 或启用了 CSS Modules 就安全了，但 scoped 只作用于 SFC 内部的 <style></style>，对第三方 JS 动态插入的内容毫无约束力。真正隔离，从来不在构建层，而在 DOM 层。
