自定义元素实例间不共享状态，需通过全局对象、localStorage、顶层状态管理或事件广播实现；Shadow DOM 内部状态须通过属性或 getter/setter 暴露；事件需设置 bubbles: true 和 composed: true 才能跨边界冒泡；路由切换时应在 disconnectedCallback 中持久化状态，并避免重复注册。
customElements.define() 注册后，组件实例间如何共享状态？
原生自定义元素本身不提供跨实例状态管理能力。每个 <my-counter> 实例都是独立的，constructor() 和 connectedCallback() 中的 this.state 仅作用于当前 DOM 节点。
想让多个组件响应同一份数据，必须引入外部状态源。常见做法是：
- 用全局对象（如
window.appStore）手动同步，但易失控、难调试 - 借助
localStorage或sessionStorage持久化关键状态，适合用户偏好、表单草稿等场景 - 在顶层组件（如 Shell 或 App 根节点）中维护状态，并通过属性（
attributeChangedCallback）或自定义事件（this.dispatchEvent(new CustomEvent('statechange'))）向下/向上广播 - 避免直接依赖 Redux / Zustand 等库的状态订阅机制——它们无法自动感知 Shadow DOM 内部变化，需手动桥接
Shadow DOM 隔离下，父页面如何读写自定义元素内部状态？
Shadow DOM 的封装性是一把双刃剑：它阻止样式泄漏，但也阻断了父级对内部节点的直接访问。你不能用 document.querySelector('my-form').shadowRoot.querySelector('input') 这种方式稳定读取——因为 shadowRoot 可能为 null（如果组件未启用 mode: 'open'），且在 SSR 或 hydration 阶段可能尚未挂载。
正确暴露状态的方式只有两种：
立即学习“前端免费学习笔记（深入）”；
-
通过属性（attributes）和属性变更回调：定义
static get observedAttributes()，在attributeChangedCallback(attr, oldVal, newVal)中响应变化；父页通过el.setAttribute('value', 'xxx')控制，组件内部再映射到 UI -
通过公开的 getter/setter 方法：在类中定义
get value() { return this._value; }和set value(v) { this._value = v; this.render(); }，父页调用el.value = 'new'即可
别试图绕过封装去操作 shadowRoot ——这会破坏 Web Components 的设计契约，且在 Chrome 125+ 中对闭合模式（mode: 'closed'）完全不可行。
多层级嵌套自定义元素时，事件冒泡是否穿透 Shadow DOM 边界？
默认情况下，CustomEvent 不会穿透 Shadow DOM 边界，除非显式设置 bubbles: true 和 composed: true。这是最容易踩的坑：很多开发者写了 this.dispatchEvent(new CustomEvent('submit'))，结果父页面监听不到。
正确写法必须包含这两个选项：
this.dispatchEvent(new CustomEvent('submit', {
bubbles: true,
composed: true,
detail: { data: this.formData }
}));
同时，父页面监听时无需特殊处理，直接用 document.addEventListener('submit', handler) 或 parentEl.addEventListener('submit', handler) 即可捕获。
注意：composed: true 是关键。它允许事件跨过 Shadow DOM 边界向上传播到 light DOM，但也会让事件被同级其他 Shadow DOM 捕获（如果它们也监听了该类型事件），需结合命名空间（如 'my-form:submit'）避免冲突。
SPA 路由切换时，自定义元素如何保持状态不丢失？
当使用 history.pushState() 切换路由但不刷新页面时，DOM 节点通常被复用或卸载重挂。此时 disconnectedCallback() 会被触发，但 connectedCallback() 不一定立刻执行——尤其在框架（如 Lit、Stencil）做懒加载或条件渲染时。
要确保状态延续，必须主动持久化关键字段：
- 在
disconnectedCallback()中将必要状态存入localStorage或sessionStorage，键名建议带上组件 ID 或路径前缀（如`form-${this.id}-draft`） - 在
connectedCallback()开头检查对应存储项，存在则恢复（注意 JSON 解析失败兜底） - 若组件有异步初始化逻辑（如拉取远程配置），不要在
constructor()中发起请求——此时this.getAttribute()可能还未就绪，应推迟到connectedCallback()
最隐蔽的问题是：同一个自定义元素在不同路由下被多次注册（customElements.define() 被重复调用），会直接报错 Failed to execute 'define' on 'CustomElementRegistry': the name "x-button" has already been used。务必加守卫：if (!customElements.get('x-button')) customElements.define('x-button', XButton)。
