自定义元素必须配合shadowRoot封装且在DOM ready后注册，否则成为空壳；需用open模式便于调试；属性更新应通过getter/setter而非仅attributeChangedCallback；模板首选<template>标签。
直接说结论：自定义元素不是“写个新标签就完事”，它真正起效的前提是必须配合 shadowRoot 封装样式与DOM，且注册时机不能早于 customElements.define() 调用。否则你写的 <my-button> 本质上只是个空壳，照样会样式污染、逻辑耦合、复用失效。
为什么 customElements.define() 必须在 DOM ready 后调用？
浏览器解析 HTML 是同步流，如果脚本在 <my-button> 标签之前执行 customElements.define()，该元素会被当作“未知元素”提前解析并挂载——此时构造函数还没运行，connectedCallback 不触发，shadowRoot 不创建，后续所有逻辑都失效。
- 常见错误现象：
<my-button>渲染为空白，控制台无报错，但点击没反应、样式不生效 - 正确做法：把定义语句放在
<script>标签末尾，或包裹在document.addEventListener('DOMContentLoaded', ...)中 - 更稳妥的写法：使用
customElements.whenDefined('my-button').then(...)做依赖等待，尤其在多模块异步加载时
attachShadow({mode: 'open'}) 和 mode: 'closed' 怎么选？
绝大多数场景下必须用 mode: 'open'。选 closed 看似更“安全”，实则断掉了调试和集成能力——父组件无法通过 el.shadowRoot 访问内部结构，自动化测试、DevTools 检查、甚至某些框架（如 Vue 的 ref 绑定）都会失败。
-
mode: 'open'：允许外部 JS 读取shadowRoot，支持调试、测试、跨框架集成 -
mode: 'closed'：仅限极端隔离需求（如广告 SDK），但会牺牲可维护性，不推荐日常使用 - 注意：
shadowRoot必须在constructor中调用attachShadow，不能拖到connectedCallback—— 否则首次渲染会漏掉样式注入
属性变更怎么触发 UI 更新？别只靠 attributeChangedCallback
attributeChangedCallback 只监听 HTML 属性（即字符串值），对布尔属性（如 disabled）、对象/数组属性完全无效。硬靠它做响应式更新，90% 的情况会漏更新或类型错乱。
立即学习“前端免费学习笔记（深入）”；
- 正确姿势：把属性映射为类内部的 getter/setter，例如
set disabled(value) { this._disabled = value !== null && value !== 'false'; this.render(); } - 配合
static get observedAttributes()列出需要监听的属性名，但仅用于初始化同步，不要在里面写复杂逻辑 - 避免在
attributeChangedCallback里直接操作this.shadowRoot—— 此时 DOM 可能尚未挂载，应统一收口到render()方法中
模板内容从哪来？别用 innerHTML 拼接字符串
手写 this.shadowRoot.innerHTML = `...` 看似快，但会丢失事件绑定、破坏 SSR 兼容性、且无法静态分析——一旦模板变长或含条件逻辑，维护成本指数级上升。
- 首选方案：用原生
<template>标签预定义结构，再用template.content.cloneNode(true)注入，保证语义完整、可复用、易测试 - 次选方案：用
document.createElement()+appendChild()构建，适合极简组件（如单按钮） - 绝对避免：
eval()、new Function()、第三方模板引擎——违背 Web Components “原生、轻量、可预测” 的设计初衷
最常被忽略的一点：自定义元素本身不解决“HTML 结构组织”问题。你仍需决定 <my-card> 里要不要用 <slot> 分发内容、是否支持 slot="footer" 命名分发、要不要暴露 getBoundingClientRect() 这类原生方法——这些细节不写进文档，复用时就会卡在“不知道怎么传内容”或“拿不到尺寸”。
