应选最近的静态父容器（如id="search-results"的div），避免document/window；优先用data-action精确匹配；input防抖需按场景设延迟并避开组合输入；shadow dom需优化js执行与布局读写；动态元素须确保父容器存在且不被replacewith替换。
事件委托怎么选父容器才不拖慢性能
别把监听器挂到 document 或 window 上——冒泡路径太长，浏览器得逐层检查每个祖先节点是否匹配，尤其在深层嵌套 DOM 中会明显卡顿。父容器要选“最近的静态包裹元素”，比如一个带 id="search-results" 的 <div>，而不是整个 <code>。
常见错误是：列表渲染后用 document.addEventListener('click', ...) 处理所有按钮，结果每次点击都要从 html 根节点开始冒泡。换成 document.getElementById('search-results').addEventListener('click', ...)，冒泡提前终止，性能提升立竿见影。
- 父容器必须在页面加载时就存在，不能是后续用
innerHTML动态插入的 - 避免用 class 名模糊匹配（如
.item），优先用data-action属性做精确判断：e.target.matches('button[data-action="remove"]') - 如果父容器本身可能被
replaceWith()替换，监听器就失效了，得重新绑定；但用innerHTML重写内容不影响委托
input 事件要不要加防抖，取决于什么
input 事件确实实时，但不是所有场景都适合“每敲一个字就发请求”。高频触发会导致接口被打爆、UI 卡顿、甚至输入法组合状态被干扰（比如中文拼音还没选完，input 就先触发了）。
真正该防抖的，是那些触发开销大的操作：调用 API、更新复杂视图、触发 layout 强制重排。而纯本地校验、字数统计这类轻量逻辑，直接响应反而更顺滑。
- 中文输入场景下，得配合
compositionstart和compositionend判断是否处于选词中，只在compositionend后或非组合状态下才执行防抖逻辑 - 防抖延迟别设成统一 300ms——搜索建议可以 200ms，表单验证可放宽到 500ms，避免用户觉得“卡”
- 别在防抖函数里反复读写布局属性（如
el.offsetHeight），否则防抖反而加重卡顿
Shadow DOM 里事件响应还是慢，问题出在哪
用了 attachShadow 不等于自动变快。Shadow DOM 只隔离样式和 DOM 范围，不解决 JS 执行效率或布局抖动问题。很多组件卡顿，是因为在 click 回调里做了不该做的事。
典型陷阱：监听 slotchange 后立刻遍历所有 assignedNodes() 并计算尺寸；或者在事件里同步修改多个元素的 style 再马上读取 getBoundingClientRect() ——这会强制浏览器同步重排。
- 给 shadowRoot 的根容器加
contain: strictCSS，明确限定重绘边界 - 避免在事件回调中交替读写布局属性，把读操作集中、写操作批量合并
- slot 内容变更不会自动重渲染，依赖 slot 变化更新 UI 时，要用
requestIdleCallback延后处理，别堵住主线程
动态创建的元素，事件监听器为什么第一次点没反应
根本原因不是“没绑上”，而是绑早了——DOM 节点还没插入文档，addEventListener 对象是 null，静默失败。或者监听器绑在旧节点上，新节点重建后旧监听器自然失效。
最稳妥的做法是：事件委托 + 父容器静态存在。只要父容器没被 replaceWith() 替换，哪怕子元素删光重画，监听器始终有效。
- 别在循环里对每个新
button单独调用addEventListener，尤其是异步渲染后补绑 - 如果非得直接绑定，确保节点已挂载：用
el.isConnected判断，或等requestAnimationFrame下一帧再绑 - 用
{ once: true }选项处理一次性动作（如初始化确认），避免手动清理遗漏
