n8n 錯誤處理教學：Error Trigger 失敗通知、自動重試與重跑

這篇帶你把 n8n 的錯誤處理整套設好：容易失敗的節點讓它自動重試，個別資料出錯時決定要停下來還是繞過去，整個流程失敗時由一個專門的錯誤處理工作流程發 Telegram 或 Email 通知你，訊息裡附上執行紀錄的連結，點開就能從失敗的那個節點重跑。你需要一台 n8n 2.x（自己架或託管都可以）、一個收通知的管道（Telegram bot、Gmail 或 Slack 擇一），再拿一個現有的流程來測試，整套做下來大約半小時。

本文依 n8n 官方文件與 GitHub 上 2.45 版的原始碼整理，介面名稱以 2.x 英文介面為準，資料查證至 2026 年 10 月。

先分清楚兩層：節點出錯和流程失敗

n8n 的錯誤處理分成兩層，很多人一開始搞混，設了半天收不到通知。第一層在節點上：每個節點的 Settings 分頁裡有 Retry On Fail 和 On Error，決定這個節點失敗時要不要重試、重試完還是失敗要怎麼辦。第二層在整個工作流程上：一次執行最後的狀態是「失敗」時，n8n 會去叫你指定的錯誤處理工作流程（Error Workflow），由它負責通知或善後。

兩層之間有一個關鍵的連動：只有流程真的以失敗結束，第二層才會啟動。如果你在節點上把 On Error 設成 Continue，錯誤被吞掉、流程最後算成功，錯誤處理工作流程就不會被叫起來。所以動手前先想清楚，哪些錯誤可以在節點上自己消化（網路偶爾逾時、某一筆資料格式不對），哪些錯誤一定要讓人知道（憑證過期、對方服務掛掉、整批資料沒抓到）。後者就讓流程失敗，交給錯誤處理工作流程。

節點層級一：Retry On Fail 自動重試

打開任何一個節點，面板上方除了 Parameters 還有一個 Settings 分頁。把 Retry On Fail 打開，下面會多出兩個欄位：Max. Tries 是總共要試幾次（包含第一次），預設 3，可以設 2 到 5；Wait Between Tries (ms) 是每次之間等多久，單位是毫秒，預設 1000，最多 5000。換算下來，開到最大也只是最多試 5 次、每次隔 5 秒，總共大約等 20 秒。這個上限寫在 n8n 的執行引擎裡，欄位填更大的數字也會被壓回 5 次和 5000 毫秒。

這個長度剛好適合處理「等一下就好」的錯誤：對方伺服器偶爾回 502 或 503、連線逾時、每秒請求數的限流。對於再試幾次也一樣的錯誤就沒有意義，例如 401 憑證錯誤、400 參數格式不對、404 找不到資料，重試只是讓失敗晚 20 秒發生。我自己的習慣是把 Retry On Fail 開在呼叫外部服務的節點上，像 HTTP Request、AI 模型、Google Sheets，流程內部的 IF、Edit Fields、Code 節點就不開。

有一點要特別注意：重試是整個節點重跑。假設 HTTP Request 一次處理 100 筆資料，第 87 筆失敗，重試時前面 86 筆也會再送一次。如果這個節點只是讀資料，沒什麼影響；如果是寄信、建立訂單、寫入資料庫，就可能寄兩次信、多出一筆訂單。寫入類的節點要開重試，最好先確認對方 API 有防重複的機制（例如帶一個唯一的訂單編號），或者把資料拆成一次一筆再處理。

節點層級二：On Error 的三種選擇

同樣在 Settings 分頁，On Error 決定重試用完還是失敗之後怎麼辦，有三個選項。

Stop Workflow 是預設值：節點失敗，整個流程立刻停止，這次執行記為失敗，接著觸發你設定的錯誤處理工作流程。大部分節點維持預設就對了，尤其是流程前段負責抓資料的節點，資料沒抓到，後面做什麼都沒有意義。

Continue 會把錯誤訊息包成一筆資料，從一般的輸出往下傳，下一個節點可以用 {{ $json.error }} 看到錯誤內容。流程會繼續跑完，最後的狀態是成功。這適合壞一筆也沒關係的情境，但下游節點會收到一筆缺了預期欄位的資料，常常在更後面的地方用奇怪的方式出錯，除錯反而更難。

