关键在避免每次变更都触发完整 layout + paint 流程：禁用 attributeChangedCallback 中直接重写 shadowRoot.innerHTML，改用轻量 diff 渲染；用 shouldUpdate 拦截无效更新；批量属性变更后统一 requestUpdate；慎用 mode: 'closed' 和动态注入 style。
频繁更新 HTML 组件时，卡顿、内存泄漏、样式错乱不是“组件写得不够好”，而是 DOM 更新路径没被收束——关键在避免每次变更都触发完整 layout + paint 流程。
避免在 attributeChangedCallback 中直接重写 shadowRoot.innerHTML
这是最常见也最伤性能的写法。属性变一次，整个 Shadow Tree 就销毁重建一次，事件监听器全丢，样式重新计算，布局重跑。
- 错误做法：
this.shadowRoot.innerHTML = template(this.foo, this.bar)放在attributeChangedCallback里 - 正确做法：用
render()配合轻量 diff（如 Lit 的html模板），只更新变化的文本、class 或 dataset - 若必须字符串渲染，先用
document.createDocumentFragment()组装好节点，再一次性appendChild()到shadowRoot，而非循环插入 - 注意：
innerHTML = ''后再赋新值，等价于两次销毁重建；应直接替换内容，而不是清空再填
用 shouldUpdate 拦截无效更新（LitElement 场景）
不是所有属性变更都需要重绘 UI。比如 loading 状态只影响 class，error 只控制一个 <span> 显示，没必要重走整个 render 流程。
-
shouldUpdate在render前调用，返回false可跳过本次更新 - 检查变更项用
changedProperties.has('loading')，别用'loading' in changedProperties或changedProperties.loading !== undefined - 禁止在
shouldUpdate里发请求、改 state、调用this.dispatchEvent——它可能被跳过或多次调用 - 适合场景：仅视觉反馈类属性（
disabled、valid、focused）或不影响结构的数据字段
批量属性变更后统一调用 requestUpdate()
连续赋值多个响应式属性（如表单重置），默认会触发多次更新队列，导致多次 diff + patch + 渲染。
立即学习“前端免费学习笔记（深入）”；
- 错误写法：
this.value = ''; this.error = ''; this.touched = false;→ 默认三次更新 - 正确写法：赋值完立刻
this.requestUpdate()，Lit 会合并为一次 update 周期 - 不依赖框架时，可用
Promise.resolve().then(() => { /* 批量操作 */ })或requestAnimationFrame推迟到下一帧统一处理 - 注意：不要在
requestUpdate()后立即读取shadowRoot节点——它尚未完成 patch，需等updateCompletePromise
慎用 mode: 'closed' 和动态注入 <style>
mode: 'closed' 看似增强封装，实则切断调试链路，更致命的是它让组件无法复用 shadowRoot 引用，每次都要新建整个 Shadow Tree。
- 动态注入
<style>（如通过document.createElement('style')插入）在mode: 'closed'下会失败，且无法被缓存 - 主题切换类需求，优先用 CSS 变量（
--theme-color）+ class 切换，而非拼接 style 字符串 - 若必须注入样式，应在
constructor或connectedCallback中一次性完成，避免在更新钩子里反复创建/移除<style>标签 - 真实代价：每秒 10 次
mode: 'closed'组件创建，在低端安卓机上 layout 时间可飙升 4 倍以上
真正难的不是“怎么更新”，而是判断“这次值变了，但用户真的需要看到变化吗”——多数卡顿来自对变更必要性的误判，而非技术选型。
