adoptedStyleSheets 是唯一标准方式，但必须三步全做：先 new CSSStyleSheet() 创建实例，再用 replaceSync() 或 replace() 注入规则，最后赋值给 shadowRoot.adoptedStyleSheets；漏步或浏览器不支持时需降级并谨慎处理重复注入与错误。
adoptedStyleSheets 是唯一标准方式，但必须三步全做
直接赋值 shadowRoot.adoptedStyleSheets = [sheet] 不生效，是因为它只接受已注入规则的 CSSStyleSheet 实例。常见错误是漏掉 replaceSync() 或用 link.sheet 替代——后者是只读且未激活的实例，样式永远不会进入 Shadow DOM。
必须严格按顺序执行：
- 调用
new CSSStyleSheet()创建空样式表（Chrome 73+、Firefox 94+、Safari 15.4+ 支持） - 用
sheet.replaceSync(cssText)注入规则（初始化推荐）或await sheet.replace(cssText)（需异步处理） - 显式赋值
shadowRoot.adoptedStyleSheets = [sheet]，注意它是只写数组属性，不是 setter
示例中若漏掉第二步，控制台无报错但样式完全不渲染；若在 Safari ≤17.3 中执行，会直接抛 TypeError: Illegal constructor。
降级到 fetch + style 标签时，重复注入和静默失败最危险
当 'adoptedStyleSheets' in shadowRoot 为 false（如 Safari ≤17.3、Firefox ≤116），必须 fallback，但简单拼字符串极易出错：
立即学习“前端免费学习笔记（深入）”；
- 多个同类型组件实例会重复插入相同
<style data-id="my-comp">，导致选择器权重叠加、样式覆盖混乱 -
fetch('./style.css')失败时默认静默吞掉，页面白屏或样式缺失却无任何提示 - 在
constructor中发起请求，此时shadowRoot尚未创建，直接报错
安全做法是：在 connectedCallback 中检查 !shadowRoot.querySelector('style[data-id="my-comp"]') 再插入，并用 catch 提供内联基础样式或抛出明确错误。
@import 在 shadowRoot.innerHTML 里是性能陷阱
看似兼容性好，实则卡首屏：浏览器必须阻塞后续 DOM 解析，等 @import './style.css' 下载并解析完才继续，延迟常达 300–600ms。更严重的是：
- 路径基于当前 HTML 文档 URL 解析，不是组件 JS 所在目录，
@import './index.css'几乎必然 404 - 返回 404/500 时整个
<style>块被丢弃，控制台零报错 - Webpack/Vite 等构建工具无法识别该路径，无法哈希、Tree Shaking 或预加载
它不走浏览器预加载队列，Network 面板显示为 “late”，且无法通过 preload 优化。
shadycss Polyfill 不模拟 adoptedStyleSheets，而是绕开它
webcomponentsjs 的 shadycss 并不补 CSSStyleSheet 构造函数，也不支持 adoptedStyleSheets 属性赋值。它用 DOM 操作 + 作用域重写实现近似效果：
- 把外部 CSS 字符串加载进来，自动给
:host、::slotted等选择器加上唯一 scope class（如.x-my-el-abc123） - 将处理后的样式插入
<head>或shadowRoot内的<style>标签 - 依赖
ShadyDOM节点包装机制维持作用域隔离
代价明显：无法动态修改 sheet 内容（只能替换整个 <style>）、不能复用同一份 sheet 实例、getComputedStyle 查不到原始自定义属性值，必须用 ShadyCSS.getComputedStyleValue()。
最容易被忽略的是动态创建 shadowRoot 的场景——比如在 connectedCallback 后才调用 attachShadow，若没手动触发 ShadyCSS.styleSubtree(el)，样式根本不会重计算，Polyfill 就“悄悄失效”了。