Continue (using error output) 是我最常用的一種。選了之後，節點右側會多出一個 error 輸出，成功的資料照常從上面那條線往下走，失敗的那幾筆改走 error 那條線。走 error 線的資料會保留原本的欄位，另外多一個 error 欄位放錯誤內容，所以你可以把它們寫進 Google Sheets 的待處理分頁、發一則通知，或者等一下再重送（後面講 429 時會用到）。

要記得 error 輸出處理完之後，流程一樣會以成功結束。如果你希望分流處理完，還是要讓這次執行算失敗、觸發錯誤通知，就在 error 那條線的最後接一個 Stop and Error 節點，下面會講它的用法。

流程層級：用 Error Trigger 建錯誤處理工作流程

錯誤處理工作流程就是一個以 Error Trigger 節點開頭的普通流程。其他流程失敗時，n8n 會把失敗的資訊交給它，後面接什麼節點都可以：發通知、寫進試算表、開工單。一個錯誤處理工作流程可以給很多流程共用，通常整台 n8n 做一個就夠了。還沒做過任何流程的話，可以先看建立第一個工作流程熟悉一下編輯器。

步驟一：建立錯誤處理工作流程並發布

1. 在 n8n 首頁按 Create workflow 建一個新流程，名稱取「錯誤通知」這類一看就懂的名字。
2. 新增第一個節點時搜尋 Error Trigger。這個節點沒有參數，面板上只有一行說明：其他流程設定好之後，出錯時會觸發它。
3. 後面接你要的通知節點（下一節以 Telegram 示範），存檔。
4. 按右上角的 Publish 發布。這一步在 n8n 2.x 不能省，原因見下一段。

關於要不要發布，網路上的教學和官方 Error Trigger 文件都寫錯誤處理工作流程不需要發布（舊版叫啟用），這是 1.x 時代的行為。2.x 把草稿和發布版本分開之後，n8n 執行錯誤處理工作流程時讀的是已發布版本，從來沒發布過的話，失敗的流程叫不動它，伺服器日誌會留下 ... is not active and cannot be executed，你什麼通知都收不到。較新的版本更直接，在你指定錯誤流程時就會擋下來，顯示 The selected error workflow has no published version.。同樣的道理，之後修改了錯誤處理工作流程，也要重新 Publish 才會生效，只存檔的話跑的還是舊的發布版本。

步驟二：在要監控的流程裡指定 Error Workflow

1. 打開你要監控的流程，按右上角的三個點（Workflow menu），選 Settings。
2. 在 Error Workflow (to notify when this one errors) 下拉選單選剛才的「錯誤通知」。
3. 按 Save。依官方文件，已發布的流程只改設定的話，n8n 會自動重新發布，不用再按一次 Publish。

這個設定是跟著每個流程各自存的，要監控幾個流程就要設幾次。流程一多容易漏，建議新建流程時就順手先設好 Error Workflow。

如果錯誤處理工作流程和被監控的流程放在不同專案，還要注意錯誤流程 Settings 裡的 This workflow can be called by。n8n 執行錯誤流程前會檢查這個設定，預設只允許同一個擁有者的流程呼叫，不符合的話錯誤流程會被擋下，只在它的執行紀錄裡留下一筆權限錯誤。最省事的做法是把錯誤處理工作流程放在同一個專案，或在這裡放寬允許的範圍。

錯誤資料裡有哪些欄位可以用

Error Trigger 收到的資料大致長這樣。這裡依 2.x 原始碼調整過執行網址的格式，實際是 /workflow/流程ID/executions/執行ID，官方文件範例裡的舊格式已經不同了：

[
  {
    "execution": {
      "id": "231",
      "url": "https://n8n.example.com/workflow/1/executions/231",
      "retryOf": "34",
      "error": {
        "message": "Example Error Message",
        "stack": "Stacktrace"
      },
      "lastNodeExecuted": "Node With Error",
      "mode": "trigger"
    },
    "workflow": {
      "id": "1",
      "name": "Example Workflow"
    }
  }
]

