connectedCallback 仅在元素首次挂载到主 DOM 树时触发，attributeChangedCallback 需显式声明 observedAttributes 且仅响应 attribute 变更；disconnectedCallback 是清理资源的确定时机但不保证总执行，所有回调中禁止使用 async/await。
connectedCallback 不是“写了就执行”，attributeChangedCallback 也不是“改了就回调”——它们的触发完全依赖浏览器对 DOM 树的操作，且必须满足严格前提。
connectedCallback 为什么没执行？
它只在元素**首次真正挂载到 document 的主 DOM 树**时调用，不是标签一写就触发，也不是 new 实例就运行。
- 静态 HTML 中的
<my-input></my-input>只有在页面解析完成、该节点被插入主文档后才触发 - 动态创建：
document.createElement('my-input')后必须紧接着parent.appendChild(el)，否则不触发 -
innerHTML = '<my-input></my-input>'或 React/Vue 渲染时，若框架未走原生appendChild路径，也可能跳过该回调 - Shadow DOM 内部
appendChild该自定义元素，不会触发父文档的connectedCallback
attributeChangedCallback 怎么监听才生效？
这个回调完全不自动，必须靠 observedAttributes 显式声明，且只响应 attribute 级变更（不是 property）。
- 静态 getter 必须返回字符串数组：
static get observedAttributes() { return ['data-value', 'disabled']; } - 属性名必须和 HTML 中写的完全一致：
data-user-id→ 监听'data-user-id'，不能写成'userId'或'user-id' -
this.value = 'abc'是 property 赋值，不触发；得用this.setAttribute('data-value', 'abc')或初始 HTML 属性 - 首次渲染时的属性值不会进这个回调（
oldValue是null），初始化逻辑仍要放在connectedCallback里兜底
disconnectedCallback 能不能当“最后保险”？
它是清理资源的唯一确定时机，但浏览器不保证总执行——页面刷新、tab 关闭、后台进程被杀时可能直接跳过。
立即学习“前端免费学习笔记（深入）”；
- 所有定时器必须在这里
clearTimeout()/clearInterval()，但也要加 fallback：比如用AbortController.signal控制fetch，避免请求悬停 - 别在里面做关键持久化操作（如写
localStorage），也不该访问已脱离 DOM 的节点（this.parentNode可能为null） - 清理前建议加 guard 判断：
if (this._timer) clearInterval(this._timer)，防止重复调用出错
最容易被忽略的是：所有生命周期回调里都不能用 async/await；constructor 中不能操作 DOM（此时 this.shadowRoot 还是 null）；而 adoptedCallback 日常几乎用不到，除非你正在处理跨 <iframe> 的元素迁移。
