作者：張醫博
什麼是 404
404 标準的 http code 狀态碼，代表使用者請求的資源在服務端不存在， 404 并不是一個異常狀态碼？而是一個正常的響應。換句話說 404 已經成為了一個結果，這種響應常見在 client 端下載下傳 OSS 的資源時出現。
做好預防
很多情況如果服務端的曆史日志儲存時間有限，那麼出現問題時也無法查證，是以建議使用 OSS 先把日志功能開啟，将 OSS 每天的資料都自動備份到使用者指定的目錄下，費用低廉。
why 404
- 檢查 用戶端提供的 objectname 是否正确，確定不存在低級的拼寫錯誤。
- 用戶端之前上傳是否成功，如果成功 OSS 會傳回 requestid，凡事沒有 requestID 的并不能保證已經上傳到 OSS 成功。
- 用戶端可以根據開啟的 log 查詢下對應時間點 OSS 出現 404 的情況。
- OSS 是否開啟過 生命周期 功能，開啟這個功能，觸發生命周期管理規則後，會将滿足條件的 URL 完全上除掉。
用戶端上傳成功，但是下載下傳傳回 404
首先這種情況是不存在，如果已經上傳到 OSS 的檔案，除了會備援寫多份，也受到權限的嚴格限制，匿名非法的通路是不可能直接删除的，除非使用者自己把 bucket 設定為公共讀寫（高危權限）
一般對上傳成功有個誤區，認為傳回 200 就代表檔案已經上傳成功其實這并不準确。會造成兩種情況
- 收到狀态碼 200 的情況後立刻取請求 OSS ，傳回了 404 ，等一會再通路就 200 ，懷疑到 OSS 傳回 200 和真實的寫入成功不同步。
- 上傳成功收到 200 狀态碼，但通路一直都是 404
- 分片上傳或者斷點續傳已經收到了 200 并切有 requestID 的情況下，通路 OSS 仍然傳回 404。
其實以上兩種情況都是對傳回狀态的判斷不準确導緻，可靠的判斷方式是，if result.status==200 && result.requestID != None 的情況下才是上傳成功。有的 http 請求被 http 劫持的情況下會收到一個僞造的 200 狀态碼并不是真實的傳回。
另外分片上傳或者斷點續傳比叫特殊，是采用将原檔案切片的形式上傳，每一個分片 multipart 上傳成功都會傳回 200 和 requestID，這種情況應該以 complete 合并分片後傳回的 200 & requestID 為準。
極特殊的情況是用戶端使用分片上傳時對用的 uploadID 憑證是 A，但是完成合并時用的 uploadID 憑證是 B，OSS 找不到原始的 A 憑證，是以報 404 無法完成上傳。
檔案之前一直存在，突然通路 404
有以下幾個原因
- 用戶端的子賬号有權限，把 OSS 的檔案删除了。
- 具備客戶合法的 AK SK 通過 API 删除了。
- 具備合法賬号密碼的人在控制台删除了。
- 擁有者設定過生命周期過期被删除了。
- bucket 和其他 bucket 有跨區複制的關系，其他的 bucket 執行了删除操作，同步到目前的 bucket，是以檔案被删除。