資料同步還在「每 5 分鐘刷一次」？Webhook vs. Polling 終極對決，資深工程師教你選對架構不燒主機

大家好，我是浪花科技的資深工程師 Eric。昨天半夜，我又收到一個客戶的緊急 Ticket，標題寫著：「為什麼我的 CRM 系統還沒看到剛剛那筆 WooCommerce 的大訂單？是不是網站壞了？」我嘆了一口氣，打開他們的後台一看，嗯，果然又是那個熟悉的設定——每 15 分鐘執行一次的 Cron Job 輪詢（Polling）。

在 2025 年的今天，使用者對於「即時性」的要求已經到了苛刻的地步。訂單成立、會員註冊、庫存扣減，這些數據如果沒有在「毫秒級」或至少「秒級」內同步，輕則造成客服困擾，重則導致超賣或資料打架。很多工程師在剛開始接案或開發時，為了省事，習慣寫一個排程去「問」外部系統有沒有新資料，這就是所謂的 Polling（輪詢）。但隨著業務量增長，這種做法往往會變成效能殺手。

今天這篇文章，我要用工程師的角度，深入淺出地跟各位聊聊 Webhook vs. Polling 這場同步策略的戰爭。我們不只要談理論，還要直接看 WordPress 的程式碼實作，讓你的網站架構從「被動挨打」變成「主動出擊」。

什麼是 Polling（輪詢）？為什麼它會讓你的伺服器「過勞死」？

想像一下，你正在等一封重要信件，但你沒有手機通知。你每隔 5 分鐘就跑去樓下信箱開箱子看有沒有信。這就是 Polling。

在技術層面上，Polling 是客戶端（Client）定期向伺服器（Server）發送請求，詢問：「有新資料嗎？」。

Polling 的運作模式

• Short Polling（短輪詢）： 設定一個固定的時間間隔（例如每 60 秒），不管有沒有資料，時間到就發送 API 請求。
• Long Polling（長輪詢）： 請求發出後，伺服器會「hold 住」這個連線，直到有新資料才回傳，或者連線超時。

為什麼資深工程師通常不愛 Polling？

對我來說，Polling 就像是一個焦慮症患者。如果你的網站每分鐘都有新訂單，那 Polling 還算有效率。但如果你的網站是 B2B 類型，一天只有 10 筆訂單，卻設定每分鐘檢查一次，那一天就有 1440 次請求，其中 1430 次都是回傳「空資料」。

這造成了兩個嚴重的後果：

1. 資源浪費（Resource Waste）： 你的 WordPress 主機 CPU 和記憶體都在處理這些無效的連線 handshake 和資料庫查詢。
2. 資料延遲（Data Latency）： 如果你設定每 10 分鐘檢查一次，那麼資料同步的延遲最大就是 10 分鐘。在電商搶購場景下，這 10 分鐘足夠讓庫存炸裂。

什麼是 Webhook？主動通知的優雅藝術

相較於 Polling 的焦慮，Webhook 就像是快遞員按門鈴。你不需要一直去開信箱，你就在家裡翹腳喝咖啡，當信件（資料）來了，快遞員（外部系統）會主動「推播（Push）」給你。

Webhook 是一種事件驅動（Event-Driven）的架構。當來源系統發生特定事件（例如：訂單狀態變更為「已付款」），它會立即發送一個 HTTP POST 請求到你預先設定好的 URL（Payload URL），把資料「餵」給你。

Webhook 的絕對優勢

• 即時性（Real-time）： 事件發生當下立即觸發，延遲通常在幾百毫秒內。
• 效能友善（Efficiency）： 沒有事件就不會有請求，伺服器不需要空轉。
• 架構解耦（Decoupling）： 兩邊系統不需要知道對方的運作頻率，只需約定好資料格式（通常是 JSON）。

實戰對決：Polling 與 Webhook 的架構差異表

為了讓大家更直觀地理解，我整理了這張對照表，這也是我在幫客戶做架構健檢時常用的評估標準：

特性	Polling (輪詢)	Webhook (網頁鉤子)
運作方向	Pull (拉取)：我去問你有沒有	Push (推播)：你有就丟給我
即時性	低 (受限於輪詢間隔)	極高 (接近即時)
伺服器負載	高 (大量無效請求)	低 (僅處理有效請求)
實作複雜度	低 (寫個迴圈或 Cron 即可)	中 (需架設接收端點與驗證)
適用場景	舊系統不支援 Webhook、資料更新頻率極高	需要即時通知、事件驅動流程

WordPress 開發實戰：從 Polling 到 Webhook

光說不練不是我的風格。接下來，我們來看看在 WordPress 中，這兩種模式的程式碼長什麼樣子。這也是很多新手工程師最容易卡關的地方。

場景：同步外部 CRM 的客戶資料

1. Polling 的寫法 (使用 WP-Cron)

