前言：昨天的驗證邏輯，還有一個沒處理到的情況

昨天講的驗證邏輯，處理的是「片段數量比預期少」的情況。但這個系列素材專案裡真實遇過另一種相反的狀況：片段數量比預期多。

今日目標

• 認識「數量不吻合」不是只有「少了」這一種可能
• 看真實程式碼怎麼處理「數量比預期多」這種情況
• 反思這種處理方式背後的判斷跟它的侷限

為什麼片段數量會比預期多

回顧 Day 12 的重試邏輯：一個片段重試失敗超過上限後會被放棄，但放棄不等於它完全沒有留下任何檔案——如果失敗發生在寫入檔案的過程中（例如寫到一半才發現內容跟預期長度對不上），加上前面幾天沒有徹底處理乾淨的殘留檔案，理論上就可能讓某個索引位置留下不只一份檔案，或者殘留了不該存在的暫存產物,讓實際檔案數量比 M3U8 清單宣告的片段數量還多。

真實程式碼的處理方式

def is_files_equal(directory, total):
    files = find_ts(directory)
    file_total = len(files)

    if file_total > total:
        for file in files:
            os.unlink(file)
            log.warning(f'{file} deleted')

    return file_total == total

當實際檔案數量比預期多時，這段程式碼的處理方式相當直接：全部刪除、記錄警告，讓下一輪重新下載。這不是一個精緻的處理方式——它沒有嘗試判斷「哪些檔案是對的、哪些是多餘的」，而是選擇「狀態不明的時候，寧可全部重來，也不要保留一個不確定是否正確的中間狀態」。

這個判斷背後的取捨

值得誠實檢視的是，這個做法犧牲了 Day 13 講過的斷點續傳效益——一旦觸發這個分支，之前局部重試、局部驗證省下來的下載成本，這一次全部作廢。但反過來想，當「數量對不上」這種不該發生的情況真的發生時，代表某個假設已經被打破，程式碼此刻已經不確定自己手上的資料是不是可信的——在這種狀態下，選擇保守地全部重來，比繼續嘗試用不確定正確的邏輯去猜測「哪些檔案該留、哪些該丟」更安全。

今日思考題

你的專案裡有沒有類似「驗證結果不是預期中的兩種可能之一（不是全對、也不是全錯），而是第三種意料之外的狀態」的情況？遇到這種狀態時，你的處理方式是嘗試精確修正，還是保守地整批重來？

今日重點回顧

• 數量驗證不能只考慮「比預期少」，「比預期多」也是一種需要處理的意料之外狀態
• 真實案例的處理方式：狀態不明時，選擇保守地全部刪除重來，而不是嘗試精確判斷對錯
• 這個選擇犧牲了斷點續傳的效益，換來的是不必在不確定的狀態下繼續往下走

明日預告

明天是第三部回顧：下載引擎的失敗處理，是設計出來的，不是加出來的。