為了提高大檔案上傳效率，OSS提供了兩種大檔案上傳方法，分別是斷點續傳上傳和分區上傳。本文將概述這兩種上傳方法，並提供相關文檔連結供進一步參考。
注意事項
傳統的簡單上傳方法（如 PutObject）上傳大檔案會遇到以下問題：
最大對象大小限制：OSS 對單個對象的大小有限制，超過5GB的檔案無法通過簡單的
PutObject方法直接上傳。嘗試上傳超過5GB的檔案會導致操作失敗。上傳時間：上傳大檔案可能需要較長的時間，尤其是在較慢的網路連接下。長時間的傳輸容易受到網路波動的影響，可能導致傳輸中斷或逾時問題。
記憶體消耗：上傳大檔案可能導致記憶體消耗增加，特別是在使用較小的記憶體配置或受限的環境中，這會影響系統的穩定性和效能。
因此，在處理大檔案上傳時，推薦使用斷點續傳上傳或分區上傳方法，以提高上傳效率和可靠性。
斷點續傳
斷點續傳上傳是一種高效的大檔案上傳方法，特別適用於網路連接不穩定或檔案大小超過5GB的情況。這種方法自動將檔案分割成多個較小的分區，並進行並發上傳，整個過程無需使用者幹預。如果上傳過程中發生中斷，可以從最後一次成功的上傳位置繼續，避免了重新上傳整個檔案，從而顯著提高了上傳效率和可靠性。
分區上傳
分區上傳是一種常用的大檔案上傳方法，使用者需要先將大檔案手動分割成多個分區，然後使用分區上傳系列介面進行上傳。與斷點續傳上傳相比，分區上傳提供了更高的靈活性，允許使用者在上傳過程中動態調整分區大小，並且可以在中途取消分區上傳任務。這種方法適用於需要更精細化控制上傳過程的情境。
方法比較
特性 | 斷點續傳上傳 | 分區上傳 |
適用情境 | 希望簡單快速即可完成大檔案上傳任務，不關注具體細節的使用者 | 需要精細化控制且有技術能力的使用者 |
並發上傳 | 支援 | 支援 |
斷點續傳 | 支援，可以從斷點處繼續上傳 | 不直接支援斷點續傳 |
分區大小 | 需要預設分區大小 | 可以動態調整分區大小 |
可靠性 | 高，減少因網路波動導致的上傳失敗 | 較高，但仍需手動處理斷點 |
管理難度 | 低，只需調用一個UploadFile上傳函數 | 高，需要調用InitiateMultipartUpload, UploadPart, CompleteMultipartUpload等函數 |
靈活性 | 一般，不支援精細化控制上傳流程 | 高，支援手動控制上傳流程，便於即時監控分區上傳的活動 |
開發便利性 | 極高，只需調用一個上傳函數即可完成大檔案的上傳 | 較低，需要手動對大檔案進行分區，編寫更多的控制邏輯調用多個介面完成分區上傳，並且需要處理各種異常情況 |