最常用的是這幾個：{{ $json.workflow.name }} 是失敗的流程名稱；{{ $json.execution.lastNodeExecuted }} 是最後執行的節點，通常就是出錯的那個；{{ $json.execution.error.message }} 是錯誤訊息；{{ $json.execution.url }} 是這次執行紀錄的網址，點開會看到每個節點的輸入輸出，出錯的節點標成紅色；{{ $json.execution.id }} 是執行編號。execution.mode 告訴你這次是怎麼被觸發的，例如排程是 trigger、Webhook 是 webhook、從執行紀錄重跑是 retry。retryOf 只有在這次執行本身就是重跑時才會出現，值是原本那次的執行編號。

有一個例外要記得：如果出錯的是流程的觸發節點本身，例如 Gmail Trigger 的憑證失效，流程根本沒開始跑，資料裡就沒有 execution，改成一個 trigger 物件，錯誤訊息在 {{ $json.trigger.error.message }}，也沒有執行網址。通知訊息的表達式要顧到這種情況，不然錯誤流程會在讀 $json.execution.url 的時候自己出錯。

實作：任何流程失敗就發 Telegram 通知，附執行連結

收通知的管道我用 Telegram 示範，建 bot 不用審核，五分鐘內就能用。LINE Notify 已經在 2025 年 3 月 31 日結束服務，想用 LINE 收通知得改走 LINE Messaging API，設定步驟比較多，這篇先不展開。

1. 在 Telegram 搜尋 BotFather，傳 /newbot，照指示取名字，最後會拿到一串 bot token。
2. 先傳任何一則訊息給你的 bot，再用瀏覽器打開 https://api.telegram.org/bot你的token/getUpdates，回應裡 chat 底下的 id 數字就是你的 Chat ID。要發到群組的話，把 bot 拉進群組、在群組裡傳一則訊息再查，群組的 Chat ID 是負數。
3. 回到「錯誤通知」流程，在 Error Trigger 後面加 Telegram 節點，動作選 Send a text message。Credential 選 Create new credential，在 Access Token 貼上 bot token。
4. Chat ID 填上一步拿到的數字，Text 切成 Expression，貼上下面的內容。
5. 在 Additional Fields 加入 Parse Mode 並選 HTML，再加入 Append n8n Attribution 並關掉，不然訊息尾巴會多一行 n8n 的署名。

【n8n 流程失敗】
流程：{{ $json.workflow.name }}
失敗節點：{{ $json.execution ? $json.execution.lastNodeExecuted : '觸發節點' }}
錯誤訊息：{{ (($json.execution || $json.trigger).error.message || '').slice(0, 500).replaceAll('&', '&amp;').replaceAll('<', '&lt;').replaceAll('>', '&gt;') }}
時間：{{ $now.toFormat('yyyy-MM-dd HH:mm') }}
執行紀錄：{{ $json.execution ? $json.execution.url : '觸發節點出錯，沒有執行紀錄' }}

錯誤訊息那一行做了三件事。第一，觸發節點出錯時改讀 trigger 裡的訊息。第二，只取前 500 個字，因為有些 API 出錯時會回一整頁 HTML，而 Telegram 單則訊息上限是 4096 個字，太長會發不出去。第三，把 &、<、> 換成 HTML 跳脫字元，因為 Parse Mode 設成 HTML 之後，訊息裡只要有沒跳脫的角括號，Telegram 就會回 Bad Request: can't parse entities，整則通知發不出去。

那乾脆不設 Parse Mode 行不行？看 n8n 的原始碼，Telegram 節點在沒設定 Parse Mode 時會自動用舊版 Markdown 解析，錯誤訊息或網址裡只要有底線、星號，一樣會 can't parse entities。改用 HTML 再自己跳脫，是我試過最穩的做法。時間那一行用的是流程的時區，RoamerHost 託管的 n8n 已經預設台灣時間；自己架的話，記得設環境變數 GENERIC_TIMEZONE=Asia/Taipei，沒設的話 n8n 預設用美國紐約時間。

不想一個一個欄位填的話，可以複製下面這段，在 n8n 畫布上按 Ctrl+V（Mac 是 Cmd+V）直接貼上兩個已經接好的節點，再補上 Telegram 憑證、把 Chat ID 換成你自己的：

