JavaScript事件模型：像快递派送一样读懂网页交互

可视化演示

事件流三阶段

快递派送的完整旅程其实分成三段：包裹从城市配送中心出发，经各区分拨站一路下沉到你所在的小区；骑手把包裹送到你手上；你签收后，回执信息又逐级传回配送中心。这三段缺一不可，构成了快递配送的完整闭环。浏览器的事件，走的也是这条“三段式”路线。

当你点击页面上一个按钮，浏览器不会把“点击”这件事直接丢给按钮，而是从最顶层的 window 对象出发，沿着 DOM 树逐级下沉，经过 document、html、body 等祖先节点，最终到达你点中的元素。这条下沉链路叫捕获阶段；到达目标元素的那一瞬间叫目标阶段；随后事件又调头向上、沿原路逐级传回 window，这条上浮链路叫冒泡阶段。

完整的事件流路径是：window → document → html → body → …… → 目标元素 → …… → body → html → document → window。监听事件最常用的 addEventListener 默认在冒泡阶段触发，因为此时事件已经从目标元素“回传”到了监听器所在的祖先节点；想在捕获阶段提前“截取”事件，就把第三个参数设为 true。

回到快递的比喻：捕获阶段像配送中心逐级发货，目标阶段像骑手当面签收，冒泡阶段像回执单逐级传回。浏览器里的每一次点击，都严格走完这三段旅程，无论中间隔着多少层“中转站”。

冒泡与捕获

为什么快递回执要一级一级往回传，而不是骑手直接打电话给配送中心？因为每一级中转站都需要留个记录——包裹经过谁、谁经手的，出了问题才知道去哪查。冒泡正是这样：事件一层层往上走，让沿途每个祖先节点都有机会“看一眼”。

捕获与冒泡是一对方向相反的传播过程。捕获是“自上而下”：从 window 到目标元素，像快递发货时的逐级下拨；冒泡是“自下而上”：从目标元素回到 window，像回执单的逐级回传。两者会经过同一批祖先节点，只是顺序完全相反。

用 addEventListener 监听时，第三个参数是决定方向的开关：false（默认）表示在冒泡阶段触发，true 表示在捕获阶段触发。同一个祖先元素如果同时注册了 true 和 false 两个监听器，捕获阶段先执行前者，冒泡阶段再执行后者。要注意：目标阶段本身没有“捕获/冒泡”之分，不管参数是什么，目标元素上的监听器都会在事件到达时触发。

拿着回执单逐级登记是冒泡，拿着派送单逐级下拨是捕获。方向相反，目的相同——让每一级祖先都有机会响应。理解这对“顺水”与“逆水”的关系，你就拿到了阅读事件传播的第一把钥匙。

阻止事件行为

快递路上可能发生两种“意外”：一是某级中转站发现包裹不该继续往下派，直接拦下退回；二是收件人坚决拒收，包裹被原路退回。前者是“拦截”，后者是“拒收”，看起来都让包裹停了，但原因完全不同。事件模型里恰好有两个 API 对应这两种情况。

stopPropagation 负责“拦截”：调用后，事件立即停止继续传播，后面无论还有多少层祖先，都再也收不到它。preventDefault 负责“拒收”：它不管事件传不传，只是阻止浏览器对这个事件的默认动作——比如链接的跳转、表单的提交、复选框的勾选。

两者可以同时调用，互不影响：stopPropagation 管的是“事件这条路还走不走”，preventDefault 管的是“浏览器固有的行为做不做”。典型场景：表单校验不通过时用 preventDefault 阻止提交，同时用 stopPropagation 防止事件冒泡到 document 触发全局逻辑。注意，老代码里的 return false 在不同场景下行为并不一致，现代推荐显式调用这两个 API。

中转站拦截的是“包裹的行程”，收件人拒收的是“签收动作本身”。记住这组对照，面试中再被问“二者区别”，你就能四两拨千斤。

事件委托

整栋楼每天几十个快递，如果每家每户门口都雇一个签收员，成本高得离谱。物业想了个聪明的办法：在小区门口设一个统一代收点，由物业统一签收，再根据每家每户的门牌号分发。新搬来的住户不用安装任何设备，自动就能享受代收服务。

事件委托就是这种“物业代收”思想。与其给每个子元素都绑一个监听器，不如把监听器统一绑在它们共同的祖先上。当子元素被点击，事件冒泡到祖先时，祖先的监听器统一处理，再通过 event.target 判断“到底是哪家住户的件”。

事件委托的两个核心收益：一是监听器数量从 N 个降到 1 个，内存占用和初始化开销大幅减少；二是对动态增删的元素天然友好——新增的子元素不需要重新绑定，因为处理逻辑在祖先上。判断具体元素时，用 e.target 检查 tagName 或 classList 即可。经典实战：给 ul 绑定点击监听，用 e.target 判断是否点中了某个 li，再执行对应操作。

物业代收点不会替每户装新设备，祖先监听器也不会为每个新节点绑新函数。这套“找人代收”的智慧，正是事件委托在大规模列表、动态渲染场景里长盛不衰的原因。

自定义事件

快递系统只管“送货—签收”这一件事，可小区居民想搞读书会、跳蚤市场，这些不在快递业务范围内。怎么办？大家自己约定暗号：“谁想参加，就在楼下公告栏贴一张红色纸条。”这套自创的流程，不经过任何官方中转站。

自定义事件就是前端世界的“自创暗号”。浏览器内置了 click、scroll 等事件，但业务中经常需要“加载完成”“数据更新”“用户登录”这些语义化信号。用 new CustomEvent 创建事件，用 dispatchEvent 分发出去，再用 addEventListener 监听——完全复用事件模型一套体系，表达的却是你自己的业务语义。

