事件冒泡本身不导致白屏卡顿，但在document全局监听器中执行低效操作（如强制布局、频繁dom修改、未优化循环）会阻塞主线程；应仅做轻量分流，用事件委托、节流、分片等策略优化。
事件冒泡本身不会直接导致白屏或卡顿，但在全局 document 上绑定监听器时，若处理逻辑低效、触发频繁或存在隐式重排，就容易拖慢主线程，造成视觉停滞或响应延迟。
全局监听器放大低效操作的负面影响
把事件监听器挂到 document 上，意味着所有点击、输入、滚动等事件都会经过它。哪怕只是简单判断 e.target，只要页面元素多、交互密（比如富文本编辑、表格拖拽、高频按钮），每秒可能触发几十甚至上百次回调。
- 每次回调里执行
getBoundingClientRect()、offsetHeight或反复查querySelector，会强制浏览器同步计算布局，引发“布局抖动” - 在回调中动态修改大量 DOM（如高亮匹配项、实时过滤列表），又没做批量或节流，等于在每一帧内反复触发重排重绘
- 监听器内部有未优化的循环（如遍历所有
.menu-item判断是否被点中），数据量一大，JS 执行时间就拉长，渲染线程被持续阻塞
避免在 document 级监听器里做耗时同步操作
全局监听的本质是“守门人”，职责应是快速分流，而不是现场干活。
- 只做轻量判断：用
e.target.matches('.btn-save')替代e.target.classList.contains('btn-save')，更快更安全 - 不直接操作 DOM：点击保存按钮后，不要在监听器里拼 HTML、appendChild；而是发个信号（如
dispatchEvent(new CustomEvent('save'))），由专门模块处理 - 对高频事件（如
mousemove、scroll）绝不挂 document —— 改用requestAnimationFrame节流，或委托到具体容器
用委托+局部作用域替代 document 全局监听
绝大多数场景根本不需要 document 级监听。真正需要它的，只有极少数跨区域行为（如全局快捷键、模态框外点击关闭）。
- 菜单栏？监听
#header容器就够了 - 商品列表？绑定在
.product-list上，子项增删也不用重绑 - 表单字段？用
form.addEventListener('input', ...)，靠事件冒泡捕获所有输入，比每个input单独绑省资源
必要时加防抖或分片执行
如果确实要在 document 监听并执行较重逻辑（例如根据点击位置动态加载浮层），别让它“一口吃成胖子”。
- 用
setTimeout(..., 0)或queueMicrotask把 DOM 更新延后，让当前帧先完成渲染 - 涉及大批量节点操作（如高亮搜索结果），拆成每帧处理 20 个，用
requestIdleCallback或手动分片控制节奏 - 避免在回调里调用
location.reload()、alert()或同步 AJAX，这些会彻底冻结 UI
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