{
  "nodes": [
    {
      "parameters": {},
      "name": "Error Trigger",
      "type": "n8n-nodes-base.errorTrigger",
      "typeVersion": 1,
      "position": [0, 0]
    },
    {
      "parameters": {
        "chatId": "123456789",
        "text": "=【n8n 流程失敗】\n流程：{{ $json.workflow.name }}\n失敗節點：{{ $json.execution ? $json.execution.lastNodeExecuted : '觸發節點' }}\n錯誤訊息：{{ (($json.execution || $json.trigger).error.message || '').slice(0, 500).replaceAll('&', '&amp;').replaceAll('<', '&lt;').replaceAll('>', '&gt;') }}\n時間：{{ $now.toFormat('yyyy-MM-dd HH:mm') }}\n執行紀錄：{{ $json.execution ? $json.execution.url : '觸發節點出錯，沒有執行紀錄' }}",
        "additionalFields": {
          "appendAttribution": false,
          "parse_mode": "HTML"
        }
      },
      "name": "Telegram 通知",
      "type": "n8n-nodes-base.telegram",
      "typeVersion": 1.2,
      "position": [240, 0]
    }
  ],
  "connections": {
    "Error Trigger": {
      "main": [[{ "node": "Telegram 通知", "type": "main", "index": 0 }]]
    }
  }
}

步驟三：測試，手動執行不會觸發錯誤流程

這是最多人卡住的地方：你在編輯器裡按 Execute workflow 手動跑一個會失敗的流程，錯誤處理工作流程不會被觸發。官方文件寫得很明白，Error Trigger 只在自動執行的流程失敗時才會跑；原始碼裡也是直接看執行模式，手動執行（manual）就跳過。所以測試要分兩段做。

第一段測訊息格式：在「錯誤通知」流程裡直接按 Execute workflow。Error Trigger 在手動執行時會吐出一組範例資料，錯誤訊息是 Example Error Message、執行編號是 231，Telegram 節點會拿它發一則測試通知，你可以確認排版和表達式都正常。

第二段測整條路：新建一個「錯誤測試」流程，觸發器用 Schedule Trigger，Trigger Interval 選 Minutes、Minutes Between Triggers 填 1，後面接一個 Stop and Error 節點，Error Message 填「這是測試錯誤」。到這個流程的 Settings 把 Error Workflow 指向「錯誤通知」，然後 Publish。等一兩分鐘，Telegram 應該會收到通知，點連結會打開那次失敗的執行紀錄。確認沒問題後記得把測試流程 Unpublish，不然它會每分鐘失敗一次，也每分鐘通知你一次。

想改用 Email 或 Slack，把 Telegram 節點換成 Gmail 節點（Resource 選 Message、Operation 選 Send）或 Slack 節點（同樣是 Message 底下的 Send），內文沿用同一組表達式就好，這時候可以不做 HTML 跳脫。Email 主旨建議寫成 [n8n 失敗] {{ $json.workflow.name }}，在收件匣裡一眼就知道是哪個流程。重要的流程可以兩個管道都發：把 Telegram 節點的 On Error 設成 Continue (using error output)，error 那條線接 Gmail，Telegram 發不出去的時候至少還有一封信。

Stop and Error：沒有報錯但結果不對時，主動讓流程失敗

最難發現的失敗，是流程顯示成功但其實什麼都沒做。例如每天早上抓前一天的訂單做報表，對方 API 回 200、內容卻是空陣列；或者回傳 {"ok": false, "error": "token expired"} 這種把錯誤包在正常回應裡的格式。n8n 判斷 HTTP Request 成不成功看的是狀態碼，這些情況都算成功，錯誤處理工作流程不會知道。

做法是在抓資料的節點後面加一個 IF 節點檢查結果，例如條件寫 {{ $json.ok }} is false，或者 {{ $json.orders.length }} 等於 0，true 那條線接 Stop and Error。Stop and Error 的 Error Type 有兩種：Error Message 填一段文字，可以用表達式帶入資料，例如 API 回傳失敗：{{ $json.error }}；Error Object 填一個 JSON 物件，適合要帶錯誤代碼給後續判斷的情況。流程跑到這個節點就會以失敗結束，錯誤處理工作流程收到的 execution.error.message 就是你填的那段文字，lastNodeExecuted 是這個 Stop and Error 節點的名稱。所以節點名稱值得取清楚一點，例如「今天訂單數為 0」，收到通知一看就知道發生什麼事。

從執行紀錄重跑失敗的執行

收到通知、修好問題之後，不用回頭重新觸發一次。n8n 預設會保存正式執行的失敗紀錄，可以直接從失敗的節點接著跑。

