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

通過 trigger 手動觸發了 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','慕課網');

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

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

trigger 與 dispatch 方法的區別

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

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

jQuery 設計好的地方就是對元素層級的劃分，內部冒泡與外部冒泡獨立處理，相互不會影響，但是又有千絲萬縷的關系，具體我們來看看處理的結構。

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

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

總結

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