假设你正在维护一个旧版的jQuery项目，页面中有一个动态列表，父容器上绑定了点击事件委托。新插入的行偶尔无法触发回调，控制台没有任何报错。这种问题排查起来相当折磨人，因为表面上选择器、事件绑定语句都写对了。此时如果仅仅盯着业务代码看，很容易忽略jQuery内部在注册事件时悄悄保存的两个属性：selector和context。它们不直接暴露在事件处理函数的参数里，却控制着整个委托流程的匹配与范围。会读这两个属性，很多诡异的交互问题就能快速还原出原因。

事件委托内部的selector属性到底存了什么

jQuery的.on方法支持事件委托语法，比如$('#list').on('click', 'li.item', handler)。这里li.item就是委托选择器。在注册事件时，jQuery并不会在父元素上为每一个未来的子元素绑定事件，而是把选择器字符串连同处理函数一起存入事件数据。你可以通过$._data(element, 'events')查看内部结构。例如在控制台执行下面这段命令，会看到click事件数组中包含selector属性，值正是li.item。

// 绑定委托事件
$('#list').on('click', 'li.item', function(e){
    console.log('clicked', e.target);
});
// 查看内部保存的selector
console.log( $._data($('#list')[0], 'events') );
// 输出结果中类似：
// click: [
//   {
//     type: 'click',
//     selector: 'li.item',   // 这就是selector属性
//     handler: function...
//   }
// ]

这个selector属性在事件触发时被jQuery用来做目标匹配。当一个点击事件从某个li元素冒泡到父元素#list时，jQuery会检查事件源是否匹配selector指定的选择器，匹配成功才执行handler。很多开发者误以为事件委托只跟父元素有关，其实内部的隐式过滤正是依赖这个保存下来的selector字符串。如果selector为空，事件会直接绑定到父元素自身，不再做任何过滤，这会导致所有点击都触发回调。如果selector写错，比如li .item多了一个空格，匹配范围就会完全改变。调试时先打印$._data(parent, 'events')，确认每个事件处理对象中的selector值是否符合预期，往往能直接发现问题。

有一个细节值得注意：在jQuery 1.7之前的版本中，事件对象上还能直接访问到event.selector属性，但后来官方将这个属性从公共事件对象中移除了，避免暴露内部实现。因此现在的调试方式基本都依赖$._data来查看。虽然属于内部API，但排查问题时非常实用。selector属性不仅影响匹配，还会被用于阻止重复触发。例如同一个元素上绑定了多个委托事件，如果selector不同，jQuery会分别判断；如果selector相同且data相同，则会合并处理。这些行为都跟selector属性直接相关。

context属性决定了事件捕获范围

在jQuery的构造函数里，$(selector, context)中的context参数指定了查找DOM的范围。事件委托语法$(parent).on(type, selector, handler)实际上在内部用parent作为context来绑定事件。这个context信息同样被保存在事件数据结构中。在$._data里的每个事件处理对象里，有可能包含一个data字段，而更早的版本里可以直接看到context属性。不过在新一些的jQuery版本中，context属性从jQuery对象上被移除了，但事件绑定时仍然会通过闭包保存父元素引用，也就是event.delegateTarget。

理解context属性的关键在于：它限定了事件冒泡路径上的监听范围。当你写下$('.container').on('click', '.btn', handler)时，context实际上就是.container元素本身。事件必须经过这个context元素才能触发处理函数。如果在代码里动态替换了DOM结构，导致原来绑定的父元素被移除或脱离文档树，即便子元素还存在，委托事件也不会触发，因为冒泡路径不再经过那个context节点。调试时可以输出event.delegateTarget，它返回的正是委托绑定的父元素，相当于内部保留的context引用。看看这个节点是否仍然存在于文档中、是否就是你以为的那个容器，常能发现DOM重构引发的问题。

另一个容易被忽视的场景是嵌套委托。假设外层有一个大容器委托了.item，内层另一个容器委托了.item.active。两个context范围不同，事件触发顺序和匹配结果也不同。如果外层context过大，内层的匹配可能先发生；如果外层context刚好是内层context的祖先，可能会发生两次回调。通过打印event.delegateTarget和event.currentTarget，再结合内部的selector值，就能理清多个委托事件的绑定上下文与匹配顺序。例如下面这段代码分别输出两个关键属性：

$('#outer').on('click', '.item', function(e){
    console.log('delegateTarget:', e.delegateTarget.id);
    console.log('currentTarget:', e.currentTarget.id);
    console.log('target:', e.target.id);
});
$('#inner').on('click', '.item.active', function(e){
    console.log('inner delegateTarget:', e.delegateTarget.id);
});
// 点击 #inner 内的一个带有 active 类的 item 时，
// 观察控制台输出的delegateTarget，可以确认事件经过了哪些context。

