第 2 章 上傳路徑：分割、並發與復原（重點）
在上傳方面，目標是在網路波動的情況下盡可能接近“頻寬飽和”，同時將故障成本限制在最低限度（僅重傳失敗的區塊）。 這兩個目標在很大程度上解釋了為什麼上傳感覺更快。
2.1 分塊
- 客戶端必須將檔案分割成多個區塊； chunk 是上傳/重試的最小單位。
- 區塊應該使用固定大小（或按檔案大小策略）來簡化並發調度和狀態表示。
- 直接好處：任何故障僅影響一個區塊，而不是整個檔案。
2.2 並行上傳
並發的目的不是“更多線程”，而是為了避免實際網路中單一連接的三個實際限制：
- 緩慢啟動和視窗增長： 單一連接增長緩慢，尤其是在跨區域 RTT 較高的情況下。
- 鏈路抖動： 一個連接上的抖動會降低整體速度；並發使效果變得平滑。
- 每流整形： 一些網路限制單一流量；多個流可以更接近頻寬上限（在合規性限制內）。
- 客戶端應該使用有限的並發性（例如 4-12），並在較弱的設備上降低並發性以避免記憶體峰值。
- 客戶端可以調整並發：當吞吐量增加時增加；當錯誤率上升時下降。
2.3 冪等性和重試
- 同一塊的重複上傳必須是冪等的：重複提交不得破壞已完成的狀態。
- 伺服器應該使用（transferId，fileId，chunkIndex）或等效約束來強制唯一性。
- 客戶端必須實現指數退避重試；失敗應該只重試失敗的區塊。
2.4 斷點續傳
- 伺服器必須能夠回答“哪些區塊已經上傳”，以便客戶端可以跳過已完成的區塊。
- 上傳的集應該表示為點陣圖/範圍集，以避免狀態大小隨區塊計數線性增長。
- 速度優勢：網路中斷、瀏覽器崩潰或網路切換後，復原不會從0%重新開始。
2.5「上傳時分享」（可選）
- 系統可以在上傳仍在進行時產生可用的傳輸標識符並共享鏈接，以加速交付工作流程。
- 如果在上傳完成之前允許共享，則必須明確收件者所看到的內容：不完整的內容尚無法下載，或僅顯示進度。