你是不是也遇到過(guò)，上傳個(gè)幾百M(fèi)的安裝包或者設(shè)計(jì)稿，眼瞅著進(jìn)度條走到99%，然后……網(wǎng)絡(luò)波動(dòng)一下，啪，沒(méi)了！又要從頭再來(lái)？相信我，這種崩潰的感覺(jué)我太懂了。

最近剛好在弄文件上傳的小工具，又把這塊硬骨頭啃了一遍。今天不聊虛的，就把我這次用 FastAPI 和 Vue 實(shí)現(xiàn)大文件分片上傳的完整思路，還有踩過(guò)的坑，都倒出來(lái)給你聽(tīng)。

?? 核心摘要：讀完你能帶走什么？

這篇文章不會(huì)給你扔一堆晦澀的概念就跑。我會(huì)用講故事的方式，跟你講明白：

?? 分片上傳到底是怎么一回事兒，原理是啥。

?? 秒傳和斷點(diǎn)續(xù)傳的核心邏輯（其實(shí)就隔一層窗戶紙）。

?? 一份可以直接復(fù)制粘貼拿去用的 FastAPI 后端核心代碼。

?? 一份 Vue3 前端的實(shí)現(xiàn)思路和關(guān)鍵代碼片段。

??? 主要內(nèi)容脈絡(luò)

1?? 從一次抓狂的上傳失敗說(shuō)起

2?? 別再盯著進(jìn)度條了：聊聊分片、哈希與秒傳

3?? 后端實(shí)戰(zhàn)：FastAPI如何像收快遞一樣收文件

4?? 前端實(shí)戰(zhàn)：Vue里那把切文件的“菜刀”

5?? 跑起來(lái)！以及那些年我踩過(guò)的坑

6?? 結(jié)尾碎碎念

1?? 從一次抓狂的上傳失敗說(shuō)起

手機(jī)上傳一段視頻到電腦，“每次到一半就掛” 我一看日志， 413 Request Entity Too Large ，Nginx和FastAPI雙雙攔截。

調(diào)整配置大小限制？那是治標(biāo)不治本，大文件上傳慢、易失敗是HTTP協(xié)議天生的短板。

這就是為啥我們需要 分片上傳。

思路特簡(jiǎn)單：把大象放進(jìn)冰箱要幾步？不對(duì)，是把大文件切成小塊，一塊塊傳，最后在服務(wù)端拼起來(lái)。

2?? 別再盯著進(jìn)度條了：聊聊分片、哈希與秒傳

好，咱們先來(lái)理順幾個(gè)核心概念，別急著寫代碼。

?? 文件切片（Blob.slice）

瀏覽器里，我們可以用 file.slice() 方法，像切西瓜一樣把一個(gè) File 對(duì)象切成一個(gè)個(gè) Blob 。比如設(shè)定每片5MB，一個(gè)100MB的文件就變成了20個(gè)小塊。

?? 文件哈希（Spark-MD5）

接下來(lái)重點(diǎn)來(lái)了！文件指紋，也就是MD5值。 這玩意兒是文件的唯一身份證號(hào)。你可能會(huì)問(wèn)，為啥要算這個(gè)？

一是為了 秒傳：后端一看，“喲，這個(gè)MD5我數(shù)據(jù)庫(kù)里有啊，文件存著呢！” 直接告訴你“傳完了”，用戶體驗(yàn)瞬間起飛。
二是為了 校驗(yàn)：確保服務(wù)端拼起來(lái)的文件沒(méi)缺胳膊少腿。

這里千萬(wàn)別學(xué)我當(dāng)初偷懶，想著用 文件名+修改時(shí)間 來(lái)當(dāng)唯一標(biāo)識(shí)，結(jié)果用戶把文件重命名一下，或者換個(gè)文件夾上傳，后端就傻傻地又存了一份一模一樣的垃圾數(shù)據(jù)。

?? 斷點(diǎn)續(xù)傳

