很多人是在使用事件委托的，那对于一个使用者来说，只要能正确的使用好事件委托，完成工作，就算可以了，那么你有认真的考虑过事件委托的原理，以及你的使用场景是否适合使用事件委托呢，如果需要使用事件委托，那么你是否有正确的使用呢？这里我想简单的说一下我对事件委托的理解，希望可以有机会多多交流。
概述
事件委托有哪些好处，才会被现在人们大量的使用呢？
那么就得先说说事件的一些性能和使用的问题：
1：绑定事件越多，浏览器内存占用越大，严重影响性能。
2：ajax的出现，局部刷新的盛行，导致每次加载完，都要重新绑定事件
3：部分浏览器移除元素时，绑定的事件并没有被及时移除，导致的内存泄漏，严重影响性能
4：大部分ajax局部刷新的，只是显示的数据，而操作却是大部分相同的，重复绑定，会导致代码的耦合性过大，严重影响后期的维护。
这些个限制，都是直接给元素事件绑定带来的问题，所以经过了一些前辈的总结试验，也就有了事件委托这个解决方案。
我们本篇将要说的是，事件委托。
事件委托的基础
如果我们相对一个技术点了解的更深，用的更好，那么我们就需要对这个技术点的原理有更多的了解，那么事件委托的实现原理是什么呢？
1：事件的冒泡，所以才可以在父元素来监听子元素触发的事件。
2：DOM的遍历，一个父级元素包含的子元素过多，那么当一个事件被触发时，是否触发了某一种类型的元素呢？
这是事件委托的两个基础，也是事件委托的核心，跟事件委托相关的技术点，如果碰到什么问题，都可以在这两个点进行切入，来寻求解决方案。
而且还有一点要注意：不管你使用什么样的框架，实现方案，这两个基础都是必须的，OK，我们继续看下去。
一个简单的事件委托
只是使用文字描述，是无法很好的理解事件委托的，那么这里我们来看一个例子：
注：假设只支持标准浏览器，不兼容IE的低版本
我现在使用原生的JS，来实现一个简单的事件委托
然后，可以直接这么调用：_delegate(document.body,"item",fn);
它执行的效果是：body内部，所有class包含item的元素，都会相应该操作。
注：该方法是为了说明这个原理，并不是用于生产开发中的，如果想要用在生产开发中，那么实现方式应该更严谨，一些必要的类型检测，还是需要的。
