本頁面提供 Cloud Storage 最佳做法的索引。您可以將此處收集的資訊做為快速參考，瞭解建構使用 Cloud Storage 的應用程式時，應注意的事項。
如果您才剛開始使用 Cloud Storage，本頁可能不是最佳起點，因為這裡不會說明 Cloud Storage 的基本使用方式。如果您是新使用者，建議先參閱「使用 Google Cloud 控制台探索物件儲存庫」或「使用 Google Cloud CLI 探索物件儲存庫」。
如需媒體工作負載的最佳做法，請參閱「媒體工作負載最佳做法」。
命名
如要瞭解名稱規定和注意事項，請參閱「Bucket 命名」和「Object 命名」。
流量
針對會傳送到 Cloud Storage 的流量進行簡便計算。具體來說，請將下列項目納入考量：
每秒作業數。對於值區和物件的建立、更新和刪除作業，您預期每秒會執行多少次作業。
頻寬。要傳送多少資料？在什麼時間範圍內傳送？建議您使用 Wolfram Alpha 等工具，避免計算錯誤。
快取控制。在可公開存取的物件上指定
Cache-Control中繼資料，有助於縮短熱門或經常存取物件的讀取延遲時間。如要瞭解如何設定物件中繼資料 (例如Cache-Control)，請參閱「查看及編輯中繼資料」。
妥善設計您的應用程式以降低流量尖峰的情況。如果您應用程式的用戶端正在進行更新，請將更新作業分散在一天中進行。
為高要求率設計應用程式時，請注意特定作業的速率限制。瞭解特定類型輸出的頻寬限制，並遵守要求比率和存取權分配指南。請特別留意自動調度資源，以及需要逐步提高要求比率，才能達到最佳效能。
處理錯誤時：
請確保應用程式使用重試策略，以免因流量突然暴增而發生問題。
請使用新的連線重試，並可能重新解析網域名稱。這有助於避免「伺服器黏性」，即重試嘗試通過相同路徑，並命中初始要求命中的相同不健康元件。
如果應用程式對延遲時間很敏感，請使用對沖要求。避險要求可讓您更快重試，並減少尾端延遲。同時不會縮短要求期限，以免要求過早逾時。詳情請參閱「The Tail at Scale」。
瞭解顧客對應用程式效能的期望。建立新 bucket 時，您可以參考這項資訊，選擇儲存空間選項和區域。舉例來說，您可以考慮將運算資源與 Cloud Storage bucket 放在相同位置，以便執行數據分析應用程式。
位置和資料儲存選項
如要瞭解如何以最佳方式儲存資料，請參閱「儲存空間級別」和「值區位置」主題。
ACL 和存取控管
Cloud Storage 要求必須透過值區和物件的名稱來參照值區和物件。因此，即使 ACL 可防止未經授權的第三方對 bucket 或物件執行操作，第三方仍可嘗試使用 bucket 或物件名稱提出要求，並透過觀察錯誤回應來判斷其是否存在。這樣一來，值區或物件名稱中的資訊就有洩漏之虞。如果您對值區或物件名稱的隱私有所疑慮，則應採取適當的預防措施，如同下列事項：
選用難以猜到的值區和物件名稱。例如像
mybucket-gtbytul3這樣的值區名稱就具備足夠的隨機性，可讓未經授權的第三方無法輕易猜到該名稱，或是難以從中推導出其他值區名稱。避免在 bucket 或物件名稱中使用私密資訊。舉例來說，與其將值區命名為
mysecretproject-prodbucket，不如取名為somemeaninglesscodename-prod。在某些應用程式中，您也不妨將敏感的中繼資料放在x-goog-meta等 自訂 Cloud Storage 標頭中，而不要將這些資訊編入物件名稱中。
相較於明確列出大量使用者，使用群組是較好的做法。這樣不僅能夠更完善調整，也提供非常有效的方法來同時更新大量物件的存取控管。最後，由於您不必為每個物件提出要求來變更 ACL，因此費用較低。
詳閱並遵循存取控管最佳做法。
Cloud Storage 存取控管系統可指定物件是否可公開讀取。請確認您要使用這項權限寫入的任何物件都是公開的。網際網路上的資料一旦「發布」，就可能複製到許多地方，因此實際上無法重新取得以這項權限寫入的物件讀取控制權。
Cloud Storage 存取控管系統可指定 bucket 為公開可寫入。雖然以這種方式設定 bucket 可方便用於各種用途，但我們不建議使用這項權限，因為這項權限可能會遭到濫用，用於散布非法內容、病毒和其他惡意軟體，而且 bucket 擁有者必須對儲存在其 bucket 中的內容承擔法律和財務責任。
如要安全地向沒有使用者帳戶的使用者提供內容，建議您使用經簽署的網址。舉例來說，您可以使用經簽署的網址提供物件連結，這樣應用程式的客戶就不需要向 Cloud Storage 驗證身分，即可存取物件。建立經簽署的網址時，您可以控管存取權類型 (讀取、寫入、刪除) 和存取權效期。
資料上傳
如果您使用 XMLHttpRequest (XHR) 回呼來取得進度更新，請勿在偵測到進度停滯時關閉並重新開啟連線。這樣做會在網路壅塞時建立不良的正向回饋循環。網路壅塞時，XHR 回呼可能會在上傳串流的確認 (ACK/NACK) 活動後積壓，此時關閉並重新開啟連線會耗用更多網路容量，而這正是您最無法負擔的時候。
我們建議您針對上傳流量，設定合理長度的逾時。為提供良好的使用者體驗，您可以設定用戶端計時器，在應用程式長時間未收到 XHR 回呼時，以訊息 (例如「網路壅塞」) 更新用戶端狀態視窗。發生這種情況時，請勿直接關閉連線並重試。
要減少每個要求占用的頻寬，最簡便的方法就是啟用 gzip 壓縮。雖然此方法需要額外的 CPU 作業時間來擷取結果，但相對可省下可觀的網路成本。
以 gzip 格式上傳的物件通常也能以 gzip 格式放送。不過，請避免上傳同時包含
content-encoding: gzip和壓縮content-type的內容，因為這可能會導致非預期行為。建議使用支援續傳的上傳作業，即使通訊問題導致資料傳輸過程遭到中斷，之後仍可繼續傳輸資料。您也可以使用 XML API 分塊上傳功能，平行上傳檔案的多個部分，這可能會縮短完成整體上傳作業所需的時間。
資料刪除作業
如需刪除資料的指南和注意事項，請參閱「刪除物件」。您也可以使用資料生命週期控管功能，防止應用程式軟體或使用者誤刪資料。