1. 點通知裡的執行連結，或從左側的 Overview 進 Executions 分頁，按 Filters、在 Status 選 Failed，找到那次失敗的執行。
2. 在那一列右邊的三個點選 Retry with currently saved workflow (from node with error) 或 Retry with original workflow (from node with error)。如果你是在流程上方的 Executions 分頁操作，同樣的兩個選項叫 Retry with current version 和 Retry with original version。
3. 重跑會產生一筆新的執行，標示 Retry of 原本的執行編號；重跑成功之後，原本那筆就不能再重跑。

兩個選項的差別在用哪一版的流程。currently saved（current version）用你現在存檔的版本，適合已經改好節點設定的情況；original 用當時執行的那一版，適合流程本身沒問題、只是對方服務剛才掛了的情況。兩種都從出錯的節點開始，前面已經成功的節點直接沿用當時的結果，觸發器不會再觸發，也不會重抓資料。重跑如果又失敗，錯誤處理工作流程會再收到一次通知，這次資料裡會帶著 retryOf。

重跑有幾個限制要知道。失敗的那個節點會把它的輸入資料全部重新處理一次，包含當時已經處理成功的那幾筆，所以如果它是寄信或寫入類的節點，先到對方系統確認哪些已經進去了。用 currently saved 重跑時，如果你把出錯的節點改了名字或刪掉，會看到 Could not find the node "..." in workflow. It probably got deleted or renamed.，這時只能改用 original 重跑，或重新觸發。最後，沒有存下來的執行不能重跑：如果你為了省空間把 Save failed production executions 設成 Do not save，就沒有東西可以重跑，通知裡的連結點開也找不到紀錄。執行紀錄要留多少、怎麼清，可以看執行紀錄膨脹與清理這篇。

外部 API 回 429 限流怎麼處理

429 Too Many Requests 是串外部服務最常見的錯誤之一，在 n8n 裡通常顯示成 The service is receiving too many requests from you，HTTP Request 節點的錯誤內容裡也可能出現一句提示，建議你用 Options 裡的 Batching 把請求分散開。處理方式要看對方怎麼限，先去查那個服務的 API 文件，看限制是每秒、每分鐘還是每天。

限制是每秒幾次的話，Retry On Fail 就夠了：Max. Tries 設 3 到 5，Wait Between Tries 設得比限流間隔長，例如對方每秒只收 1 次，就設 1000 以上。

更好的做法是一開始就送慢一點。HTTP Request 節點的 Options 可以加入 Batching，Items per Batch 是每批送幾筆（預設 50），Batch Interval (ms) 是每批之間隔多久（預設 1000）。例如對方限每分鐘 60 次，就設每批 1 筆、間隔 1000 毫秒。沒有 Batching 選項的節點（例如 AI 模型、Google Sheets），可以在前面放 Loop Over Items、後面放 Wait 節點再接回 Loop Over Items，效果一樣。

限制是每分鐘或更長的話，Retry On Fail 最多等 20 秒不夠用，可以自己做一個等久一點再重送的迴圈：

HTTP Request
  Settings → Retry On Fail：開，Max. Tries 3，Wait Between Tries (ms) 5000
  Settings → On Error：Continue (using error output)
    error 輸出 → IF（{{ $runIndex }} 小於 3）
      true  → Wait（Resume 選 After Time Interval，60 Seconds）→ 接回 HTTP Request
      false → Stop and Error（重試 3 輪仍被限流）

這裡的 $runIndex 是這個節點在這次執行裡跑到第幾次，從 0 開始算，IF 每繞一圈就加 1，用來限制最多重送 3 輪，避免對方一直限流時變成無窮迴圈。走 error 輸出的資料保留了原本的欄位，所以接回 HTTP Request 時，原本用 $json 帶進去的參數照樣讀得到。三輪都失敗就由 Stop and Error 讓流程失敗，錯誤處理工作流程會通知你。

最後一種是每天或每月的額度用完，例如 AI 模型的每日 token 上限。這種情況重試多少次都沒用，就讓它失敗、收到通知，等額度恢復後到執行紀錄用 Retry with original workflow 重跑。

常見的坑

手動執行失敗，收不到任何通知

