shadow dom是唯一能从dom层硬隔离多团队html样式冲突的方案，必须在custom element构造函数中调用attachshadow({mode:'closed'})，配合domparser解析、cssstylesheet注入和沙箱化脚本执行，否则任何class命名约定均无效。
多团队联调时 HTML 代码质量失控，根本原因不是写法不规范，而是 class/id/data-* 这些属性天然没有作用域——class="btn" 在 A 团队 Button 和 B 团队 Modal 里同时出现，谁的 CSS 先加载、谁的选择器更具体，谁就赢。接口级隔离必须从 DOM 层开始卡住，不能靠约定或后期检查。
为什么直接用 data-team 或 BEM 命名无法解决联调冲突
这些只是字符串标记，浏览器根本不识别“团队语义”。data-team="marketing" 不会阻止主应用的 .header 规则匹配到子应用的 <div class="header">；BEM 的 <code>my-button__icon 也挡不住外部 [data-app="cart"] .my-button__icon { display: none } 的覆盖。
- 所有
class、id、data-*都是全局注册表，没有隐式命名空间 - 构建时加哈希（如
btn_abc123）只能防同名碰撞，拦不住div.header这类标签选择器穿透 - 运行时靠 JS 查询
document.querySelectorAll('[data-team="finance"]')可以定位，但样式仍被污染
attachShadow({ mode: 'closed' }) 是唯一能卡住 DOM 层的硬隔离手段
它不是“让样式更好管”，而是切断外部 CSS 选择器对内部节点的匹配能力。只要没这句，任何“组件封装”都是纸墙。
- 必须在 Custom Element 构造函数中立即调用：
this.attachShadow({ mode: 'closed' })，延迟执行等于没做 -
mode: 'open'允许el.shadowRoot被外部读取，生产环境等同于放弃隔离 -
mode: 'closed'下el.shadowRoot返回null，但 DevTools 仍可查看（需开启“Show user agent shadow DOM”） - Shadow DOM 内部的
<style></style>不会泄漏，外部规则也无法穿透，连!important都无效
HTML 模板注入必须绕过 innerHTML，否则隔离失效
写 shadowRoot.innerHTML = htmlString 看似简单，实则让所有 <style></style> 和 <script></script> 逃逸到全局——样式污染、XSS、document.body.classList.add('dark') 全部复现。
- 正确路径：用
DOMParser解析 HTML → 提取<style></style>内容 → 转为CSSStyleSheet→ 通过shadowRoot.adoptedStyleSheets = [sheet]注入 -
<script src="..."></script>必须拦截 fetch，再在沙箱中重绑定window/document后执行，不能直接插入 - 禁止模板内硬编码
id="modal"，改用动态生成的data-id，否则getElementById返回错节点 - 克隆模板必须用
document.importNode(tmpl.content, true)，cloneNode(true)会丢掉<input checked>状态
真正难的不是写对那一行 attachShadow，而是整个子应用的 HTML 构建链路都要适配 Shadow DOM：第三方库是否依赖 document.querySelector、CSS 中的 @import 和相对路径怎么处理、adoptedStyleSheets 在 Safari 16.4+ 才支持——这些细节漏掉一个，隔离就塌一半。