原理就是每次上傳前，先拿MD5去問(wèn)后端：“我這文件，哪些片你已經(jīng)有了？”
后端返回一個(gè)數(shù)組，比如 [0, 1, 3] ，意思就是第0、1、3片傳過(guò)了。前端直接跳過(guò)這些片，從第2片開始傳。

是不是以為這樣就完了？對(duì)，核心就這么簡(jiǎn)單！

3?? 后端實(shí)戰(zhàn)：FastAPI如何像收快遞一樣收文件

咱們后端用的是 Python 界的當(dāng)紅炸子雞 FastAPI，它處理文件上傳異步非阻塞，性能杠杠的。

?? 檢查分片接口（實(shí)現(xiàn)秒傳+斷點(diǎn)續(xù)傳）

@app.post("/upload/check")
async def check_chunks(file_hash: str, total_chunks: int):
    # 1. 去數(shù)據(jù)庫(kù)查這個(gè)hash
    file_record = await db.get_file_by_hash(file_hash)
    if file_record:
        # 如果存在完整文件記錄，直接返回秒傳信號(hào)
        return {"status": "success", "code": 200, "data": {"uploaded": True}}
    # 2. 不存在，就去磁盤找臨時(shí)分片文件夾
    temp_dir = Path(f"temp/{file_hash}")
    uploaded_chunks = []
    if temp_dir.exists():
        for chunk_file in temp_dir.iterdir():
            # 文件名約定為 chunk_index
            uploaded_chunks.append(int(chunk_file.stem))
    return {"status": "success", "data": {"uploaded": False, "uploaded_chunks": uploaded_chunks}}

再說(shuō)個(gè)容易翻車的點(diǎn)： 臨時(shí)文件夾的路徑設(shè)計(jì)。
千萬(wàn)別把所有分片都扔一個(gè)文件夾里，文件多了系統(tǒng)查找速度會(huì)變慢。按 file_hash 的前兩位或者直接建一個(gè)同名文件夾，是最穩(wěn)妥的做法。

?? 上傳分片接口

@app.post("/upload/chunk")
async def upload_chunk(
    file: UploadFile = File(...),
    file_hash: str = Form(...),
    chunk_index: int = Form(...),
):
    temp_dir = Path(f"temp/{file_hash}")
    temp_dir.mkdir(exist_ok=True)
    chunk_path = temp_dir / str(chunk_index)
    # 把上傳的分片內(nèi)容異步寫入磁盤
    with open(chunk_path, "wb") as f:
        while content := await file.read(1024 * 1024): # 1MB一讀
            f.write(content)
    return {"status": "success", "chunk_index": chunk_index}

?? 合并分片接口

@app.post("/upload/merge")
async def merge_chunks(file_hash: str, file_name: str, total_chunks: int):
    temp_dir = Path(f"temp/{file_hash}")
    target_path = Path(f"uploads/{file_hash}_{file_name}")
    # 注意：要按照分片索引順序?qū)懭耄?
    with open(target_path, "wb") as target_f:
        for i in range(total_chunks):
            chunk_path = temp_dir / str(i)
            with open(chunk_path, "rb") as chunk_f:
                target_f.write(chunk_f.read())
    # 清理臨時(shí)分片和文件夾（這里可以用 shutil.rmtree）
    # 校驗(yàn)MD5是否一致...
    # 寫入數(shù)據(jù)庫(kù)記錄...
    return {"status": "success", "code": 200}

4?? 前端實(shí)戰(zhàn)：Vue里那把切文件的“菜刀”

前端我用的是 Vue3 + Element Plus ，核心庫(kù)是 spark-md5 。

?? 第一步：切肉，不對(duì)，切文件并計(jì)算Hash

計(jì)算大文件的MD5是個(gè)CPU密集型任務(wù)，如果直接卡在主線程，頁(yè)面會(huì)直接假死。
官方文檔雖然建議用 Worker，但根據(jù)以往的經(jīng)驗(yàn)，不用 Worker 而是用 requestIdleCallback 或者分片讀取計(jì)算，對(duì)小幾G的文件來(lái)說(shuō)，體驗(yàn)也是OK的，代碼還少。

