connectedcallback仅在元素首次真正挂载到主dom树时触发，非静态定义即执行，也非每次appendchild都调用；常见错误是误判插入时机或未满足挂载条件。
connectedCallback 只在元素首次插入 active DOM 时执行，不是写在 HTML 里就立刻运行，也不是每次 appendChild() 都触发。
为什么 connectedCallback 没有被调用？
常见错误是误以为只要定义了标签、写了 HTML，回调就会自动执行。实际触发条件非常明确：
- 元素必须已实例化且**真正挂载进 document 的主 DOM 树**（不是 Shadow DOM 内部，也不是未 append 的节点）
- 静态 HTML 中的
<my-element></my-element>在解析完成并插入后触发 - 动态创建时：
document.createElement('my-element')不会触发；必须紧接着parent.appendChild(el) - 重复移除再添加：只在“首次连接”时调用，后续
appendChild()不再触发 -
constructor里不能操作 DOM，此时元素可能还没挂载，this.shadowRoot为null
attributeChangedCallback 怎么监听才生效？
它不会自动响应任意属性变更，必须配合 observedAttributes 静态 getter，否则改了也白改。
- 必须返回字符串数组，如
static get observedAttributes() { return ['size', 'theme']; } - 属性名严格区分大小写，HTML 中写
data-id="123"，就必须写'data-id'，不能简写或驼峰 - 仅响应 attribute 级别变更：通过
el.setAttribute('size', 'large')或 HTML 解析触发；直接赋值el.size = 'large'是 property 操作，不触发 - 回调参数固定为
(attrName, oldValue, newValue)，首次设置时oldValue是null - 若需同步 property 和 attribute，得自己在 setter 里手动调用
setAttribute()
disconnectedCallback 是清理资源的唯一机会，但不保险
它是你释放事件监听器、清除定时器、取消 fetch 请求的最后确定时机 —— 但浏览器不保证它一定执行。
- 页面刷新、强制关闭标签页、进程崩溃等场景下，
disconnectedCallback可能完全不运行 - 不要在里面做关键数据持久化（比如 localStorage 写入），应提前或双保险处理
- 清理逻辑要幂等：同一元素可能被多次
removeChild()，但disconnectedCallback最多执行一次；不过仍建议加 guard 判断（如检查 timer 是否存在） - 避免在其中访问
document或其他 DOM 节点，此时元素已脱离 DOM，部分引用可能失效
adoptedCallback 基本只在 iframe 场景下有用
日常开发几乎遇不到，除非你明确需要跨文档迁移自定义元素（比如把一个组件从主页面拖进 <iframe></iframe>）。
- 触发条件苛刻：元素先从原 document 移除，再被
adoptNode()进新 document - 典型场景：富文本编辑器中嵌入可拖拽的 widget，或微前端子应用跨 iframe 注册组件
- 大多数项目可直接忽略，不定义也不会影响其他生命周期
- 如果真要用，注意样式重置和事件代理可能需要重新绑定，因为新 document 的全局环境不同
最容易被忽略的是 connectedCallback 和 attributeChangedCallback 的触发边界 —— 它们不是“DOM 变了就回调”，而是由浏览器在特定树挂载/属性变更路径上精确派发。写错 observedAttributes 或误判插入时机，会导致整个响应链静默失效，且无报错提示。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
