隨著時間的推移，儲存在 OSS 中的資料訪問熱度通常會逐漸降低。若持續使用高成本的標準儲存儲存冷資料，或依賴人工清理大量日誌、備份檔案，既不經濟，效率也低。生命週期管理功能允許您建立自動化規則，在檔案滿足特定條件（如建立超過30天）後，自動將其轉換為成本更低的儲存類型（如低頻、歸檔），或直接刪除，實現智能化、低成本的資料全生命週期管理。
工作原理
生命週期管理通過使用者定義的規則，對儲存空間（Bucket）內的檔案（Object）進行自動化操作。生命週期規則建立後的24小時內，OSS會載入規則。規則載入完成後，OSS 會在固定的時間周期（通常是次日 UTC 時間 0點，即北京時間 8 點後）掃描並執行合格規則。
一條生命週期規則主要由三部分構成：
控制對象： 定義規則對哪些檔案生效，可基於檔案首碼（Prefix）、對象標籤（Tag）、或檔案大小（ObjectSize）來篩選目標檔案。
生命週期規則目前不支援萬用字元匹配、尾碼匹配以及正則匹配。
執行動作： 定義對篩選出的檔案做什麼操作。主要包括：
儲存類型轉換（Transition）： 將檔案轉儲到低頻訪問、歸檔、冷歸檔等更低成本的儲存類型。
到期刪除（Expiration）： 檔案達到指定生命週期後將其刪除。
清理片段（AbortMultipartUpload）： 自動刪除超過指定時間仍未合并的分區上傳任務。
觸發策略：定義對篩選出的檔案基於什麼條件觸發：
最後一次修改時間（Last-Modified-Time）： 根據檔案的最後修改時間為基準進行儲存類型轉換和刪除，適用於日誌、備份等生命週期明確的資料，可自動進行儲存類型轉換或刪除以節省成本。
最後一次訪問時間（Last-Access-Time）：啟用訪問跟蹤功能後，根據檔案的最近訪問時間智慧切換儲存類型，適合訪問模式不確定的情境，如素材庫。可在資料冷卻時降級，訪問時自動回復。
可參考生命週期配置元素配置生命週期策略。
配置生命週期
自動清理到期的記錄檔
伺服器每天會產生大量日誌並上傳至指定目錄。您可配置基於最後修改時間的生命週期規則，在達到指定天數後刪除Bucket內的所有Object，釋放儲存空間、降低儲存成本。
資料的冷熱階層式存放區
對於訪問頻率不確定的資料（如網站圖片、線上視頻、文檔等），建議啟用訪問跟蹤功能，並使用最後一次訪問時間的生命週期規則實現資料智能分層。系統將根據實際訪問情況，自動將冷資料轉入低頻、歸檔或冷Archive Storage，實現智能分層與成本最佳化。
自動清理歷史版本
開啟版本控制後，針對資料的覆蓋和刪除操作將會以歷史版本的形式儲存下來。當Bucket累積了大量的歷史版本或者到期刪除標記時，可使用最後一次修改時間的生命週期規則結合版本控制降低儲存成本，在檔案達到指定時間後自動刪除，從而減少儲存成本並有效提升列舉Object的效能。
自動清理上傳時產生的片段
在使用分區上傳大檔案過程中，若上傳中斷，系統會保留未合并的分區（Part），這些分區將持續計費。可配置生命週期規則自動清理超過指定時間的未完成分區，避免不必要的資源佔用。
除上述情境外，如需實現更精細的資料管理策略，您可參考生命週期配置樣本，根據業務需求組合不同規則，實現對 Bucket 中資料的精細化管理。
多條生命週期規則
為確保配置的多條生命週期規則按預期生效，需要理解兩個核心機制：規則的執行優先順序和配置的覆蓋機制。
規則執行優先順序
同一個Bucket可以配置多條生命週期規則，且規則之間互不影響。因此，同一個Object可能會命中多條規則，需根據所有規則的命中結果決定最終操作。
當多條規則同時匹配同一檔案時，按以下優先順序執行：刪除 Object > 轉為深度冷歸檔 > 轉為冷歸檔 > 轉為歸檔 > 轉為低頻訪問 > 轉為標準。
刪除操作始終優先於儲存轉換。建議將刪除規則的時間設定得比轉儲規則更長，避免檔案在轉儲完成前被刪除。
執行樣本
假設指定了以下兩條生命週期規則，且兩條規則均命中相同的Object。
規則1：指定將最後一次修改時間超過365天的Object轉為低頻訪問類型。
規則2：指定將最後一次修改時間超過365天的Object刪除。
執行結果：規則命中的Object將在距離其最後一次修改時間超過365天后刪除。
配置的覆蓋機制
在使用控制台時，無需關心配置覆蓋問題。每次新增、修改規則時，控制台會自動讀取當前配置併合並後提交，避免誤操作導致原有規則丟失。但在使用 ossutil、SDK或直接調用 API 的方式配置生命週期規則時，需格外注意：每次調用 PutBucketLifecycle 都會完全覆蓋當前 Bucket 的所有生命週期配置，若只提交新規則而未包含原有規則，將導致原有規則被刪除並失效。
樣本說明
如果您希望在已有規則的基礎上新增一條規則，需按以下步驟操作：
擷取 當前已生效的所有生命週期規則（例如規則1）
添加 新規則（例如規則2）
重新提交 包含全部規則（規則1 + 規則2）的完整配置
注意：如果僅提交包含新規則（規則2）的配置，而未包含原有規則（規則1），則規則1會被刪除，不再生效。
應用於生產環境
為確保在生產環境中安全、高效地使用生命週期管理，建議：
先測試，後部署： 強烈建議先在測試 Bucket 中建立規則，驗證其行為完全符合預期後，再應用到生產環境的 Bucket。
謹慎使用刪除規則： 對配置了到期刪除的規則，務必精確設定首碼，避免規則範圍擴大導致重要資料被意外刪除。
開啟版本控製作為保障： 對於關鍵業務資料，建議開啟 Bucket 的版本控制功能。這樣，即使目前的版本檔案被生命週期規則誤刪，仍有機會從歷史版本中恢複資料。
階梯式轉換避免額外費用： 在設計儲存類型轉換策略時，確保後一階段的觸發時間晚於前一階段的觸發時間與該儲存類型最低儲存時間長度之和，以避免提前轉換帶來的費用。
錯誤樣本： 標準儲存
30天-> 低頻儲存40天-> Archive Storage。此配置會導致低頻檔案僅儲存10天（< 30天）就被轉走，從而產生費用。正確樣本： 標準儲存
30天-> 低頻儲存90天-> Archive Storage。（30天轉為低頻，再經過60天滿足歸檔最低要求，共90天）。
計費說明
配置生命週期規則本身不收費。費用產生於規則被執行時以及執行後帶來的儲存狀態變化。
請求費用：當生命週期規則執行儲存類型轉換、刪除Object或刪除Part操作時，系統會發起
Put類型請求調用，並按請求次數收取請求費用，計費規則可參考生命週期費用說明。對於包含海量小檔案的 Bucket，此費用可能較為顯著，請在配置前進行評估。
儲存費用：檔案轉換到新儲存類型後，將按新類型的單價計費。
重要低頻、歸檔、冷歸檔等儲存類型有最低儲存時間長度要求（如低頻為30天，歸檔為60天）。如果生命週期規則在檔案存滿最低時間長度之前就將其刪除或再次轉換，需要支付剩餘天數的儲存費用作為補償。為避免產生轉儲或者刪除產生的不足規定時間長度容量費用（條件），可參考如何避免產生儲存不足規定時間長度容量費用？，確保滿足其最低儲存時間長度後再進行轉儲或者刪除。
資料取回費用：生命週期規則本身不會產生資料取回費用。但檔案被轉換為低頻、歸檔等類型後，在訪問這些檔案時，會產生相應的資料取回費用。
直接讀取低頻的Object會產生資料取回費用。
直接讀取歸檔的Object會產生歸檔直讀資料取回容量費用。
解凍歸檔類型的Object會產生Put類型請求次數費用和資料取回容量費用。
解凍冷歸檔、深度冷歸檔類型的Object會產生取回請求次數費用、取回容量費用和臨時解凍容量費用。
重要冷歸檔和深度冷歸檔的object，選擇不同的取回優先順序收費不同。優先順序越高收費越貴。
常見問題
Bucket未開啟版本控制
對於未開啟版本控制的Bucket，只需要配置一條生命週期規則，即可自動快速清理所有檔案和片段（Multipart Upload產生的未合并片段）。
登入OSS管理主控台的Bucket列表頁面，找到目標Bucket。
在左側導覽列，選擇，確認Bucket未開啟版本控制。
在左側導覽列，選擇，設定生命週期規則，指定Bucket內所有檔案在最後一次修改後1天自動刪除，同時對產生時間早於1天的檔案片段，自動執行清理操作。
Bucket已開啟版本控制
Bucket開啟版本控制後，會產生目前的版本檔案、歷史版本檔案、片段檔案和刪除標記。只需要配置一條生命週期規則，即可自動快速清理這些檔案。
登入OSS管理主控台的Bucket列表頁面，找到目標Bucket。
在左側導覽列，選擇，確認Bucket已開啟版本控制。
在左側導覽列，選擇，設定生命週期規則，指定Bucket內所有目前的版本、歷史版本檔案在最後一次修改後1天自動刪除，同時對產生時間早於1天的檔案片段，自動執行清理操作。該規則會同步清理刪除標記。