這是正常的。錯誤處理工作流程只處理自動執行的失敗，在編輯器按 Execute workflow 跑出來的錯誤不會觸發它。照上面「錯誤測試」的方式，發布一個排程流程來測。

正式流程失敗了，錯誤流程還是沒動靜

依序檢查：錯誤處理工作流程有沒有 Publish，最近修改後有沒有重新 Publish；它的第一個節點是不是 Error Trigger，而且沒有被停用；失敗的流程 Settings 裡 Error Workflow 有沒有選到它；兩個流程是不是在不同專案，被 This workflow can be called by 擋掉。也要確認失敗的節點不是設成 Continue，被吞掉的錯誤不會讓流程失敗。

通知裡的連結是 http://localhost:5678

執行網址是用 n8n 設定的對外網址組出來的，n8n 會先看 N8N_EDITOR_BASE_URL，再看 WEBHOOK_URL，都沒設就用預設的 http://localhost:5678。自己用 Docker 架在反向代理後面的話，把這兩個變數設成你的 https 網址後重建容器。Webhook 網址跑掉也是同一個原因，可以參考 Webhook 與第三方串接教學。

Telegram 回 can't parse entities

訊息內容裡有 Telegram 解析不了的符號。照上面的範例把 Parse Mode 設成 HTML，並把錯誤訊息裡的 &、<、> 跳脫；流程名稱如果可能出現角括號，也一樣包一層。

錯誤處理工作流程自己出錯

為了避免無限迴圈，錯誤處理工作流程自己失敗時，n8n 不會再拿它來處理它自己的錯誤，代價是通知節點壞了你也不會知道。所以這個流程要越簡單越好，通知節點開 Retry On Fail，Telegram 或 Gmail 的憑證換過時要記得一起更新，偶爾到它的 Executions 分頁看一下有沒有紅色的失敗紀錄。

不想自己顧主機的話

錯誤通知做好之後，剩下會讓流程半夜停擺的，多半是主機本身：容器掛了沒人重啟、磁碟被執行紀錄塞滿、版本太舊沒跟上資安修補。如果你想把時間花在流程上，不想顧這些，RoamerHost 的 n8n 全託管是獨立容器，給你專屬的 HTTPS 子網域與 Webhook 網址，錯誤通知裡的執行連結點了就能打開，時區已預設台灣時間，包含自動更新與自動備份，執行次數與流程數不設上限，年繳 NT$5,988（平均每月 NT$499），有問題可以直接用中文問我們。想先比較自己架要花多少，可以看自架 n8n 的成本表。

常見問題

Q：錯誤處理工作流程一定要發布嗎？

在 n8n 2.x 要。執行時讀的是已發布版本，沒發布就不會跑，新版甚至會在你指定錯誤流程時直接擋下。官方 Error Trigger 文件寫的不用發布是 1.x 的行為。修改之後也要重新發布才會生效。

Q：可以一個錯誤流程給所有流程共用嗎？

可以，一個 Error Trigger 流程能接所有流程的錯誤，用 $json.workflow.name 分辨是哪個流程出事。不過每個流程都要在自己的 Settings 裡指定一次。想依流程通知不同的人，可以在 Error Trigger 後面接 Switch 節點，依流程名稱發到不同的群組。

Q：Retry On Fail 可以設成等 1 分鐘再試嗎？

不行，Wait Between Tries 最多 5000 毫秒、Max. Tries 最多 5 次。要等更久，用 On Error 的 Continue (using error output) 接 Wait 節點再接回原節點，做法見上面 429 那一節。

Q：重跑失敗的執行會從頭開始嗎？

不會。重跑從出錯的節點開始，前面成功的節點沿用當時的輸出，觸發器也不會再觸發一次。但出錯的那個節點會把它所有的輸入重新處理，寫入類的節點要先確認哪些資料已經進去了。

資料來源

• n8n 官方文件：Error handling、Error Trigger node、Stop and Error node
• n8n 官方文件：節點設定（Retry On Fail、On Error）、工作流程設定、發布工作流程
• n8n 官方文件：重跑失敗的執行、處理 API 限流
• n8n GitHub 原始碼（2.45.4 版）：錯誤流程讀取已發布版本、錯誤資料與執行網址、重試次數與間隔上限
• n8n 社群論壇：Should sub-workflows & error workflows be published
• Telegram：Bot API sendMessage（單則訊息 4096 字上限）