針對自定義事件 jQuery 有一個 trigger 方法，代碼其實不是很復(fù)雜，但是由于關(guān)聯(lián)性太強了所以非常繞。我們根據(jù)案例分析下：

通過 trigger 手動觸發(fā)了 foo 元素的 click 事件，body 的 click 事件。

$("body").click(function(event,data){
    console.log('body')
})
var foo = $('#foo');
foo.on('click', function(event,data) {
    console.log(data);
});
foo.trigger('click','慕課網(wǎng)');

元素 foo 本身綁定了一個 click 事件，但是我們知道 click 這種原生事件是靠 addEventListener 綁定交互驅(qū)動的，但是 jQuery 的 trigger 能夠在任意時刻模擬這個交互行為。

從這一個功能點上我們就不難發(fā)現(xiàn)為什么 jQuery 要設(shè)計元素與數(shù)據(jù)分離了，如果是直接綁定的話就完全無法通過 trigger 的機制調(diào)用，trigger 的實現(xiàn)首先得益于事件的分離機制，因為沒有直接把事件相關(guān)的與元素直接綁定采用了分離處理，所以我們通過 trigger 觸發(fā)與 addEventListener 觸發(fā)的處理流程都是一致的，不同的只是觸發(fā)的方式而已。通過 trigger 觸發(fā)的事件是沒有事件對象、冒泡這些特性的，所以我們需要有一個方法能模擬出事件對象，然后生成一個遍歷樹模擬出冒泡行為，那么這個任務(wù)就交給了 trigger 方法了。

trigger 與 dispatch 方法的區(qū)別

很多人會迷惑trigger 與 dispatch 方法的區(qū)別。這里提到一個概念是元素內(nèi)處理，trigger 是元素外部處理。

• 簡單的來說，jQuery 的事件我們應(yīng)用從更抽象的一層去理解它的元素層次劃分其實是非常清晰的，首先每一個元素都可以綁定事件與冒泡，那么這個針對每個層的單獨元素的處理是劃分給了 dispatch 方法。在 dispatch 方法中我們通過 target 與 currentTarget（綁定事件的元素）生成一條冒泡線，依次往父層元素遍歷取出每一個層級元素對應(yīng)的數(shù)據(jù)相應(yīng)的執(zhí)行，由于在這個模擬冒泡的操作過程中，jQuery 模擬出的事件對應(yīng)被所有的這些操作共享，所以在任何一個元素的事件處理中調(diào)用了停止冒泡，那么這個循環(huán)就停止了，也就達到了 stopPropagation 的目的，這里我們要注意事件的冒泡是在綁定事件元素內(nèi)部發(fā)生的。
• 原生事件提供了一個最重要參數(shù) - 事件對象，trigger 是模擬觸發(fā)，所以我們需要模擬一個這樣的數(shù)據(jù)對象，其次 trigger 也要支持冒泡，但是這里有一個區(qū)別 dispatch 的地方，trigger 冒泡的 target 的對象是確定的，所以 target 就是自己本身，所以冒泡的路徑其實是一個從自己本身到 window 的一條外部路線。

jQuery 設(shè)計好的地方就是對元素層級的劃分，內(nèi)部冒泡與外部冒泡獨立處理，相互不會影響，但是又有千絲萬縷的關(guān)系，具體我們來看看處理的結(jié)構(gòu)。

初看 trigger 源碼部分真有點暈，處理的 hack 太多了：

1. 命名空間的過濾
2. 模擬事件對象
3. 制作一個觸發(fā)的路徑隊列eventPath
4. 對 eventPath 進行模擬冒泡的觸發(fā)
5. 在一個層級調(diào)用 dispatch 處理各自的內(nèi)部事件關(guān)系(委托）

總結(jié)

所以整個 trigger 的核心，還是圍繞著數(shù)據(jù)緩存在處理的，通過 on 機制在 jQuery.event.add 的時候預(yù)處理好了。trigger 的處理就是模擬冒泡的一個調(diào)度，具體的觸發(fā)還是交給 jQuery.event.dispatch 方法了，通過 trigger 很好的模擬了瀏覽器事件流程，但是美中不足的是對象的事件混淆其中，這就造成了觸發(fā)對象事件的時候最后會調(diào)用對象的相應(yīng)方法。