昨天和我們可愛的後端架構師在爭論這個問題，我很多ui元件中大量使用了jquery live進行事件繫結，眾所周知它最直觀的好處在於可以一直「監聽」我們操作，對於新增的dom節點也會有效，而不需要重新繫結。也許是因為這個「監聽」讓我們很多人聯想到他會不斷的去繫結、判斷，會造成效能問題，這也是他給我的意見，真的是這樣嗎？
在我開始認識live之前，我也看過網上很多文章說live會降低效能，昨天架構師也給我這麼一篇：《jquery效能優化指南》，此文說到live上完全就是避重就輕，原因都還沒談直接給出定結論——「雖然我把繫結事件重新寫了一次，**多了點，但這種方式的效率明顯高於live()方式，特別是在頻繁的dom操作中，這點非常明顯。」，鄙視之。
在此之前，我認為我這篇文章是毫無意義的，因為live是類似於繫結父節點，去監聽子節點產生的冒泡才去執行相應的事件，這種**的好處幾乎已經得到js程式設計哥公認了。可是前端面對環境的問題往往要比後端複雜，這也是前端經常需要與人分享的原因，通過前端工程師不斷的積累讓很多瀏覽器的問題明朗起來，讓彼此避免陷入泥潭中。理論上的爭執永遠比不過乙個實測來得直觀。下面是我對live與普通繫結的記憶體占用測試：
環境：ie8。 工具：sieve。 jquery:1.42
普通方式：
jquery(function($);
$('#test').html(newli);
$('#test a').click(function());
});
live **方式：
jquery(function($);
$('#test').html(newli);
$('#test a').live('click', function());
});
從結果可以得知在記憶體消耗方面live幾乎完勝（執行效率與這個無關）。總之繫結6000次與繫結1次的區別還是比較大的。
前段時間我也淺淺的閱讀了jquery的原始碼，也曾經嘗試寫過自己的微型dom引擎，因為我認為解決jquery常用的方法可以控制在8kb之內，後來在處理事件機制的時候才知道這個是無法「微型」，無法自動處理記憶體洩漏，所以jquery原始碼中有一大片地方是給事件機制的，在1.42原始碼中竟然達到了1069行！
了解jquery應該從他實現的原理開始，也可以自己嘗試寫dom操作引擎，看別人造輪子與自己造輪子都會讓一切將明朗起來！
事件**機制擴充套件閱讀：
jquery繫結事件以及js繫結事件
jquery繫結事件 bind事件 onelive delegate on對應的 jquery繫結click事件的寫法start click1 bind click function click2 one click function click3 live click function click...
事件處理 on 繫結事件
on 方法在匹配元素上繫結乙個或者多個事件處理函式 element.on events,selector fn 發生多個事件的話 div on click function mouseout function 發生事件發生同樣的操作的話 div on mouseover mouseout funct...
JQuery 事件繫結，移除繫結
bind 隱式迭代,為匹配到的元素繫結相同的事件。selector bind event,func 繫結匿名函式 div p bind click function 繫結指定函式 div p bind click funcname params 繫結click事件 div p click funct...