很多人是在使用事件委托的，那對于一個使用者來說，只要能正確的使用好事件委托，完成工作，就算可以了，那么你有認真的考慮過事件委托的原理，以及你的使用場景是否適合使用事件委托呢，如果需要使用事件委托，那么你是否有正確的使用呢？這里我想簡單的說一下我對事件委托的理解，希望可以有機會多多交流。
概述
事件委托有哪些好處，才會被現在人們大量的使用呢？
那么就得先說說事件的一些性能和使用的問題：
1：綁定事件越多，瀏覽器內存占用越大，嚴重影響性能。
2：ajax的出現，局部刷新的盛行，導致每次加載完，都要重新綁定事件
3：部分瀏覽器移除元素時，綁定的事件并沒有被及時移除，導致的內存泄漏，嚴重影響性能
4：大部分ajax局部刷新的，只是顯示的數據，而操作卻是大部分相同的，重復綁定，會導致代碼的耦合性過大，嚴重影響后期的維護。
這些個限制，都是直接給元素事件綁定帶來的問題，所以經過了一些前輩的總結試驗，也就有了事件委托這個解決方案。
我們本篇將要說的是，事件委托。
事件委托的基礎
如果我們相對一個技術點了解的更深，用的更好，那么我們就需要對這個技術點的原理有更多的了解，那么事件委托的實現原理是什么呢？
1：事件的冒泡，所以才可以在父元素來監聽子元素觸發的事件。
2：DOM的遍歷，一個父級元素包含的子元素過多，那么當一個事件被觸發時，是否觸發了某一種類型的元素呢？
這是事件委托的兩個基礎，也是事件委托的核心，跟事件委托相關的技術點，如果碰到什么問題，都可以在這兩個點進行切入，來尋求解決方案。
而且還有一點要注意：不管你使用什么樣的框架，實現方案，這兩個基礎都是必須的，OK，我們繼續看下去。
一個簡單的事件委托
只是使用文字描述，是無法很好的理解事件委托的，那么這里我們來看一個例子：
注：假設只支持標準瀏覽器，不兼容IE的低版本
我現在使用原生的JS，來實現一個簡單的事件委托
然后，可以直接這么調用：_delegate(document.body,"item",fn);
它執行的效果是：body內部，所有class包含item的元素，都會相應該操作。
注：該方法是為了說明這個原理，并不是用于生產開發中的，如果想要用在生產開發中，那么實現方式應該更嚴謹，一些必要的類型檢測，還是需要的。
