處理 LINE 收回訊息事件：避免已刪除內容重回收件匣

LINE 使用者收回訊息後，應從客服介面移除內容，並停止在下游使用。LINE 官方 webhook 指南建議取消顯示並刪除已儲存內容。透過 UnifyPort 串接時，可處理標準化的 message.deleted 事件，持久化刪除標記，再執行可重試的清理工作。只刪除收件匣中的一筆資料並不足夠：延遲事件可能重建訊息，搜尋或 AI 上下文也可能仍保有副本。

重點

• 接收收回通知與呼叫 API 主動收回訊息是兩回事。
• 依事件 ID 去重，但用 data.message.id 與帳號範圍定位目標訊息。
• 保留最小刪除標記，避免延遲的接收或編輯事件還原內容。
• 獨立追蹤下游清理；webhook 確認成功不代表所有副本都已刪除。

LINE 收回訊息對儲存內容的意義

LINE 訊息接收指南說明，使用者收回訊息時，伺服器會收到 unsend 事件。官方建議尊重使用者意圖，避免內容繼續被查看或使用，包括從管理畫面移除，以及從儲存空間刪除。

這是官方建議。以下刪除標記、交易式 outbox 與驗收測試是應用程式架構建議，不是 LINE 內建功能，也不是法定資料保留期限的判定。

編輯是取代內容，收回則是停止使用內容。若也處理編輯，可保留LINE message.updated 同步流程，但必須在寫入新文字前檢查刪除標記。修訂紀錄不能成為客服或檢索工作仍可讀取的隱藏副本。

分清楚事件契約

LINE 官方 Messaging API 接收器與 UnifyPort 接收器使用不同的酬載與驗證契約。沒有獨立轉接層時，不要把原生 LINE 請求直接送進標準化事件處理器。

UnifyPort 的標準事件參考將 message.deleted 定義為訊息已刪除或收回。在 message 物件中，只保證 data.message.id；文字與媒體會被移除。平台事件矩陣列出 LINE、Telegram 與 WhatsApp 對該事件的映射支援，但不保證所有上游帳號或部署都會產生每種已映射事件。

以下示例使用文件中的欄位與虛構識別碼，並非實際擷取的投遞：

{
  "id": "evt_6d91a2c8",
  "type": "message.deleted",
  "provider": "line",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-09-23T08:15:00Z",
  "data": {
    "conversation": { "id": "c8f2a4d91e", "type": "group" },
    "message": { "id": "551842037194" },
    "event": { "kind": "message_deleted" }
  }
}

頂層 id 識別事件，data.message.id 識別被移除的訊息。不要用前者查找訊息，也不要把缺少文字解讀成「編輯為空字串」。

先建立刪除屏障，再清理副本

在 subscribed_events 中加入 message.deleted，保留應用程式需要的接收與編輯事件，並啟用 signing_secret。依照投遞契約，對時間戳記、句點與原始請求本文驗證 HMAC-SHA256，接受工作前也要執行時間戳記有效時間檢查。重放防護教學說明了驗證與持久化去重為何不能互相取代。

完成驗證與酬載檢查後：

1. 在正確的工作區、平台與訊息帳號內定位目標。可用時使用對話與訊息識別碼；缺少對話資訊時，只採用既有且無歧義的帳號內映射。不可跨對話猜測，無法定位的目標應隔離並交付審查。
2. 在同一交易內記錄事件去重資訊、建立或保留最小刪除標記、移除線上內容，並排入清理工作。與相同目標的接收、編輯寫入進行序列化協調。
3. 持久化接受後才回傳 2xx；下游清理由 worker 獨立重試。
4. 所有接收與編輯寫入都要檢查標記。延遲事件不能重新填入內容或觸發新的 AI 工作。

以下是建議的應用程式狀態，不是 API 欄位：

目前狀態	收到事件	處理方式
沒有原始訊息	刪除	儲存不含內容的標記，不等待原始訊息
線上內容	刪除	停止顯示並排入清理
刪除標記	接收或編輯	不還原內容
刪除標記	重複刪除	維持狀態，繼續未完成的清理

不要只依賴到達順序或「最後時間戳記優先」。UnifyPort 不保證投遞順序。刪除标記是應用程式的明確規則：對同一訊息身分，刪除持續有效。

追蹤副本，而不只是收件匣資料列

維護來源訊息到衍生產物的本地映射。以下是需盤點的清理目標，不是 UnifyPort 自動執行的能力：

副本或工作	建議動作
收件匣本文、預覽	移除內容並使快取失效
已下載附件	刪除持有的副本與縮圖
搜尋、向量索引	刪除項目，清理完成前阻止檢索
AI 上下文、摘要、待送回覆	排除來源，使受影響摘要失效，取消或審查相依工作
CRM、團隊聊天轉送	支援時刪除或遮蔽，追蹤未能清理的副本
原始事件日誌、死信佇列、備份	套用存取與保留政策，防止還原至線上檢視

worker 應在檢索前、發布生成文字前，以及重建索引時再次確認刪除狀態。可行時，發布也要與相同的訊息層級保護機制協調。已交給外部系統的工作未必能收回；應記錄限制，不能承諾完全抹除。

最小標記可只保留有範圍的識別碼與清理狀態，不保留已收回的文字。依重放、備份還原及隱私需求決定保留期限。舊事件仍可重放時移除標記，可能讓內容再次出現。

驗收測試與限制

使用受控測試訊息，不使用客戶資料。以下是建議測試，並非已執行結果：

• 刪除先於原始訊息：後到的接收事件仍不會顯示內容。
• 刪除與編輯或索引工作同時執行：內容不會重新發布。
• 重複投遞刪除：不重複產生副作用，未完成工作繼續重試。
• 下游刪除失敗：收件匣隱藏內容，清理狀態仍明確標示待完成。
• 還原備份：開放搜尋或收件匣存取前，先套用刪除標記。

UnifyPort 提供非官方介面與標準化事件流，不會自動刪除 CRM 或 AI 系統的內容。它沒有 REST 訊息歷史讀取 API，也不保證重放漏收事件。未收到刪除事件，不代表沒有發生收回。需要原生 LINE 官方帳號契約時，應優先使用官方路徑。

常見問題

message.deleted 是收回他人訊息的請求嗎？

不是。它報告已觀察到的刪除或收回。清理自己的儲存副本，與主動執行平台動作是不同操作。

能從刪除酬載找回原文嗎？

不能。文件保證目標 ID，不保證已移除的文字或媒體。不要把收回處理設計成內容復原功能。

HTTP 200 表示所有下游副本都刪完了嗎？

不是。它只確認投遞；應用程式必須另行追蹤清理完成狀態與失敗。

下一步與來源

查看平台 webhook 事件矩陣，啟用下游 AI 處理前，先加入「刪除先於原始訊息」的測試。

資料核對日期：2026-09-23。

• LINE：接收訊息與收回事件處理
• LINE：Messaging API 參考
• UnifyPort：標準事件
• UnifyPort：投遞與簽章驗證