CustomElementRegistry 是浏览器识别自定义组件的核心机制，它通过注册表匹配与HTML解析时机双重确认标签身份：遇未知标签先查注册表，已注册则立即实例化并触发 constructor，未注册则暂作 HTMLUnknownElement，后续 define() 触发 upgrade 流程补执行 connectedCallback；upgrade 不重渲染，仅补初始化逻辑；connectedCallback 中不可直接操作 Shadow DOM，因元素可能尚未挂载到可渲染文档树，应使用 requestAnimationFrame 或 MutationObserver 延迟执行；Shadow DOM 样式隔离非绝对，外部选择器无法穿透，但 :host、:host-context()、::slotted() 及 CSS 自定义属性（--my-color）可穿透；动态插入 HTML 字符串时，即使已注册，connectedCallback 也需等待解析微任务后才触发。
CustomElementRegistry 是浏览器解析原生组件的起点，没有它，customElements.define() 就会报错：Failed to execute 'define' on 'CustomElementRegistry': this name is already used 或直接 undefined is not a constructor。现代浏览器（Chrome 67+、Firefox 63+、Safari 16.4+、Edge 79+）已原生支持，但 IE 完全不支持，且 Safari 对 adoptNode() 和部分生命周期钩子有延迟行为。
浏览器怎么知道一个标签是自定义组件？
不是靠标签名“看起来像”，而是靠注册表匹配 + 解析时机双重确认：
- HTML 解析器遇到未知标签（如
<my-button>），先查CustomElementRegistry是否已注册同名构造函数 - 若已注册，立即创建实例并进入
constructor钩子；若未注册，先作为HTMLUnknownElement存在，后续调用define()时触发upgrade流程 - 升级（upgrade）不是重渲染，而是补执行
connectedCallback—— 所以 DOM 已存在、但逻辑未初始化的“半成品”状态很常见
connectedCallback 为什么不能直接操作 Shadow DOM？
因为此时元素可能还没被插入到文档树的可渲染位置，document.body.contains(this) 可能为 false，导致 attachShadow() 失败或样式未生效。更隐蔽的问题是：如果组件依赖父级尺寸（比如要读 this.parentElement.clientWidth），这时父级可能尚未 layout。
- 安全做法：用
requestAnimationFrame(() => { /* attachShadow & render */ })延迟到下一帧 - 更健壮的做法：结合
MutationObserver监听自身是否真正挂载到可见文档中 - 不要在
constructor里调用attachShadow()—— 此时this.ownerDocument可能为null，Chrome 会静默失败
Shadow DOM 的样式隔离，浏览器到底封了什么？
不是“完全隔绝”，而是有明确边界规则：
立即学习“前端免费学习笔记（深入）”；
- 外部 CSS 选择器无法穿透 Shadow Root，哪怕写
my-button span { color: red }也无效 - 但
:host、:host-context()、::slotted()是浏览器专为 Shadow DOM 开的后门，它们由渲染引擎在样式计算阶段主动注入上下文 -
!important在 Shadow 内部依然有效，但无法覆盖外部通过:host设置的带!important的样式 - 注意：CSS 自定义属性（
--my-color）默认可继承穿透，这是有意设计，不是漏洞
真正容易被忽略的点在于：浏览器对自定义元素的解析和升级是异步且非原子的。比如动态插入 HTML 字符串：el.innerHTML = '<my-card></my-card>'，即使此前已 define()，my-card 实例也不会立即执行 connectedCallback —— 它得等浏览器完成本次 DOM 解析微任务后才触发。这导致很多“插入即用”的直觉失效。