// 偽代碼示例，思路最重要
const CHUNK_SIZE = 5 * 1024 * 1024; // 5MB一片
async function handleUpload(file) {
  const chunks = createChunks(file);
  // 計(jì)算Hash (這里略去具體SparkMD5的增量計(jì)算代碼，否則太長(zhǎng)了)
  const fileHash = await computeHash(chunks);
  // 1. 檢查是否秒傳或需要斷點(diǎn)續(xù)傳
  const { uploaded, uploadedChunks } = await checkChunksApi(fileHash, chunks.length);
  if (uploaded) {
    ElMessage.success('文件秒傳成功！');
    return;
  }
  // 2. 過(guò)濾出未上傳的分片
  const pendingChunks = chunks.filter((_, index) => !uploadedChunks.includes(index));
  // 3. 并發(fā)上傳 (千萬(wàn)別同時(shí)全發(fā)出去，要控制并發(fā)數(shù)，比如一次最多6個(gè))
  await uploadChunksWithPool(pendingChunks, fileHash, 6);
  // 4. 通知后端合并
  await mergeChunksApi(fileHash, file.name, chunks.length);
  ElMessage.success('總算傳完了，合并成功！');
}

這個(gè)工具的選擇，好比選螺絲刀，不是最貴的最好，而是最順手的。這里用 spark-md5 完全夠用，別為了高大上去引入一整套 crypto-js，太重了。

5?? 跑起來(lái)！以及那些年我踩過(guò)的坑

?? 坑一：分片大小怎么定？

別設(shè)太小，比如100KB，那樣請(qǐng)求數(shù)爆炸，瀏覽器并發(fā)扛不住，后端壓力也大。也別太大，失去斷點(diǎn)續(xù)傳的意義。個(gè)人經(jīng)驗(yàn)， 5MB 或 10MB 是個(gè)很舒服的區(qū)間。

?? 坑二：合并文件時(shí)的順序！

后端合并分片時(shí)，千萬(wàn)注意要按照 chunk_index 從小到大寫入。如果你用了 os.listdir() 然后直接遍歷，系統(tǒng)返回的順序可能是亂的，拼出來(lái)的文件就壞了。我就這么壞過(guò)一個(gè)3個(gè)G的模型包，血淚教訓(xùn)啊！

?? 坑三：并發(fā)上傳控制

瀏覽器對(duì)同一域名的并發(fā)連接數(shù)是有限制的（HTTP/1.1一般是6個(gè)）。如果你 for 循環(huán)里直接發(fā)幾百個(gè)請(qǐng)求，后面的請(qǐng)求全得排隊(duì)，甚至直接失敗。一定要寫個(gè)簡(jiǎn)單的請(qǐng)求池，控制同時(shí)在傳的分片數(shù)。

?? 結(jié)尾碎碎念

大文件上傳這玩意兒，看著唬人，其實(shí)拆解開來(lái)就三件事：切、傳、合。核心難點(diǎn)都在異常處理和細(xì)節(jié)的打磨上。希望我今天掏心窩子的這些分享，能讓你在實(shí)現(xiàn)這個(gè)功能時(shí)，少熬幾個(gè)大夜，少掉幾根頭發(fā)。

如果你在實(shí)際操作中遇到了什么妖魔鬼怪的問(wèn)題，或者有更好的實(shí)現(xiàn)思路，歡迎隨時(shí)留言找我嘮嗑。技術(shù)在交流中才會(huì)變得更有趣嘛。

到此這篇關(guān)于FastAPI+Vue：文件分片上傳+秒傳+斷點(diǎn)續(xù)傳，這坑我?guī)湍悴绕搅?！的文章就介紹到這了,更多相關(guān)FastAPI Vue分片上傳內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論