@leemiyinghao: 當我們在開發 Mosir 的中期，選擇了由社群發展出的一套基於 HTTP `multipart/form-data` 的方案，即 GraphQL Multipart Request Specification。 其核心概念是將傳統的 `application/json` Content Type 轉換為 `multipart/form-data`。一個典型的 `multipart/form-data` 請求會包含以下幾個部分： - **operations 部分**： 包含常規的 GraphQL Query 或 Mutation，其中檔案變數會以 null 或特定的佔位符號表示。 - **map 部分**： 定義 operations 中佔位符號與 multipart 請求中實際檔案部分的對應關係。 - **一個或多個檔案 part**： 每個 part 都包含一個實際的二進位檔案。 透過這種方式，Client 就能在單一 HTTP 請求中，同時傳送 GraphQL 操作的 JSON 資料和二進位檔案，伺服器解析後再將檔案注入到 GraphQL Mutation 的上下文中進行處理。 儘管 GraphQL Multipart Request Specification 解決了在 GraphQL 環境下上傳檔案的需求，但它也繼承了 `multipart/form-data` 的固有缺點，特別是在處理複雜情境時： 1. **缺乏斷點續傳 (Resumable Uploads)**： multipart/form-data 屬於「一次性」的傳輸模式。若檔案在上傳過程中中斷（不論是網路不穩、伺服器重啟或客戶端意外關閉），整個上傳都必須從頭開始。這對於上傳大型檔案（數十 MB 甚至 GB 等級）而言，會導致極差的使用者體驗和大量的資源浪費。 2. **Proxy 和處理的複雜性**： - **Proxy 處理壓力**：如果架構中存在反向代理 (Reverse Proxy) 或 API Gateway，當大型檔案透過 `multipart/form-data` 方式上傳時，代理層需要接收並快取整個檔案請求，然後再轉發給後端服務。這可能對代理層造成巨大的記憶體和頻寬壓力，甚至可能因為代理的快取設定或連線逾時而導致上傳失敗。 - **擴充性考量**：透過代理將大量檔案直接轉發到 GraphQL 服務，可能會使 GraphQL 服務承擔過多與其核心職責無關的 I/O 操作，進而影響其處理 GraphQL 查詢與變更的效率。這也讓檔案上傳的水平擴充變得更為困難。