Cloudflare R2，個人最容易理解的優點就是：外流量不另外收你一刀
前言
你如果看過幾次雲端帳單，大概就會慢慢發現，真正讓人心臟縮一下的，常常不是存了多少，而是「資料送出去」那筆。
所以 Cloudflare R2 每次被提到，大家第一個記住的幾乎都是同一句：從 R2 往外送資料，不另外收 egress fee。1
這句話聽起來像行銷，但對個人開發者真的很有感。至少你在放圖片、附件、下載檔的時候，不用一開始就被「會不會有人一看就把我流量吃爆」這種焦慮追著跑。
我第一個會想到的場景
我自己想到 R2，腦中冒出來的大概就是這幾類：
- 靜態資產
- 圖片、附件、備份檔
- 網站下載檔
- Worker 後面的簡單物件儲存
如果你現在只是幫 side project 找一個夠直覺、又能跟 Workers 接得順的儲存，R2 真的滿容易進入狀況。
官方怎麼定義它，其實很清楚
官方文件沒有繞彎，R2 就是 object storage，而且賣點也寫得很直白：
- S3 相容
- 可跟 Workers 很順地整合
- 出站流量不另外收費
- 有免費起步空間。1
這幾點對個人很有感，不是只有公司規模大了才會在意。
最省腦的理解方式
如果硬要一句話講完，我會這樣記：
一個比較對個人友善、又很適合跟 Cloudflare 其他服務一起玩的 S3 類物件儲存。
你本來熟 S3 的話，上手通常會很快。
官方文件也直接放了 AWS SDK 的範例，endpoint 也是標準 R2 格式。1
它跟 Workers 黏得很近，這點我很喜歡
在 Worker 裡綁一個 r2_bucket binding 之後，就可以直接讀寫：
1
2
3
4
5
6
7
8
export default {
async fetch(request, env) {
const key = 'hello.txt';
await env.R2.put(key, 'hello');
const object = await env.R2.get(key);
return new Response(object?.body);
}
}
這種感覺很像什麼？不像你在接一個很遠的雲端服務，比較像同一套東西裡面本來就應該這樣接。1
第一次碰的話，我反而不會講太多大道理，直接做這三步比較快：
- 先建一個 bucket
- 先綁進 Worker
- 先測一次
put跟get
走完這條，你對 R2 的感覺通常就不會停留在「喔，一個雲端儲存服務」那麼空。
第一次碰物件儲存，先把幾件小事弄懂
很多人卡住不是因為 API 難，而是有幾個概念一直混在一起：
1. bucket 不是資料夾
bucket 比較像一個容器。裡面的 key 看起來像路徑，但本質上還是 object key。
2. 公開下載跟私有存放是兩回事
你可以把東西存進 R2，但要不要讓外部直接拿到，還牽涉到公開 URL、權限、甚至你是不是要經過 Worker 來控管。
3. 它很適合放檔案，不適合拿來查資料
這聽起來很基本，但真的很多人一開始會忍不住把 object storage 當資料庫用，後面就會很想回頭重做。
哪些情況我會特別推薦把檔案放 R2
1. 網站圖片、附件、下載檔
這種最直覺，而且通常也最容易看到成本差異。
2. 跟 Worker 綁很近的小專案
例如：使用者上傳頭像、暫存匯出檔、備份包。
3. 想先保留 S3 操作習慣
你如果不想整個工作流大改，但又想先試 Cloudflare 生態，R2 很順手。
真正麻煩的，通常不是 API
說起來，這類服務最煩的地方，往往不是怎麼上傳，而是你檔案開始多了之後怎麼收拾。
你檔案一多，後面會開始碰到：
- 命名規則怎麼定
- 上傳失敗要不要重試
- 舊檔要不要清
- 私有檔如何驗證下載權限
- 快取更新時怎麼避免看到舊版本
所以如果你是打算把正式資產放進 R2，我會很建議早一點把 key 命名、版本策略、刪除策略想清楚。這種東西拖久了，最後一定會回頭補，而且通常補得很煩。
遷移這件事，我不太愛一次搬完
如果你原本資料在 S3 或其他物件儲存，我更偏好：
- 先挑一批不太敏感的靜態檔測試
- 先驗證下載流程、快取、Worker 串接是否正常
- 再慢慢把正式流量切過來
這樣排錯比較輕鬆，也比較不會因為某個本來沒注意到的小地方，整站一起受影響。
近一年的一些新動向
Cloudflare 這一年對 R2 也還在持續補東西。像 R2 Local Uploads 在 2026 年 2 月進 open beta，這種更新看起來不浮誇，但對實際上手的人很有感。3
畢竟產品最怕的不是功能少，而是你摸起來一直卡手。R2 現在給我的感覺，是它有在往「比較順手」這個方向慢慢修。
哪些場景我會優先選 R2
1. 靜態檔案很多，又不想被 egress 嚇到
2. 本來就已經用 Workers
3. 想保留 S3 相容的操作習慣
這三種情境下，我自己會很自然先看 R2。
哪些地方要先想清楚
1. 它不是萬用資料庫
這是 object storage，不是拿來當查詢型資料庫。
2. 如果你已經綁很深 AWS 生態，遷移成本要算
3. 雖然出站流量友善，但整體架構還是要想
例如權限、公開連結、快取策略、Worker 怎麼接，這些都還是要規劃。
我對 R2 的觀感一直不差，說穿了是因為它沒有太多花拳繡腿。
多數時候，你只是想把檔案放好，讀寫順一點，帳單不要莫名其妙冒出一刀。從這個角度看，R2 的確抓到很多個人開發者最在意的那一塊。