Cloudflare R2 是 S3 相容的物件儲存服務，可保存圖片、影片、備份和下載檔案。它與一般主機磁碟不同，檔案以 bucket 和 object key 管理。WordPress 不會在建立 bucket 後自動把媒體搬到 R2；仍需要可靠整合、網址重寫、刪除同步和回復方案。
先判斷是否真的需要物件儲存
小型網站若媒體量不大、主機空間充足，加入外部儲存可能只會增加複雜度。R2 較適合大量媒體、跨多台主機、可下載資產或需要分開擴展儲存的網站。先量度現有容量、每月新增量和下載流量。
理解儲存、操作與傳輸成本
R2 按儲存容量及不同類別的讀寫操作計費，直接從 R2 傳出資料通常沒有網際網路 egress 費用。沒有傳輸費不代表完全免費；大量小檔案列出、寫入、讀取和刪除仍會產生操作量，亦要留意計費單位取整。
建立用途單一的 Bucket
將公開媒體、私人下載和備份分開放在不同 bucket，可避免一條公開規則意外暴露敏感檔案。名稱應反映環境與用途，例如正式媒體或測試媒體，但不要放入密碼、客戶名稱或其他敏感資料。
選擇合適的儲存類別
經常顯示的網站圖片適合標準儲存；很少讀取的封存檔案才考慮 Infrequent Access。後者雖然每月儲存價格較低，但可能有資料取回費。不要只看每 GB 價格，應把讀取頻率和操作模式一起計算。
使用專用且最低權限的 API 憑證
WordPress 整合通常透過 S3 相容 API 連接 R2。為每個網站或環境建立獨立憑證，只允許必要 bucket 和操作。Access key 與 secret 應存於伺服器 Secret 或受保護設定，不要寫入文章、公開版本庫或前端 JavaScript。
先在測試站驗證整合
選擇仍有維護並支援 R2 自訂端點的媒體 offload 工具。先測試上載、縮圖、WebP、圖片編輯、替換、刪除和媒體庫搜尋。不要只看到原圖成功便上線，因為 WordPress 一次上載可能建立多個尺寸和衍生格式。
決定是否保留主機本機副本
保留本機副本較容易回復和停用整合，但會繼續佔用磁碟；移除本機可節省空間，卻提高對 R2 和外掛的依賴。遷移初期應先保留副本，完成完整備份及回復演練後再評估刪除。
正式流量使用自訂網域
`r2.dev` 公開網址主要供開發測試並有可變速率限制。正式媒體應連接自訂子網域，例如資產專用網域，才能使用快取、WAF 和存取控制。自訂網域必須與 bucket 位於相容的 Cloudflare 帳戶及區域設定。
公開 Bucket 不等於所有檔案都應公開
公開 bucket 讓知道 object URL 的人讀取內容，不能用於私人發票、會員檔案或付費下載原檔。敏感物件應保持私有，透過後端授權或有時效的簽署網址提供。也要關閉不再需要的開發公開入口。
為瀏覽器跨來源請求設定 CORS
普通 `` 顯示未必需要額外設定，但前端 JavaScript 上載、Canvas、字型或跨網域 API 會受 CORS 影響。只允許實際網站 Origin、必要方法和標頭，不要為解決錯誤便對所有來源全面開放寫入。
快取與更新策略要一致
以內容雜湊或版本化檔名保存長期不變的資產，可設定較長快取；相同 URL 會被覆寫的檔案則需較短 TTL 或主動清除。連接自訂網域後，快取會令直接讀取呈現較寬鬆的一致性，要測試替換檔案後的更新時間。
遷移現有媒體要分批進行
先匯出媒體清單和資料庫備份，以小批量複製物件並重寫網址，再檢查文章、特色圖片、商品圖、PDF 和社交分享圖。不要一次刪除原主機檔案；確定新舊網址映射及回復流程後才逐步釋放空間。
刪除同步與孤立檔案要監察
WordPress 刪除媒體時，整合工具是否同步刪除 R2 物件要明確設定。同步刪除可節省費用但降低復原機會；不同步則會累積孤立檔案。建立保留期、生命週期和定期盤點，而不是永久忽略。
備份不能只依賴同一個 Bucket
R2 是儲存位置，不自動等於完整備份。錯誤權限、同步刪除或憑證被盜仍可能影響物件。資料庫、媒體和設定應有另一個獨立備份位置，並定期還原測試，確保可重建 WordPress 媒體關係。
結語
把 WordPress 媒體遷移到 R2 的可靠次序是：量度需求、分開 bucket、建立最低權限憑證、在測試站驗證衍生圖片，再使用自訂網域和清楚快取策略。保留回復方案與獨立備份，才能在擴展儲存時避免把網站綁死在單一整合。
