事實
網路基礎設施 · 軟體工程 · 資訊安全 · 工程簡報Tratopedia · 2026 年 8 月 16 日
Cloudflare 把 cdnjs 搬到自家開發者平台
每日 90 億次請求，搬家時一個檔案都沒有重建
2026 年 6 月 23 日起，cdnjs 全面改在 Cloudflare 自家的開發者平台上運行；7 月 30 日 Cloudflare 發表了整個過程。搬遷是標題，回滾才是心得。先前一次嘗試把舊有檔案重新處理，最後不得不放棄——因為壓縮與最小化工具在不同版本間並非決定性的，重新產生的每一個檔案都得到不同的完整性雜湊；對任何把雜湊寫死在網頁裡的人來說，那不是差異，是一片空白。
- 23 Jun 2026全面上線開發者平台；37 天後才公開
- 108,000/s每秒請求數，約每日 90 億次
- 98.6%快取命中率——每日仍約有 1.26 億次請求越過快取
- 1.1 TBGitHub 已無法為其產生下載檔的 git 映本
| 可信度 | 主張內容 |
|---|---|
| 有文件佐證 | 瀏覽器拿到 integrity="sha384-…" 之後會對收到的內容計算雜湊，一旦不符就拒絕載入該資源並回傳網路錯誤。沒有降級模式。這正是重新產生的檔案會造成服務中斷、而非外觀差異的原因。 |
| 營運方確認，此處無法驗證 | 切換日期；每秒 108,000 次、每日 90 億次請求；330 個以上的資料中心；98.6% 快取命中率；約 12% 的網站使用，佔 JavaScript CDN 市場 48.3%。以上每一項都是 Cloudflare 報告 Cloudflare 自己，沒有方法說明，也沒有標明出處。 |
| 營運方確認，且相當坦白 | 先前一次搬遷嘗試被回滾。重新處理舊套件所產生的檔案內容正確，但位元組並不相同，完整性雜湊因此改變。最後改為把整份目錄原樣從 KV 複製到 R2。 |
| 僅有主張，未量化 | 汰除舊流程「關閉了近期所有已開立的 cdnjs 漏洞」。沒有數量、沒有編號、沒有嚴重程度、沒有日期——而這篇文章其他地方精確到個位數。 |
| 主張，且在同一篇文章中被自己削弱 | cdnjs 上每個檔案都有 SRI 雜湊——這句話出現的三句之後，作者承認 Cloudflare 仍在確認已存的雜湊是否與實際相符，原因是舊系統的錯誤。兩句都在原文裡；只引其中一句就是誤報。 |
時序
一路走來 十五年，其中一步無法定年
- 2011 年作為社群映本誕生。Ryan Kirkman 與 Thomas Davis 建立 cdnjs，當時 npm 才剛滿一歲，網頁交付 JavaScript 的方式就是「丟一個 <script> 標籤」。幾個月後 Cloudflare 開始免費代管。
- 2019 年Cloudflare 接手維護整個專案，而不只是代管。
- 2020 年服務端搬了，發佈端沒有。檔案開始由 Workers 與 KV 提供，後方保留裸機來源，所有資產都預先以 Brotli 與 gzip 壓縮。監看 npm 與 GitHub 的流程仍留在 Google Cloud，因為當時還沒有 Workflows、Queues、Durable Objects、R2 與 Containers。
- 日期不明那次被回滾的嘗試。舊套件被重新處理並直接寫入 R2；結果與 KV 原本提供的內容在位元組上並不相符，完整性雜湊因此不同，變更遭到撤回。原文完全沒有給出日期，所以它列在這裡而非依序排入——而它正是全文最有啟發性的一段。
- 2026 年 6 月之前兩道平台上限被提高，而不是繞過。付費方案的 Workers 子請求由每次呼叫 1,000 提高到 1,000 萬；Workflow 步驟由 1,024 提高到 10,000，可設定至 25,000。
- 2026 年 6 月 23 日cdnjs 全面在開發者平台上運行。R2 成為檔案內容唯一的真實來源，KV 只保留中繼資料。
- 2026 年 7 月 30 日過程公開發表，距離切換 37 天。
有一步沒有日期，而那正是重要的一步
此處其他每一項都精確到日。唯獨那次被回滾的嘗試完全沒有日期——沒有月份，也沒有年份——因此無法誠實地排進時序。這裡把它列為日期不明，而不是猜一個。
論點
Cloudflare 想論證什麼 自食其食，以及全篇指向的那句話
原文自己的用詞是 dogfooding（自食其食），其論證是一個三段論：cdnjs 規模龐大，cdnjs 現在跑在任何人都租得到的同一套元件上，所以那套元件撐得住你要蓋的東西。結語就是這麼寫的——「它大概撐得住你正在做的任何東西」。值得把兩半拆開看。證據是真的：兩道平台上限因為 cdnjs 撞到而被提高，而那些提高適用於每一位付費客戶，不只是 cdnjs。推論則是推銷，而原文也沒有假裝不是。值得注意的是，Cloudflare 同時明講這不是效能問題。「我們搬遷不是因為 cdnjs 慢。我們搬遷是因為想繼續把它做得更好。」舊架構獲得的評價是 98% 快取命中率、數十億次請求、沒有中斷。抱怨在於：要改任何東西，就得跨 GCP Functions、一台虛擬機與 Cloudflare 協調部署——而當某個環節半途失敗時，系統裡沒有任何一處知道。一個版本可能寫入了 KV，卻悄悄沒能進到 GitHub 倉庫，然後正常服務好幾週，直到有人發現兩邊已經分岔。當時沒有任何警報，原文也說清楚了為什麼不可能有：沒有任何元件知道整條流程的狀態。
- 26個 Cloud Function 只為了檢查 npm——每個字母一個，各有各的部署與日誌。
- 274條手工維護的
.gitignore規則，用來擋掉損壞或版號古怪的釋出——原文自己的說法是「一座有文件記載的墳場」。 - 10,000×Workers 子請求上限的提升幅度，由 1,000 到 1,000 萬——這是平台層級的改動，不是 cdnjs 專屬的。
補充
原文預設你已經知道的機制 為什麼重新產生的檔案是一片空白，而不是差異
子資源完整性
瀏覽器是拒絕，不是降級
- 網頁可以把雜湊寫死：
<script integrity="sha384-…">。 - 瀏覽器對收到的內容計算雜湊並比對。不符時回傳網路錯誤，該腳本永遠不會執行。
- 來源：MDN。這正是第一次搬遷嘗試必須撤回的全部原因。
- 網頁可以把雜湊寫死：
決定性
最小化工具的輸出在不同版本間並不穩定
- 幾年後用同樣的工具跑同樣的輸入，得到的是正確但不相同的輸出。
- 位元組不同就代表雜湊不同，而雜湊不同就代表每個寫死了舊雜湊的網頁都會壞掉。
- 通則：以內容定址的儲存無法重建，只能複製。
仍然未知的部分
目前有多少已存的雜湊是錯的
- Cloudflare 說它仍在讓已存的雜湊與實際相符，原因是「舊系統的錯誤」。
- 沒有給出規模。只要某個被人寫死的檔案雜湊是錯的，某處就有一個壞掉的網頁。
- 這是本頁最具後果的一項未知。
| 舊 | 新 | 實際改變了什麼 |
|---|---|---|
| Workers KV ＋ 一個 GitHub 倉庫 | R2 作為唯一真實來源 | 先前兩個儲存都不是權威，一旦分岔就沒有乾淨的辦法對齊。R2 也沒有實務上的大小限制，因此原本塞不進 KV 的原始碼對照表與字型包，現在和其他東西放在一起。 |
| 一連串由儲存桶事件觸發的 Cloud Function | Workflows，搭配 Queues 與一個 Durable Object 計數器 | 儲存原本兼作訊息佇列——沒有死信佇列、看不到積壓、失敗也無法乾淨重跑。Workflows 會保留每一步的狀態，逾時是接續而不是重來。 |
| 兩套沒有共同索引鍵的日誌系統 | 一個平台，一條追蹤 | 這要抓的不是中斷，而是半途成功：某個版本寫進了其中一個儲存、悄悄漏掉另一個，然後正常服務好幾週。 |
| 邊緣後方的一台裸機來源 | 快取 → R2 → DigitalOcean Spaces | DigitalOcean 多年來贊助 cdnjs 網站，現在連儲存也一併鏡像：架構上是災難備援副本，運作上是即時備援。在 GitHub 回填完成之前，鏈路上仍有一台 Cloudflare 代管的來源。 |
結論
可以帶走什麼 一個可以套用的心得，以及三件不必抓太緊的事
複製位元組，不要重建它們
這一段可以套用到跟 CDN 毫無關係的系統上。只要下游有人把你的輸出雜湊寫死了，那份輸出就不再是你能重新產生的東西——工具鏈會前進，位元組會不同，而「正確」並不足夠。Cloudflare 是試過並回滾之後學到這件事的，而且把它寫了出來。
在標題的意義上完成了，但有一處自承尚未結束
cdnjs 確實跑在開發者平台上。同時，在 GitHub 回填進 R2 之前，服務鏈路上仍留著一台 Cloudflare 代管的來源。這是原文自己說的；把它抹掉的文章，報導的是標題而不是內容。
數字要抓鬆一點，安全性主張要抓得最鬆
此處每一個營運數字都是 Cloudflare 報告 Cloudflare，沒有方法說明也沒有出處——這是工程部落格文章的常態，不是醜聞。但「關閉了近期所有已開立的 cdnjs 漏洞」沒有數量、沒有編號、也沒有嚴重程度，而這篇文章其他地方精確到個位數。把 10,000 倍的子請求提升當成紮實的證據；把那句話當成全文最弱的一環。