暫存上傳需要保留規則

「暫存上傳」是一個帶作業的承諾。

聽起來很清楚：使用者上傳檔案，系統短暫使用，然後就消失。很好。但系統不是只有一個地方。檔案可能會經過瀏覽器、邊緣快取、應用程式伺服器、物件儲存、佇列、模型執行環境、重試工作器、縮圖產生器、內容分發網路（CDN）、支援工具，以及日誌。

如果「暫存」只代表主資料庫裡的暫時性，那個承諾就太薄了。使用者在乎的是檔案本身，而不是你資料庫結構圖。

暫存上傳的保留政策應涵蓋原始檔、縮放版本、遮罩、預覽、縮圖、重試載荷、失敗任務、輸出交付的 URL、快取，以及日誌。它應該說明：會建立哪些內容、為什麼要建立、會存多久，以及之後還會留下什麼。

這並不表示每個暫存檔都必須立刻消失。有些系統需要短暫有效的交付連結。有些需要短時間的重試窗口。有些需要不含內容的紀錄，用於計費或防止濫用。重點是：保留行為必須是刻意設計的，並且有清楚的說明。

暫存也需要處理失敗情境。如果生成在一半時崩潰，上傳還會保留嗎？如果工作器逾時，來源影像是否會被保留以便除錯？如果使用者取消，部分輸出會怎麼處理？失敗路徑正是「暫存承諾」變成「意外儲存」的地方。

最安全的做法是減少複製。複製越少，就越少需要制定保留規則，也越少清理工作。短暫的「生成作業階段」（Generation Session）在接收內容、處理內容、回傳結果後就丟棄敏感材料，比起把上傳變體像彩帶一樣到處散落的產品，更容易理解與推理。

「暫存」不是你貼在介面上的一句話。它是一個工程層級的宣告。

延伸閱讀：如何在不使用雲端術語的情況下思考短暫運算、Unexposed 資料儲存，以及 OpenAI 的 API 資料控管。