Cloudflare 在 2026 年 10 月 30 日宣布，Durable Objects 部署新程式碼時，預設不再立刻重設仍在執行的 object，而是先等待它休眠，最長預設 300 秒。這能降低聊天室、協作編輯、即時遊戲、長時間代理工作或 WebSocket 連線在部署瞬間中斷的機會，但不是「零中斷」保證，也不會自動替應用保存記憶體狀態。

對使用 Durable Objects 的團隊，真正要處理的是同一段部署期間可能同時存在新舊程式版本。新的或已休眠 object 會在下次請求使用新版；仍活躍的 object 可以暫時繼續跑舊版。若事件格式、RPC 介面或儲存 schema 沒有相容設計，延後更新反而會讓不相容的窗口更明顯。

預設延後 5 分鐘，仍可能提前被重設

Cloudflare 更新公告說明，預設 deferred 模式讓活躍 object 在等待休眠期間維持舊程式，未設定時 max_delay 為 300 秒。使用 WebSocket Hibernation API 的連線，可在 object 休眠並於新版啟動後維持連線；若到期仍未休眠，object 會被重設後採用新版。

公告也明確提醒，延後是 best effort。Cloudflare runtime 更新或其他重設仍可能在期限前發生，因此不能把 300 秒當成交易一定完成的 SLA。團隊可在 Wrangler 設定 durable_objects.code_update_strategy，選擇 deferred 與自訂等待時間；事故修補或必須立刻換版時，也可在單次部署指定 immediate。等待時間可設定不代表越長越安全，因為新舊版共存、修補延遲與觀測判讀也會拉長。

記憶體只是工作區，重要狀態必須可恢復

Durable Objects 儲存最佳實務指出，當 object 套用新版本時會建立新的 isolate，原本記憶體狀態會被丟棄；Cloudflare 也可能在其他時間驅逐非活躍 object。訂單狀態、工作游標、房間成員、未送出的事件與去重識別碼若只放在 instance 變數，就可能在部署或重啟後消失。

應把資料分成三類。第一類是可重新計算的快取，可留在記憶體但要接受遺失；第二類是完成一半的工作，應定期寫入 SQLite 或外部持久儲存，並保存可重入的 checkpoint；第三類是不可重複的副作用，例如付款、寄信、扣庫存，必須用 idempotency key、狀態機或 outbox 記錄，讓重試不會執行兩次。

長任務不要只在結束時一次寫入結果。可依可恢復的步驟保存進度：輸入已接收、外部呼叫已送出、結果已驗證、事件已發布。重啟後從最後一個確定狀態繼續，並確認外部服務是否已完成前一步。這比期待部署永遠等到任務完成可靠。

WebSocket 必須有重連、同步與版本協商

Hibernation API 能降低更新造成的斷線，但應用仍要支援連線中斷。客戶端採用帶上限的 exponential backoff 與隨機抖動，避免大量使用者同時重連；每條連線帶 session 或房間識別，重新連線後先取得伺服器最後確認的 sequence，再補送缺少事件。

訊息格式應有明確版本。部署先讓新版伺服器同時讀舊格式與新格式，再更新客戶端開始送新格式，最後才移除舊格式。若一次把欄位改名且不保留相容讀取，延後更新期間可能由舊 object 寫入新版無法理解的資料，或新版客戶端對舊 object 發出未知命令。

對協作編輯與即時遊戲，還要區分「連線活著」與「狀態正確」。部署測試要涵蓋未確認操作、重複訊息、順序錯置、客戶端離線後補送，以及 object 在不同步驟被重設。只有 ping／pong 成功，不能證明內容沒有遺失或重複。

依更新風險選擇 deferred 或 immediate

一般功能發布適合預設 deferred，讓短請求與可休眠連線自然完成。若是修補正在被利用的安全漏洞、撤銷錯誤邏輯，或新版部署後會立刻由自動化呼叫並且不能接受舊行為，可考慮單次 immediate；代價是活躍 object 立即重設，因此要先確認客戶端重連與工作恢復。

資料 schema 變更應採 expand／migrate／contract。先加入新版欄位並保持舊版可讀寫，再部署相容程式與執行遷移，觀察所有 object 都已採用新行為後，另一次部署才移除舊欄位。不可回復的 migration 不應和依賴它的新程式同一瞬間上線，否則即使程式能回滾，資料也可能無法被舊版讀取。

部署管線應記錄版本 ID、更新策略、等待時間、相容範圍與回滾指令。先對小部分流量或測試命名空間發布，觀察 WebSocket 中斷率、object 重設、錯誤、事件重複、任務完成時間與儲存延遲。若改用 gradual deployments，也要驗證不同版本間的服務呼叫與資料契約，不把流量百分比誤當成狀態隔離。

Cloudflare 這項變更提供了更友善的部署緩衝，但可靠性仍來自應用設計。把重要狀態持久化、讓副作用可去重、客戶端可重連、新舊格式可共存，再依事件風險選擇 deferred 或 immediate，才能把「最多等 5 分鐘」轉成可驗證的部署能力，而不是新的安全錯覺。