shadow dom 中的 css/js 不受 html 缓存策略控制，易被强缓存导致样式脚本不更新；adoptedstylesheets 和动态插入资源需显式设置 no-cache 或哈希 url；script 在 shadow dom 中仍运行于全局作用域，无 js 沙箱；service worker 无法精准控制注入后资源缓存；localstorage 需手动绑定唯一键名并校验结构。
Shadow DOM 里加载的 CSS/JS 不会自动随 HTML 缓存策略更新
HTML 文件本身设了 Cache-Control: no-cache，只保证每次请求新 HTML，但 Shadow DOM 内部通过 innerHTML 或 adoptedStyleSheets 注入的 CSS/JS 资源，仍可能被浏览器单独强缓存。比如你用 fetch('/widget.css') 获取样式后注入，若服务端返回 max-age=31536000，这个 CSS 就会久留本地，哪怕 HTML 已更新、新版本 widget.css 已上线，旧样式仍生效。
常见错误现象：adoptedStyleSheets 注入后样式没变，DevTools 的 Network 面板里该 CSS 显示 200 (from memory cache)；动态插入的 <link rel="stylesheet"> 在 Shadow DOM 中加载后，后续更新不触发重新下载。
- 所有通过
fetch+CSSStyleSheet注入的样式，必须确保响应头含Cache-Control: no-cache或带内容哈希的 URL（如/widget.a1b2c3.css） - 避免在 Shadow DOM 中直接写
<link href="/style.css">—— 它走全局文档的 base URL 和缓存上下文，不受 Shadow DOM 控制 - 若用构建工具生成 CSS，确认输出文件名用了
contenthash，且服务端对这类路径配了immutable
动态插入的 script 标签在 Shadow DOM 中仍执行于全局环境
把 <script>console.log('hi')</script> 插入到 shadowRoot 里，这段代码依然在 window 全局作用域执行，this 指向 window，不是 shadowRoot；它能读写 document.cookie、触发 history.pushState，完全穿透隔离边界。
这不是 bug，是规范行为：Shadow DOM 只封装样式和 DOM 查询，不提供 JS 沙箱。
- 不要依赖
innerHTML = '...<script>...</script>'来“局部执行”逻辑 —— 它根本不是局部的 - 若需沙箱化执行，必须手动剥离
<script></script>标签，用Function构造器并重绑定this、window、document到当前shadowRoot或虚拟上下文 - 第三方脚本（如统计 SDK）绝不能直接注入 Shadow DOM，否则会污染主应用的
globalThis，应改用 iframe 或 Service Worker 代理
Shadow DOM 内部资源无法被 Service Worker 缓存精准控制
Service Worker 的 cache.put() 可以缓存任意 URL，但当资源被注入到 Shadow DOM 后，浏览器对它的缓存行为不再受 SW 的 fetch 事件直接干预——特别是通过 adoptedStyleSheets 或 fetch().then(r => r.text()) 加载后再解析的 CSS，其缓存决策由主文档的缓存策略主导，SW 只能拦截原始网络请求，无法覆盖已注入后的运行时行为。
更麻烦的是：如果 SW 预缓存了 index.html，而该 HTML 包含挂载 Shadow DOM 的逻辑，那么即使你更新了 CSS 文件并刷新页面，SW 仍可能返回旧版 HTML，导致新 CSS 根本没机会加载。
- 务必检查 SW 是否预缓存了 HTML 入口，若启用，必须配合
skipWaiting()和clients.claim()触发更新 - 对 Shadow DOM 依赖的关键资源（如 widget.js），在 SW 的
fetch事件中显式添加版本号或时间戳查询参数（如?v=20260701），绕过旧缓存 - 避免在
install阶段静态缓存所有资源，改用 runtime caching 策略，按需缓存并设置 TTL
localStorage/sessionStorage 在 Shadow DOM 组件中需显式绑定生命周期
Shadow DOM 组件自己不会自动读写 localStorage，但开发者常误以为“组件封装了状态”，就把表单数据直接塞进 localStorage.setItem('widget-data', ...)，结果多个同类型组件实例共享同一 key，互相覆盖；或者用户清空浏览器缓存时，这些数据还在，但组件 UI 已重构，JSON 结构不兼容，解析失败。
关键点在于：localStorage 是全局的，Shadow DOM 不提供命名空间隔离。
- 键名必须带唯一标识，例如
widget-${this.getAttribute('id') || Date.now()}，避免冲突 - 写入前先校验数据结构有效性，读取后做 try/catch + schema 检查，失败则清除该 key
- 组件卸载（
disconnectedCallback）时，考虑是否要清理对应 localStorage —— 不是必须，但若涉及敏感信息（如 token），就得主动removeItem
document.currentScript 的指向、甚至 performance.getEntriesByName() 返回的资源列表里，Shadow DOM 内部加载的资源也混在全局条目中——这些地方没有银弹，只能靠提前约定、严格校验、分层清理。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
