在connectedCallback中查不到子元素是因为规范限定该钩子仅保证组件自身挂载，不保证模板解析完成；应使用requestAnimationFrame延后查询，或手动克隆template内容到shadowRoot。
connectedCallback 里查不到子元素怎么办
这是最常被误认为“bug”的行为：在 connectedCallback 中调用 this.shadowRoot.querySelector('button') 返回 null。根本原因不是代码写错，而是规范限定——connectedCallback 只保证组件自身已挂载，不保证内部模板解析或子节点渲染完成。
- 直接延后一帧：用
requestAnimationFrame(() => { /* 查询逻辑 */ })是最轻量、兼容性最好的解法 - 若使用
<template>插入内容，必须在connectedCallback内手动克隆并append到shadowRoot，否则子节点根本不存在 - 别在
constructor里操作 DOM：此时this.shadowRoot一定为null，任何querySelector或innerHTML都会报错
attributeChangedCallback 为什么没触发
写了回调函数却完全没反应？大概率是漏了静态声明。这个钩子不是“监听所有属性”的通用监听器，它必须显式告知浏览器哪些属性值得关注。
- 必须定义
static get observedAttributes() { return ['data-id', 'disabled']; }，且数组内字符串要和 HTML 中的属性名**完全一致**（data-id≠dataId） -
attributeChangedCallback只响应setAttribute()或 HTML 解析时的初始值设置；直接赋值el.disabled = true属于 property 操作，不会触发 -
oldValue和newValue始终是字符串，需自行转换类型，比如Number(newValue)或JSON.parse(newValue)
disconnectedCallback 清理为何有时失效
你写了清理逻辑，但内存泄漏依然发生——因为 disconnectedCallback 不是“必达”钩子。浏览器只在元素被正常移出 DOM 时调用它，而强制关闭标签页、进程崩溃、系统杀进程等场景下，这个钩子会被跳过。
- 不能在里面做关键持久化操作，比如
localStorage.setItem()期望保存状态 - 清理前务必加 guard：如
if (this._timer) clearInterval(this._timer)，避免对已销毁引用操作 - 对重要副作用（如未完成上传），建议额外在
beforeunload事件中做轻量兜底 - 别在清理逻辑里访问
document或已脱离 DOM 的节点，引用可能已失效
slot 内容只出现在第一个位置是 bug 吗
不是 bug，是 Web Components 规范行为：slot 内容被**移动**而非复制。多个同名 <slot name="icon"></slot> 不会分别渲染，而是把内容节点移到第一个匹配 slot 的位置。
立即学习“前端免费学习笔记（深入）”；
- 若需多处复用同一图标，改用
@Input()（Angular）或 props（React/Vue）传入 SVG 字符串，再由组件内用innerHTML插入（注意 XSS 风险） - 或在 JS 中用
cloneNode(true)手动克隆节点，然后分别 append 到不同 slot 容器 - 避免依赖 slot 分发做条件渲染，容易因节点移动导致逻辑错位
真实场景里，冲突往往不是单一钩子的问题，而是多个生命周期阶段之间的时间差和职责错配。比如在 connectedCallback 发起请求，又在 attributeChangedCallback 里重复触发，再叠加 disconnectedCallback 没清定时器——三者叠加，泄漏和错乱就藏不住了。