创建自定义事件推荐 new CustomEvent(type, { detail: data })，detail 可以携带任意业务数据，监听器里通过 e.detail 读取。想让自定义事件也能冒泡、被委托，就在配置里加 bubbles: true。dispatchEvent 是同步调用的，监听器会在这一行执行完毕后才继续往下走。自定义事件还被广泛用于组件间解耦通信——两个组件不直接引用彼此，而是通过一个公共事件通道对话。

红色纸条是居民自创的“事件”，公告栏是“事件通道”，会议组织者是“监听器”。浏览器允许你完全复刻这套机制，让你的应用拥有和原生事件一模一样的传播能力。

事件对象

每个快递包裹上都贴着快递单：收件人、寄件人、物品、运单号。千万别把“收件人”和“签收点”搞混——包裹上写的是收件人李四，但签收点是小区物业，这两个信息不是一回事。事件对象 event 就是事件的“快递单”。

监听器触发时会自动收到一个 event 参数，上面记录着各种信息：事件类型、触发时间、按键信息等。最容易被混淆的是两个“人”：event.target 是“收件人”——真正触发事件的那个元素；event.currentTarget 是“签收点”——当前正在执行监听器、也就是绑定监听的元素。

在事件委托场景里，监听器绑定在 ul 上、实际点中的是某个 li，此时 e.target 是 li，e.currentTarget 是 ul——两者必然不同。而在非委托、直接在元素上绑监听的场景，两者相同。理解这个区别，调试委托代码时就不会“找不到是哪个元素触发的”。其他常用属性还有 event.type（事件类型）、event.bubbles（是否可冒泡）、event.defaultPrevented（默认行为是否已被阻止）、event.timestamp（触发时间戳）。

看快递单时先分清“寄给谁”和“谁签收”；处理事件时先分清 e.target 和 e.currentTarget。这一份“快递单”上的每个字段，都是你排查交互问题时的线索。

常见踩坑

快递再熟悉也有翻车的时刻：给已搬走的住户门口堆了一堆无人取的件（监听器泄露）；把整栋楼的快递全扔在物业结果没人认领（this 指向错乱）；回执单本身也要走全楼流程，结果每家都以为要自己处理一遍（冒泡干扰）。

事件模型的常见坑集中在这几类：一是内存泄漏——监听器绑定后没有在组件销毁时移除，反复创建销毁组件时监听器越积越多；二是冒泡干扰——子元素和祖先元素都绑了同一事件的监听器，点击子元素却触发了祖先的逻辑；三是 this 指向错乱——普通函数里 this 指向 currentTarget，换成箭头函数后 this 又变成外部作用域，判断错了整个逻辑就变了味。

具体的止血方案：removeEventListener 必须持有原函数引用，addEventListener 和 removeEventListener 要成对出现，匿名函数无法被移除；在顶层节点用 stopPropagation 拦截“多余”的冒泡，或改造结构避免嵌套监听；普通函数里不要依赖 this 判断元素，直接用 e.currentTarget。还有一个隐性坑：同一元素重复注册同名事件，触发时会依次执行，不要误以为“只执行一次”。

快递系统的翻车，总能从“件没送到该到的人手里”归结出原因；事件模型的坑，也总能从“监听器绑了没解、冒泡跑错了层、this 看错了对象”这三条主线里找到答案。

AI 应用场景

Python 演示

"""用 Python 模拟 JavaScript 事件模型的捕获-目标-冒泡传播过程""" class Event:    def __init__(self, etype, target):        self.type = etype        self.target = target        self.propagation_stopped = False        self.default_prevented = False     def stop_propagation(self):        self.propagation_stopped = True     def prevent_default(self):        self.default_prevented = True  class Node:    def __init__(self, name, parent=None):        self.name = name        self.parent = parent        self.capture_listeners = []        self.bubble_listeners = []     def add_listener(self, fn, use_capture=False):        if use_capture:            self.capture_listeners.append(fn)        else:            self.bubble_listeners.append(fn)     def dispatch(self, event):        path = []        node = self        while node:            path.append(node)            node = node.parent         for n in reversed(path):            if event.propagation_stopped:                break            for fn in n.capture_listeners:                fn(event, n)         for n in path:            if event.propagation_stopped:                break            for fn in n.bubble_listeners:                fn(event, n)  def make_handler(label):    def handler(event, current):        role = "目标" if current is event.target else "中间层"        print(f"[{label}] {current.name}({role}) 收到 click, 来源: {event.target.name}")    return handler  def main():    window = Node("window")    document = Node("document", window)    div = Node("div", document)    button = Node("button", div)     window.add_listener(make_handler("捕获"), use_capture=True)    window.add_listener(make_handler("冒泡"))    div.add_listener(make_handler("冒泡"))    button.add_listener(make_handler("自身"))     click = Event("click", target=button)    print("=== 模拟点击 button ===")    button.dispatch(click)     print("\n=== stopPropagation 演示: 在 div 处拦截 ===")    def intercept(event, current):        event.stop_propagation()        print("div 拦截了事件, 不再向上冒泡")    div.add_listener(intercept)    button.dispatch(Event("click", target=button))  if __name__ == "__main__":    main()

1. while node:从触发元素沿 parent 链一路向上收集整条传播路径
2. for n in reversed(path):捕获阶段自上而下遍历路径节点
3. if event.propagation_stopped:stopPropagation 被调用后传播立即中断
4. for n in path:冒泡阶段自下而上遍历路径节点
5. role = "目标" if current is event.target else "中间层"用 target 判断当前节点角色
6. click = Event("click", target=button)构造事件对象，记录触发者
7. button.dispatch(click)从目标元素发起完整的事件传播

常见误区

面试题