需要强调的是，context并不等于event.currentTarget。在委托场景中，currentTarget是指当前正在处理该事件的元素，也就是父元素，而delegateTarget才是委托绑定时记录的context节点。二者在简单的单层委托中相同，但如果在更高层级还有委托，或者手动触发了事件，差异就会显现。因此调试时建议同时输出这两个值，以及event.target，对比三者关系。

一个完整排查案例：从selector和context还原失败原因

来看一个实际开发中可能遇到的Bug。页面有一个表格，行是动态生成的，每行末尾有删除按钮。结构大致如下：一个外层div包裹表格，表格体动态插入tr。开发者这样绑定事件：$('#table-wrapper').on('click', '#data-table tr .delete-btn', function(){...})。运行一段时间后发现，新插入的行里的删除按钮点击没反应。控制台没有错误，事件似乎根本没绑定上去。这时候就可以动用前面提到的方法来排查。

首先在控制台执行$._data($('#table-wrapper')[0], 'events')。展开click数组，检查里面的selector属性。假设输出为#data-table tr .delete-btn。这个选择器看起来没问题，但注意页面中表格容器#data-table可能并不是直接位于#table-wrapper内部，而是经过动态渲染后插入了别的包装层。事件委托的匹配过程是：事件从按钮冒泡到#table-wrapper时，jQuery从事件源向上逐级检查能否匹配selector。由于匹配是在整个文档范围内根据selector查找，如果#data-table这个祖先本身不是按钮的祖先，选择器就无法匹配成功。实际上是动态渲染时，表格id被复用到了错误的位置，或者外层结构变化导致选择器匹配失败。

此时再检查context属性。在事件数据结构中虽然没有直接显示context，但可以通过event.delegateTarget得知绑定时的父元素是#table-wrapper。接着输出event.target，发现target是按钮元素，但event.delegateTarget却是一个已经被替换过的旧节点引用。原来开发者在一次刷新数据时，用innerHTML重新生成了整个#table-wrapper的内容，导致原父元素被移除，新父元素没有绑定事件。旧的事件绑定仍然挂在被移除的节点上，新节点上的按钮点击自然不会触发。解决方法是重新绑定事件，或者使用更上层的稳定父容器。这个案例里，selector和context两个属性的异常表现（selector匹配失败与context节点失效）共同指向了动态DOM替换的问题。

代码层面可以这样复现：

// 初始绑定
var $wrapper = $('#table-wrapper');
$wrapper.on('click', '#data-table tr .delete-btn', function(e){
    console.log('delete clicked');
});
// 打印绑定信息
console.log($._data($wrapper[0], 'events').click[0].selector); 
// 输出: #data-table tr .delete-btn
// 模拟动态刷新，替换整个wrapper内容
$wrapper.html('<table id="data-table"><tr><td><button class="delete-btn">删除</button></td></tr></table>');
// 再次点击按钮，不会触发
// 点击时 e.delegateTarget 是旧引用，已不在文档中

调试这样的问题时，不要只盯着选择器是否正确，还要确认保存的context引用是否依然有效。很多前端框架早期用jQuery做事件绑定，在路由切换或局部刷新时容易遗留这种失效绑定。

selector与context在性能调优中的意义

除了定位Bug，理解这两个属性还能帮助优化事件委托的性能。selector属性越复杂，jQuery在每次事件触发时执行匹配的开销就越大。复杂的CSS选择器如div.list > ul > li:not(.disabled) a会让每个冒泡上来的事件都经过一次$.find.matchesSelector，在低端设备或高频触发事件（如mousemove、scroll）上可能造成卡顿。此时通过$._data查看selector，可以评估是否过于复杂，是否能用类名或数据属性简化匹配逻辑。

context属性则决定了事件绑定的粒度。如果在一个很大的父容器上绑定了委托事件，每一次内部子元素的事件冒泡都会经过这个父容器，jQuery都需要检查一次selector。合理缩小context范围，比如把事件绑定到更接近动态元素的中间容器上，可以减少无关的事件冒泡处理。不过也要注意，context过小可能导致动态元素在context之外生成而无法触发。调试时打印每一个委托事件的selector和delegateTarget，画出事件传播范围，能直观地发现哪些绑定对象承担了过多的匹配压力。

另外，jQuery内部在事件触发时会根据event.target和传入的selector进行matchesSelector判断，如果selector以ID开头，性能会好很多。如果selector只包含类名，还会涉及遍历。这些优化细节都跟selector属性直接相关。养成在性能排查时查看$._data(element, 'events')的习惯，可以让你对页面上的事件绑定数量、委托范围以及选择器复杂度一目了然。

总之，selector和context虽然被封装在jQuery内部，但它们决定了事件委托的核心行为。调试时不要只依赖console.log打印事件对象，还要主动查看绑定数据里的这两个属性，配合target、currentTarget、delegateTarget一起分析。无论面对动态元素不响应、事件重复触发还是性能问题，从这些内部属性入手，往往能比盲目检查业务代码更快地定位根因。