@leemiyinghao: 在開發中後期遇到 `multipart/form-data` 的問題時，在評估後我們選擇改用 **TUS (The Upload Server)**。TUS 是一個開放的、獨立於 GraphQL 的協定，專為**可靠的、可恢復的檔案上傳**而設計。它的核心理念，就是將大型檔案拆分成可管理的區塊，並提供斷點續傳的能力。 TUS 在 GraphQL 架構中的角色並非直接融入 GraphQL 的請求處理，而是作為一個**外部的、專門的檔案上傳服務**，而 GraphQL API 則扮演**協調者 (Coordinator)** 的角色，尤其在檔案完成上傳後處理業務邏輯方面。 **第一步：Client 與 TUS 伺服器互動 (HTTP POST / PATCH / HEAD)** **客戶端：** 當使用者準備上傳檔案時，Client 會使用 TUS library（例如 `tus-js-client`）與 TUS 伺服器進行互動。這個過程會由 TUS library 自動處理： * Client 會先向 tusd 送出一個 HTTP `POST` request，初始化一個新的上傳資源。 * tusd 會回應一個唯一的、用於該檔案上傳的 **TUS 上傳 URL** (例如 `https://tus-server.example.com/uploads/your-upload-id`)。 * 接著，Client 會將檔案分割成多個資料區塊 (chunks)，並透過一系列的 HTTP `PATCH` 請求將這些資料區塊逐一上傳到這個 TUS 上傳 URL。 * 過程中，TUS client 會檢查 `Upload-Offset` 確保從正確的位置續傳。 * 若上傳中斷，client 會利用 `HEAD` 請求查詢當前進度，然後從上次中斷的地方恢復上傳。 **tusd：** 在此互動過程中，tusd 會獨立接收並組裝檔案資料，同時維護上傳 session 的狀態。 **第二步：GraphQL 接收上傳完成通知並執行後續邏輯 (GraphQL Mutation)** **客戶端：** 當 TUS client 確認檔案已成功上傳到 TUS 伺服器後，**client 會再次向 GraphQL API 發送一個 Mutation request**。這個 Mutation 會攜帶 TUS 服務為該檔案產生的唯一識別符 `fileId`，以及任何需要與該檔案關聯的 metadata。 **GraphQL API (後端)：** 接收到這個完成通知後，會執行一系列的處理： * 它會根據客戶端提供的 `fileId` 驗證檔案是否確實已成功上傳並存在。 * 接著，它會執行與該檔案相關的後續業務邏輯，例如：將檔案關聯到使用者帳戶，產生縮圖，更新資料庫紀錄，或觸發其他後端處理任務。 * 最終，GraphQL API 會回傳操作是否成功的結果。