stopPropagation用于阻止事件冒泡但不影响捕获和其他监听器，应在存在副作用风险时谨慎使用；优先采用事件委托+target判断，区分preventDefault，必要时用CSS pointer-events替代。
stopPropagation 用于阻止事件向父元素冒泡，不阻止当前元素上的其他监听器执行，也不影响事件捕获阶段。它最规范的用法是：在明确需要“隔离事件作用范围”时调用，且只在事件处理函数内部、有实际冒泡干扰风险的地方使用。
只在必要时调用，避免过度使用
不是每个点击都要 stopPropagation。比如表单内按钮点击本该触发父容器的折叠逻辑，你却加了 stopPropagation，就破坏了预期行为。只有当父级监听器会引发副作用（如意外关闭弹窗、重复提交、误触菜单收起）时才考虑它。
- 常见合理场景：模态框内的按钮点击、下拉菜单项点击、自定义滚动容器内的点击
- 反模式：给所有按钮统一加 stopPropagation、在委托事件里无条件调用
优先用事件委托 + target 判断，而非依赖 stopPropagation
比起在子元素里层层 stopPropagation，更健壮的做法是把事件监听绑定在父级，通过 event.target 或 event.currentTarget 精准判断来源。
- 例：菜单容器监听 click，用
if (e.target.matches('.menu-item')) { ... }处理，不干扰外部点击 - 这样既避免冒泡干扰，又保留父容器对其他区域的响应能力
注意与 preventDefault 的区别，别混用
stopPropagation 只管传播路径，preventDefault 只管默认行为（如链接跳转、表单提交）。两者互不影响，但常被一起使用：
立即学习“Java免费学习笔记（深入）”；
- 点击按钮阻止表单提交 → 用
e.preventDefault() - 点击按钮同时防止父容器监听器执行 → 再加
e.stopPropagation() - 错误写法：
e.stopImmediatePropagation()会直接终止同一阶段其他监听器，除非真要“独占事件”，否则不用
现代替代思路：CSS pointer-events 或语义化结构
有些场景其实不需要 JS 阻止冒泡。例如遮罩层上放按钮，可让遮罩本身不响应点击：
- CSS：
.overlay { pointer-events: none; }，按钮设pointer-events: auto; - 或用语义化 HTML 结构，让交互区域天然不重叠（如按钮不在可折叠容器内部）
- 这类方案更轻量、更易维护，也规避了事件流管理的复杂性