這是傳統的做法，你需要註冊一個 Cron Event，然後定期去打 API。

// 1. 設定排程間隔 (例如每 5 分鐘)
add_filter( 'cron_schedules', 'eric_add_5min_interval' );
function eric_add_5min_interval( $schedules ) {
    $schedules['every_5_minutes'] = array(
        'interval' => 300,
        'display'  => __( 'Every 5 Minutes' ),
    );
    return $schedules;
}

// 2. 註冊 Hook
add_action( 'eric_sync_crm_event', 'eric_perform_polling' );

// 3. 執行輪詢邏輯
function eric_perform_polling() {
    // 這是最消耗資源的地方，不管有沒有新資料都要執行
    $response = wp_remote_get( 'https://api.crm-system.com/v1/customers/updated' );
    
    if ( is_wp_error( $response ) ) {
        return;
    }

    $data = json_decode( wp_remote_retrieve_body( $response ), true );

    if ( ! empty( $data ) ) {
        // 處理資料更新
        eric_update_local_users( $data );
    }
}

Eric 的囉嗦點評： 這段程式碼看起來無害，但如果你的 wp_remote_get 回應很慢，或者 WordPress 的 WP-Cron 機制因為沒有流量而沒被觸發（還要依賴系統 Crontab），你的資料同步就會變得極不可靠。

2. Webhook 的寫法 (使用 REST API 接收端)

這是現代化的做法。我們在 WordPress 開一個 REST API 端點，等 CRM 系統把資料丟過來。

// 1. 註冊接收 Webhook 的 API路由
add_action( 'rest_api_init', function () {
    register_rest_route( 'eric/v1', '/crm-webhook', array(
        'methods' => 'POST',
        'callback' => 'eric_handle_webhook',
        'permission_callback' => '__return_true', // 記得要做安全驗證！
    ) );
} );

// 2. 處理接收到的資料
function eric_handle_webhook( WP_REST_Request $request ) {
    // 獲取 JSON Payload
    $params = $request->get_json_params();

    // 安全驗證：檢查簽名 (Signature) 防止偽造請求
    $signature = $request->get_header( 'X-CRM-Signature' );
    if ( ! eric_verify_signature( $params, $signature ) ) {
        return new WP_Error( 'invalid_signature', '簽名驗證失敗', array( 'status' => 403 ) );
    }

    // 處理資料：因為是推播，這裡一定是新資料
    if ( isset( $params['customer_id'] ) ) {
        eric_update_single_user( $params );
        return new WP_REST_Response( array( 'status' => 'success' ), 200 );
    }

    return new WP_Error( 'no_data', '無效的資料格式', array( 'status' => 400 ) );
}

Eric 的囉嗦點評： 看到差異了嗎？Webhook 的邏輯是「被動觸發」。我們不需要去問 CRM，我們只需要準備好一個「門」讓它進來。這裡最關鍵的是 register_rest_route 以及安全驗證（千萬不要讓任何人都能隨便 POST 資料給你）。

2025 年架構思維：什麼時候該選哪一個？

雖然我是 Webhook 的擁護者，但身為資深工程師，我必須誠實地說：Webhook 不是萬能藥。

選擇 Webhook 的時機：

• 資料需要即時同步： 例如庫存、付款狀態、即時通訊訊息。
• 節省頻寬與運算資源： 不想浪費資源做無效查詢。
• 事件驅動的工作流： 例如 n8n 自動化串接。

選擇 Polling 的時機：

• 來源端不支援 Webhook： 很多老舊的 ERP 或銀行系統只有被動的 API。
• 資料更新頻率極高且不需即時： 如果每秒都有 1000 筆更新，用 Webhook 狂轟你的 Server 可能會導致 DDoS 效果，這時候用 Polling 批次（Batch）拉取反而比較穩。
• 防火牆限制： 你的 WordPress 處於內網，外部系統無法主動連入。

Eric 的技術總結：混合策略才是王道

在浪花科技的許多大型專案中，我們往往不會「二選一」，而是採用混合策略。我們主要依賴 Webhook 進行即時更新，但會額外設定一個每天執行一次的 Low-Frequency Polling 機制，用來「對帳」或檢查是否有漏掉的 Webhook 事件（畢竟網路傳輸偶爾會失敗）。

記住，技術沒有絕對的好壞，只有適不適合。但在 2025 年，如果你還在全盤使用 Polling 來做即時系統，那真的該考慮重構一下了。

延伸閱讀

• 資料孤島終結者！n8n Webhook + API 串接實戰：讓你的 WordPress 與外部系統「秒速」通靈
• API 狂 Call 被鎖帳號？資深工程師教你 WordPress API 串接的優雅之道：Rate Limit 與重試機制全解析
• 訂單處理還在複製貼上？揭秘 WooCommerce Webhook 自動化魔法，打造你的 24H 全自動電商大腦！