事件委托的原理依赖于事件冒泡，可以通过给父元素的事件委托来确定是哪个子元素触发了事件从而做一系列操作。
使用事件委托的优点
1、操作子元素时不用一一遍历，可以根据事件触发的对象而进行相应操作
dom结构如下：
<ul id = "oUl">
<li class = "item"></li>
<li class = "item"></li>
<li class = "item"></li>
<li class = "item"></li>
<li class = "item"></li>
</ul>
当li被点击时，打印该li的值。
在我们还没有学事件委托的时候我们会遍历所有li并给它们添加一个click事件，比如这样：
var aLi = document.getElementsByTagName('li');
for(var i = 0; i < aLi.length; i++) // 遍历li
aLi[i].addEventListener('click', function() { //给每个li添加事件
console.log(this.innerHTML);
});
学了事件委托之后js原生代码如下：
var oUl = document.getElementById('oUl');
oUl.addEventListener('click', function(ev) {
ev = ev||window.event;
var tag = ev.target; // 触发事件的对象保存在事件的target里面
console.log(tag.innerHTML);
})
jQuery代码如下：
$('#oUl').on('click', '.item', function() {
console.log($(this).html()); // this指向oUl中触发了click事件并且class
为item的子元素
})
相比之下，事件委托只需要获取父元素并且不需要遍历li，效率提高了不少。
2、将事件委托给父元素后，动态创建（删除）的子元素不用重新绑定（解绑）事件，实现了元素与事件的同步更新
在以往的js事件监听中，用js动态创建的子元素是没有事件的，必须重新为它们绑定事件，但是用事件委托就不用这么麻烦了，不需要重新绑定事件依旧可以实现事件监听。
当然事件绑定也是有弊端的，因为它依赖于事件冒泡，如果不支持冒泡那么就不能实现事件绑定了，不过我认为这种几率还是不高的。还有就是会发生事件误判，比如页面中的button1和button2的作用是点击时弹出值，而button3的作用是点击是页面变色，这三个button的同一个事件实现功能不同，当你将click事件委托给它们共同的父元素那么就会出现事件误判。
所以我认为事件委托是发生在一个子集合的事件功能相同的情况下，如果不相同则不要使用事件委托，以免弄巧成拙。
在实际开发中，掌握事件绑定对于代码的规范性以及效率会有一定提高，总的来说利大于弊。
