Cloudflare 部署完整指南：從 GitHub、Workers、網域與 SSL，到正式上線及回滾

更新與查核日期：2026 年 10 月 23 日。本文以 Cloudflare 官方文件為主要依據，適用於準備部署靜態網站、單頁應用程式、前端與 API 的讀者；另區分既有 WordPress 主機站點的安全設定。所有 example.com、demo.example.com 皆為保留用途的示例網域，不代表作者持有或已實際登入任何帳號。

範例與驗證範圍：本文依官方文件提供操作範例，未附獨立 Demo 帳號的真實部署紀錄。網域、專案名稱與架構均為通用示例，不代表任何特定企業的實際系統；圖解也不是管理介面截圖。

先理解部署的目的：讓作品變成可以交付、維護及復原的服務

完成網站設計並不等於完成網站部署。當開發者在電腦上打開 index.html，畫面可能已經能使用；但把網址交給客戶後，問題才真正開始：對方能否在手機上開啟？在不同國家是否能正常載入？表單資料會送往哪裡？修改程式時，會不會把正在使用的版本覆蓋？如果發生錯誤，誰能把服務恢復？

所謂「部署」，不是把檔案上傳到某個空間就算結束，而是把可重現的原始碼及設定轉換為可供使用的服務版本，配置網址、安全與權限，再建立檢查及回復手段。Cloudflare 在這個過程中可能扮演幾種不同角色：DNS 服務商、反向代理及 CDN、網站與應用程式的執行平台、存放靜態資產的平台，以及安全與觀測能力的提供者。不同角色所解決的問題並不相同。

本篇最重要的判斷是：先判斷應用程式需要在哪裡執行，接著才選 Cloudflare 功能。 一個只有 HTML、CSS 和圖片的活動頁，與一個包含帳號、資料庫、付款流程的會員網站，部署方式不應相同。企業若把這些差異全部當作「設定 Cloudflare」，往往會在 DNS、快取、TLS 或應用程式運作上做出不必要的改動。

30 秒答案。 對全新的靜態網站、單頁應用或適合 Cloudflare 執行環境的全端專案，優先評估 Cloudflare Workers 與 Static Assets，使用 Wrangler 在本機預覽與部署，確認 workers.dev 測試網址後，再綁定自訂網域。若已使用 Pages，可繼續維護，不必為了追逐新功能立即遷移。若網站原本是既有託管主機上的 WordPress／WooCommerce，最常見的做法是保留原主機，先正確配置 DNS、代理、TLS、安全規則及快取，而不是將 PHP 網站「整站貼到 Workers」。[S01][S02][S05][S10][S15]

一、Cloudflare 部署其實有三條路線

1. 新建靜態網站：Workers Static Assets

這類網站通常以 HTML、CSS、JavaScript、圖片及字型為主。靜態網站不代表內容永遠不會變，而是伺服器不必對每一次請求都執行業務邏輯，部署時生成的檔案即可直接交付。作品集、活動宣傳頁、文件站、純前端工具與部分 Vite 專案符合這種型態。

Cloudflare 於 2026 年的 Workers 最佳實務中建議，新專案以 Workers Static Assets 處理靜態、SPA 及全端應用。平台可在一次部署中管理 Worker 程式與靜態資產，避免把它們當成互不相關的兩組版本。[S01][S02] 讀者應留意，這是對新專案的優先選型建議，不表示 Pages 被關閉，也不保證所有既有框架只需改一個設定就能無痛遷移。

2. 新建動態應用：Workers 程式加上必要的資料服務

若功能包括 API、登入驗證、Webhook、表單後端、資料處理或需要依請求動態回傳內容，就必須評估執行環境、資料儲存與權限。Workers 可執行 JavaScript／TypeScript 的邊緣程式邏輯，並藉由 Bindings 或外部 API 連接資料與其他服務；但它不是把任何傳統 Node.js、PHP 或長時間常駐伺服器照原樣上傳就必定能執行的通用虛擬機。[S01][S17]

常見誤解是看到框架名稱支援 Cloudflare，就認為所有套件都能運行。實務上仍要查核所需 Node.js API、原生二進位套件、檔案系統操作、執行時間與資料庫連線方式。若專案需要常駐程序、特殊執行檔或長時間任務，應比較 Workers 搭配其他服務或 Containers 等架構，而非先寫完才發現不相容。

3. 已有 WordPress／WooCommerce：Cloudflare 放在主機前面

傳統 WordPress 需要 PHP 執行環境及資料庫。Cloudflare DNS 與 CDN 可放在 WordPress 來源主機前，協助流量路由、快取靜態資產、提供安全功能；原先的 PHP、資料庫與 WooCommerce 結帳仍由後端主機負責。Cloudflare 的 WordPress 效能文件也特別區分匿名頁面快取與已登入或加入購物車的使用者，避免把每個人都當成可以共同快取的訪客。[S15]

這條路線的成功標準與新專案部署不同。前者是原站不受破壞、網站可用性及安全性提高；後者才是把新應用真正部署到 Cloudflare 執行與託管。有既有網站的讀者應先完成網站備份、DNS 匯出、服務清單和變更窗口，再進入後續操作。

二、認識五個部署名詞：原始碼、建置、執行環境、版本與網址

不少新手在部署的第一天就被 Git、Build、Deploy、Domain、DNS、TLS 等縮寫打斷學習。只要能理解它們的上下游關係，後續看到任何部署平台的管理介面都比較容易判讀。

原始碼（Source Code） 是專案的可編輯來源，通常保存在本機與 Git 儲存庫。GitHub 提供版本管理與協作，不等於正式網站主機。建置（Build） 是把原始碼轉換成適合上線的檔案；純 HTML 不一定需要這個階段，但使用 Vite、React 或靜態網站產生器的專案通常需要。部署（Deploy） 是把某次建置結果與設定交給平台，形成可被請求的版本。執行環境（Runtime） 負責執行動態程式；純靜態資產未必需要由 Worker 指令碼逐筆處理。網址與 DNS 則決定訪客輸入什麼名稱、請求應前往哪個服務。

想像一位學員用 AI 協助完成了一個營運 Dashboard。程式碼存在 GitHub，是作品保管的位置；Cloudflare 收到部署版本，是服務的運作位置；dashboard.example.com 是訪客的入口；TLS 憑證讓傳輸經過加密；監控與回滾則是日後維護的保險。少掉任何一個必要環節，畫面再完整也不等於可營運。

這個分工還影響權限：負責修改畫面的同仁，不必因此拿到公司主網域的 DNS 管理權；負責審稿的人，不應有權直接輸出部署祕密；能合併 Git 分支，不代表可以不經審核就修改生產環境的資料庫。設計明確的角色與核准點，比追求任何人都能一鍵上線更符合企業要求。

三、實作前先做部署前盤點：不花錢也能避免的七種失誤

在開啟 Cloudflare 帳號之前，請先寫下要部署的是哪一個程式、要用什麼網址、是否有個資、使用哪些外部 API、是否需要資料庫、部署失敗如何復原，以及誰有權核准正式上線。這份盤點可用一個文字檔保存，不需要先建立複雜的管理系統。

第一種常見失誤是沒有辨識正式網域的現有用途。公司域名可能同時服務官網、電子郵件、第三方驗證、客服系統、票券、會員和支付。改動 Nameserver 或 DNS 記錄時，如果只注意網站 A 記錄，可能忽略 MX、TXT、DKIM、SPF、DMARC 等既有配置。雖然不是所有 DNS 改動都會影響信件，但錯誤刪除或替換記錄確實可能造成服務中斷。因此任何改動都要先匯出與逐項核對。[S11]

第二種失誤是把實際帳號密碼或 API 金鑰寫進程式。用 AI 生成程式時，範例常以 API_KEY 等變數名稱示意；正式提交前必須檢查是否有人把真正的值留在 HTML、Git 儲存庫或前端 JavaScript。前端打包後會提供給瀏覽器，不能被當成保密的位置。Cloudflare 的官方指引要求敏感值使用 Secrets，而不是 Wrangler 的普通 vars 或提交進原始碼的設定。[S08]

第三種失誤是將 staging（測試環境）與 production（正式環境）混用。測試用 API 金鑰、測試資料和正式資源應有隔離邊界。尤其表單、付款與寄信功能，部署前測試必須避免對真實客戶發送訊息或改動訂單。

第四種失誤是沒有建立內容與程式的分界。當一個 WordPress 站點有大量文章、商品、歷史訂單與搜尋索引，並不是能把前端 HTML 搬走就等於完成主機搬遷。即使新的靜態前端可以顯示商品卡片，原本的庫存、會員、支付、退貨、通知與資料備份仍要有明確承接者。

第五種失誤是沒有預先定義驗收。有人以為 Cloudflare 顯示綠色部署狀態就代表一切正常，但那通常只證明建置或發佈流程沒有拋出錯誤。首頁能開不代表手機版、深層連結、表單、登入、SEO 標籤和資料寫入皆正確。

第六種失誤是忘記評估流量與費用。Cloudflare Workers 的帳號方案對請求、CPU、記憶體、靜態檔案數等有不同規範；某些純靜態資產請求與執行 Worker 的計費方式也不同。這些數字會隨服務版本與方案調整，不能從「有免費方案」直接推論所有架構都沒有成本。[S13][S14]

第七種失誤是沒有備份與回滾設計。程式碼能回滾，不代表資料庫異動會跟著倒退；換了外部 API、修改資料結構或刪除儲存資源後，即使恢復舊版程式仍可能發生錯誤。部署前應問自己：若新版本失敗，哪些部分可以安全回復，哪些資料變更需要額外遷移策略？[S09]

四、第一個實作：不需要框架，部署純 HTML 網站

以下提供可獨立操作的最小範例。刻意不用 React、Next.js 或大型網站模板，是為了讓讀者看清 Cloudflare 平台的角色。學會這段操作之後，再把同樣概念延伸到框架與 CI/CD，理解成本會低得多。

步驟 1：準備 Node.js、npm 與專案資料夾

請在支援的 Node.js 環境開啟終端機，建立新資料夾。Cloudflare 官方建議在各個專案內安裝 Wrangler，避免多人協作時因使用不同的全域版本而產生差異。官方目前列出的 Wrangler 安裝命令為 npm i -D wrangler@latest。[S03]

mkdir deployment-lab-demo
cd deployment-lab-demo
npm init -y
npm i -D wrangler@latest
mkdir public

若 macOS、Windows 的建立資料夾命令或檔案建立方式不同，請改用你熟悉的終端機或檔案管理程式。這些命令不會自動替你建立 Cloudflare 帳號，也不會修改任何公司的正式網站。第一次執行要留意 Node.js 與 npm 是否已正確安裝。若出現權限錯誤，應先修正本機環境，而不是直接用具管理員權限的命令覆蓋系統設定。

步驟 2：建立 public/index.html

以下是一個完整可辨識的頁面，具備繁體中文、標題及手機版 viewport。你可以先用本機瀏覽器檢查內容，再交給 Cloudflare 供應。

<!doctype html>
<html lang="zh-Hant">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Cloudflare 部署測試｜Deployment Lab</title>
    <meta name="description" content="驗證 Cloudflare Workers Static Assets 的部署流程。" />
    <style>
      body { margin: 0; font-family: system-ui, sans-serif;
             background: #f6f5ef; color: #14283d; }
      main { max-width: 760px; margin: 12vh auto; padding: 2rem; }
      h1 { font-size: clamp(2rem, 5vw, 4rem); line-height: 1.15; }
      a { color: #087a65; }
    </style>
  </head>
  <body>
    <main>
      <p>DEPLOYMENT LAB 01</p>
      <h1>網站已準備好部署。</h1>
      <p>這是示範頁面，沒有連接真實客戶資料。</p>
      <a href="https://developers.cloudflare.com/workers/">Cloudflare 官方文件</a>
    </main>
  </body>
</html>

請注意：範例中的文字只證明這是一個測試頁，在未執行實際部署前，不應聲稱網站已公開上線。 它沒有登入、付款、資料庫或自動化串接。如果改用自己的公司資料或顧客名單練習，必須額外做資料保護與對外可見範圍的核對。

步驟 3：建立 wrangler.jsonc

這份檔案描述 Cloudflare Worker 的名稱、相容日期及靜態檔案位置。範例刻意沒有 main，表示這次只供應靜態資產，不需要為每一筆訪客請求額外執行 Worker 程式。官方的 Workers 最佳實務提供了相同的資產路徑設定概念。[S01][S02]

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "deployment-lab-demo",
  "compatibility_date": "2026-10-16",
  "assets": {
    "directory": "./public"
  }
}

這裡的 name 必須符合平台命名規則，且在你的帳號內不能與不相容的既有專案衝突。compatibility_date 並不是本文發布日期，它表示採用哪個日期的執行環境相容行為；新專案應依當時官方文件與測試結果選定，再把設定納入版本管理。assets.directory 應指向實際存在且包含 index.html 的資料夾。若路徑錯誤，平台可能找不到檔案，部署無法達成預期。

步驟 4：本機預覽與核對

在專案根目錄執行：

npx wrangler dev

終端機會提供本機預覽網址，通常是本機連線位址；請以實際顯示內容為準，不要把示例端口寫死。此時要檢查首頁標題、手機排版、連結、檔案路徑與瀏覽器主控台。若有更新 CSS、JavaScript 或圖片，確認瀏覽器已載入你修改的版本。如果這一步就出錯，應在本機修正，而非直接部署後才檢查。

對單純靜態頁，還應測試失效路徑的行為。例如輸入不存在的 /missing-page，是否收到預期的 404？稍後若改成 SPA，需重新思考前端路由與重新整理頁面的處理方式，不可把兩種模式混為一談。[S04]

步驟 5：登入 Cloudflare 並部署

若還沒有登入 Wrangler，可以先透過官方認證流程授權。部署命令會建立並啟用 Worker 版本，因此這是會影響對外可見狀態的動作。請在個人練習帳號操作，不要直接沿用公司的正式管理者帳號。

npx wrangler login
npx wrangler deploy

成功後，Wrangler 會顯示部署資訊與可供測試的網址；常見的是 *.workers.dev。是否已啟用 workers.dev、對應的子網域名稱與可用性，應以帳號實際回傳結果為準。開啟該網址後，先確認標題、內容與連結一致，再用手機和另一個瀏覽器驗證。[S04]

如果部署成功但頁面顯示 404，優先核對 assets.directory、index.html 是否真的存在、是否在正確的專案根目錄執行命令，以及是否誤把原始碼資料夾當成建置輸出資料夾。不要在完全不了解錯誤原因時反覆按 Deploy，因為每次部署都可能建立另一個版本。

步驟 6：留下部署證據

一次可交付的部署，最低限度應保存 Git Commit ID、部署時間、平台部署版本、測試網址、驗收者、主要功能驗證與可回滾版本。這些欄位不需要購買外部系統，用文字文件或試算表就能記錄。若 AI 協作完成修改，還應保留使用的工具、修改範圍及人工審查結果，避免日後無法重現。

完成上述步驟並確認測試網址可用後，才算走完整個最小循環：編輯檔案、定義設定、本機預覽、認證、部署、開啟網址與記錄證據。真正的技術成長不在於少打幾行指令，而在於分辨每一個動作的效果與風險。

五、框架專案如何部署：先認出 Build Output，再選適當介面

當專案使用 Vite、React、Astro 或其他框架，開發時看到的檔案不一定是能直接放上線的最終結果。開發模式可能靠本機伺服器即時轉譯，部署時則必須建立適合上線的輸出。這是新手從單一 HTML 進入正式前端開發時最容易忽略的環節。

例如一個典型 Vite 靜態前端會先安裝相依套件，接著執行 npm run build，常見輸出資料夾為 dist/。但不是所有框架都叫 dist，更不能把 .next、build、public 當成可互換的字串。請以該專案 package.json、框架設定和實際建置輸出為準。Cloudflare 文件明確指出 assets.directory 會指定要上傳的資產目錄，這是配置的核心。[S02]

{
  "name": "sample-vite-demo",
  "compatibility_date": "2026-10-16",
  "assets": {
    "directory": "./dist",
    "not_found_handling": "single-page-application"
  }
}

以上是針對確認採 SPA 路由模型的前端專案示意。single-page-application 讓某些非資產路徑回到 SPA 入口頁，適合由瀏覽器 Router 解析的路由；但它不是所有網站都應打開的萬靈丹。對有大量真實內容 URL 的文件站或 SSR 網站，過度寬鬆的回退行為可能讓本應回應 404 的路徑看似成功，影響錯誤追蹤及搜尋索引判讀。是否採用，需要和你的路由設計一併測試。

此外，build 與 deploy 是兩個不同概念。前者可以在本機、CI 或 Cloudflare 的建置環境進行；後者把結果變成可提供流量的版本。若以 wrangler deploy 作為部署命令，而沒有在流程前執行必要的 npm run build，就可能上傳舊的輸出檔案。實務上應把建置命令、Node.js 版本與 Lockfile 一起固定，確保其他同仁能重現。

六、GitHub 自動部署：不要再靠人工複製貼上版本

手動部署非常適合第一次理解平台，但一旦多人共同維護，僅靠某位工程師在自己的電腦執行指令，就容易出現版本不可追蹤、環境不一致與無法釐清責任的問題。Cloudflare 的 Workers Builds 可以連接支援的 Git 儲存庫，依設定的分支進行自動建置與部署。[S06]

推薦工作方式是先將程式碼提交 GitHub，以 Pull Request 審核改動；對非正式分支啟用 Preview 建置，檢查預覽網址的功能；通過測試與人工核准後才合併至生產分支。此時 Cloudflare 可以執行標準化的建置與部署。對企業來說，這不只是省下一次複製貼上的操作，而是把「誰修改了什麼、用哪個版本上線」變成可追溯的紀錄。

依 Cloudflare 2026 年 10 月的 Workers Builds 文件，建立專案時可選取 GitHub 或 GitLab 等支援的來源，設定儲存庫與 Build。正式分支的 Build 可建立新版本並依設定部署；非正式分支則可建立 Preview。需要注意，預覽環境、版本網址與正式環境不是同一件事：它們的變數、Secrets、Bindings 與資源隔離條件可能不同，不能因預覽成功就推論正式版必定正常。[S06][S18]

一個可操作的團隊規則是：「Pull Request 必須包含變更說明、測試結果與預期回復方法；正式分支設保護規則；敏感設定只存在於 Cloudflare Secrets 或授權的 CI Secret Store；生產部署由指定角色核准。」若沒有分支保護與人工檢查，即使自動化平台再穩定，也只是更快速地把未檢查的改動送上線。

GitHub 串接操作摘要

1. 在 GitHub 建立私人或公開儲存庫，提交已去除祕密資訊的程式與 wrangler.jsonc。
2. 於 Cloudflare 控制台進入 Workers & Pages，建立 Worker 或選擇既有 Worker 的 Builds 設定。[S06]
3. 授權需要的儲存庫範圍，不要在不需要時授予整個組織所有 Repo 的權限。
4. 核對 Worker 名稱與設定檔中的 name 是否相符；官方文件指出不一致可能導致建置失敗。[S06]
5. 設定正確的根目錄、Build 與 Deploy 命令，確認依賴安裝正常。
6. 選定 Production branch，啟用需要的 Preview 建置及人工審核流程。
7. 以非正式分支進行一次改動測試，再驗證正式發佈及回滾。

若公司的安全規範禁止把儲存庫連接外部託管建置系統，仍可評估自有 CI/CD 或部署 Token 的替代方案。重點不是 Cloudflare 一定必須控制 GitHub，而是部署版本可追溯、授權最小化與日後能復原。

七、自訂網域：為何 DNS 正確，網站仍可能打不開？

測試網址正常之後，才建議綁定自己的子網域。Cloudflare Worker 的 Custom Domain 與 Worker Route 有不同用途。Custom Domain 適合由 Worker 本身作為應用服務來源的情境；Route 適合已有外部來源主機、需要在路由上執行 Worker 的情境。根據官方文件，Custom Domain 可由平台協助建立所需 DNS 記錄及憑證，且會把該主機名稱的路徑導向 Worker。[S07]

對第一次部署企業內部工具的團隊，lab.example.com 或 demo.example.com 通常比直接替換 www.example.com 合理。使用全新子網域可以降低改動正式網站的風險，讓你先驗證流量、TLS、權限與用途。實際設定前仍要確認該子網域是否已被其他服務使用，以及是否有既有 CNAME、TXT 驗證或其他記錄。

Cloudflare DNS 記錄管理與 Worker 的部署是兩個管理層。DNS 可告訴外界這個網域要前往哪裡；部署版本則決定到達後能收到什麼內容。當使用者輸入網域仍看到舊版頁面，可能是 DNS 尚未符合預期、連到錯誤的專案、邊緣快取或瀏覽器快取持續提供舊檔案，也可能是建置結果根本沒有更新。查錯時需要逐層排除，而不是一次更改所有設定。[S07][S11]

自訂網域的實作檢查順序

先在 Worker 的 Settings 或 Domains & Routes 找到新增自訂網域的入口，確認你選的是正確 Worker。輸入預定子網域，檢查控制台提出的衝突、擁有權與 DNS 條件，再完成平台所需的動作。接著以瀏覽器測試 HTTPS，檢查憑證、頁面內容與深層 URL。不要自行假設任何 A 記錄 IP，或把教學文章提供的 IP 複製成公司的來源 IP。

在遷移既有主網域的情況下，還必須額外檢查 Canonical、301 轉址、robots.txt、Sitemap、外部服務 Webhook、Cookie Domain 和回呼 URL。網址看起來只有字串差異，但第三方登入、支付、GA4、Search Console 與外部 API 往往會把它視為不同來源；其中任何一項忘了核對，都可能造成使用者流程異常。

八、SSL／TLS 不只是看到鎖頭：兩段連線要分別理解

傳統來源主機放在 Cloudflare 後方時，使用者至 Cloudflare 與 Cloudflare 至來源主機是兩段獨立連線。Cloudflare 的 SSL/TLS Encryption Mode 決定代理到來源主機的加密方式。官方建議只要條件允許，就優先採用 Full（strict），讓 Cloudflare 驗證來源憑證的有效期、受信任程度及主機名稱，而不只是存在某張憑證。[S05]

Full 與 Full（strict）最大的差異在來源憑證驗證。 Full 可以在不嚴格驗證來源憑證的情況下建立 HTTPS 連線；Full（strict）則要求來源憑證符合指定條件。當主機上已部署有效的公開憑證，或符合要求的 Cloudflare Origin CA 憑證，優先考慮 Full（strict）。如果來源憑證過期、不符網域或安裝錯誤，強制切換可能使網站出現連線錯誤。正確做法是先修正來源憑證，而非長期以較弱模式遮掩問題。[S05]

需再次強調，這段說明主要針對代理至外部來源主機的網站。 純 Workers Custom Domain 在 Cloudflare 平台上使用自訂網域時，來源角色與外部 WordPress 主機不同，不應照搬傳統主機的憑證安裝步驟。套用前請先畫出實際流量拓樸，確認誰是 Origin。

如果啟用 Always Use HTTPS，Cloudflare 可將訪客的 HTTP 請求重導至 HTTPS，但這個功能不會幫你修正所有 Mixed Content 問題。網頁若仍載入不安全的圖片、CSS 或 API，瀏覽器可能阻擋該資源。網站需要檢查頁面實際引用的 URL，而不是只在控制台打開一個開關。[S12]

也不要以啟用 HSTS 當成所有網站的第一步。HSTS 會改變瀏覽器對 HTTPS 的使用行為；若網站還有不支援 HTTPS 的子網域或未完成測試的服務，過早設定過長時效及包含子網域的規則可能提高修復難度。先完成正確憑證及 HTTPS 驗證，再依自身網域管理能力評估逐步啟用。

九、Cloudflare 快取應該怎麼設定：WordPress 與購物車必須另外看

Cloudflare 的 CDN 可快取許多圖片、CSS 與 JavaScript 等靜態內容，但它不表示所有 HTML、API 回應與登入頁都會在所有方案下自動快取。Cloudflare 官方文件明確區分靜態內容的預設快取行為，以及必須透過規則調整的動態 HTML 快取。[S16]

最容易引發營運風險的是把「Cache Everything」之類的廣泛快取策略套用到包含會員、個人資料或購物狀態的頁面。若來源回應含 Session Cookie、個人化價格、購物車項目或會員資訊，錯誤的快取規則可能使登入失敗、購物車不更新，甚至讓一位訪客看到不屬於自己的內容。Cloudflare 官方的動態頁面問題排查文件將登入與結帳列為需特別注意的情境。[S19]

對 WordPress／WooCommerce，先辨識 wp-admin、wp-login.php、購物車、結帳、我的帳號，以及可能包含使用者身分的 AJAX、REST API 與自訂會員流程。實際要排除哪些路徑，必須根據該站的外掛、Permalink 及請求方式核對，不能直接複製其他網站的萬用路徑清單就視為完成。Cloudflare 有示範如何依 Cookie 建立 Bypass Cache 規則，但功能可用範圍與設定方式仍應依帳號方案及官方文件確認。[S15][S20]

一個安全的測試方式是準備兩種角色：匿名訪客與已登入會員。在測試環境對同一頁面交叉測試兩者的內容、Cookie、快取標頭與購物狀態；再對商品加入購物車、取消商品、切換語言或幣別、登入登出及付款測試做驗收。過程中不應使用真實付款資料。若無法確定一個頁面是否會依使用者身分變動，應先保守地不要啟用 HTML 快取。

何時該清除快取？

當你確認原始碼已更新、建置輸出正確、部署版本正確，但訪客仍收到舊資產，可檢查 Cloudflare 快取與瀏覽器快取。對已使用檔名雜湊的前端專案，版本化資產通常比較容易正確失效；相反地，若所有部署都覆寫同一個 app.js 且給予過長的快取時效，就會讓用戶可能載入混合版本。清除全部快取不是每次小改版的預設必要步驟，尤其大型網站應優先評估指定 URL 或適當的 Cache-Control 策略。

十、安全底線：金鑰、權限、公開端點與流量限制

部署動作把程式從私有電腦搬到網際網路，攻擊面自然改變。公開網址代表任何能存取該網址的人都有機會發送 HTTP 請求；不能因為服務是測試版或網址很長就把它當成私有服務。部署前應判斷是否需要身分驗證、來源限制、速率限制與資料使用規範。

在程式層，任何涉及使用者身分或資料修改的 API 都需要伺服器端授權檢查。單純將「刪除」按鈕藏在畫面上，並不等於禁止未授權呼叫。也不應把第三方 API Token、Cloudflare API Token 或資料庫連線字串塞進前端環境變數，因為很多前端建置變數會被編譯進瀏覽器可以讀取的產物。Secret 必須保存在後端或受平台保護的機制中。[S08]

Cloudflare Workers 可透過 Wrangler 或控制台設定 Secrets。常見命令如下；執行後是否建立新的 Worker 版本或直接部署，需以官方文件所述指令行為為準，避免在正式環境意外變更生產流量。[S08]

npx wrangler secret put MY_API_TOKEN

本機開發可使用 .dev.vars 或 .env 保存測試用敏感設定，並加入 .gitignore。若對話中曾直接貼出真實金鑰或把它提交 Git，即使後續刪除文字，也應評估金鑰輪替，因為歷史版本、通知紀錄或其他下載副本可能仍保留該值。做法不是刪掉畫面上的字就算安全，而是撤銷可能外洩的憑證，改用最小權限的新憑證。

在營運層，API 要設合理的輸入檢查、錯誤回傳、日誌與異常提醒；外部 Webhook 應驗證簽章或來源授權，避免任何人都能偽造付款成功、寄信或資料寫入事件。針對會產生成本的 AI 推論 API，更要設定帳務上限、使用者配額或適當的速率控制。部署完成才發現 API 被任意呼叫，可能比網站短暫無法顯示造成更高的損失。

十一、費用不只看「免費」兩個字：讀懂請求類型與資產成本

Cloudflare 的開發產品包含不同的計量對象。對 Static Assets，官方文件指出直接供應靜態資產的請求可以是免費且不限量；但如果某條請求實際執行 Worker 程式、使用 run_worker_first，或搭配其他資料與 AI 服務，就可能涉及 Worker 請求及資源使用計價。[S13]

Cloudflare Workers Limits 文件在 2026 年 10 月列出 Free 帳號的 Worker 請求額度為每日 100,000 次，另有 CPU、記憶體及檔案等限制；這不是網站能支援多少真實使用者的保證值。因為一次網頁瀏覽可能產生多筆請求，有些命中靜態資產、有些執行 API，有些被外部服務處理。不能把每次網頁瀏覽直接等同一次 Worker 執行，也不能把免費靜態資產請求推導成所有動態功能皆免費。[S14]

規劃預算時，至少區分四個維度：一是每日預估請求，二是動態請求比例，三是單次執行所需 CPU 及後端資源，四是資料儲存、外部 API、日誌或其他產品費用。較可靠的辦法不是先猜每月只會花多少美元，而是用 PoC 測量真實負載，依每一項產品的當期定價重新計算。若要提供客戶預算，應註明幣別、稅金、估算期間、假設流量、排除項目與價格查核日期。

舉例說明：一個純靜態的產品介紹頁與一個每次開啟都向外部 LLM API 請求生成內容的應用，即使在同一個 Cloudflare 帳號中，成本結構也有本質差異。前者的關鍵可能是建置、檔案數、圖像最佳化與 DNS；後者則要關注 API 呼叫頻率、模型計費、快取策略、失敗重試及防止濫用。請先量測需求，再選方案，而不是只比較頁面主視覺看起來是否一樣。

十二、上線驗收：部署成功畫面不是營運驗收報告

可以把正式上線想像成小型系統變更。至少要核對以下五層：可到達、可操作、可安全使用、可觀測、可復原。這五層從外而內，不是互相替代的選項。網站能顯示首頁，只能證明一小部分的可到達性；API 需要驗證身份與錯誤處理，商務網站需要驗證主要轉換流程。

第一層是可到達性。測試 https、主機名稱、WWW 與非 WWW 策略、是否正確回應 200／301／404、是否有無窮轉址、是否會在行動裝置與不同網路條件下異常。第二層是主要功能。至少由實際使用者角色執行一個完整任務，例如開啟課程頁、填寫測試表單、驗證通知並收到符合預期的結果，而不是只看 UI 元件能否點擊。

第三層是安全。核對 Secrets 無外洩、Cookie 屬性、存取控制、第三方 API 金鑰與錯誤訊息，並測試未登入者是否被擋在權限之外。第四層是可觀測。確認錯誤、回應時間與部署版本能查詢；Cloudflare Workers 提供 Logs 與 Observability 能力，方便查看執行事件及例外，但使用時也必須考量日誌是否包含個資或敏感資訊。[S21]

第五層是復原。預先找到前一個穩定版本的 ID，確認工程人員有權執行回滾，也確認資料庫結構在回滾後仍可運作。Cloudflare 支援透過控制台或 Wrangler 回滾到先前部署版本，但官方同時提醒，對外部 KV、D1、R2 等儲存與資源的狀態改動並不會隨程式版本回滾；因此回滾不是萬能復原。[S09]

建議保留的部署驗收紀錄

十三、正式部署後故障怎麼查：先判斷是哪一層

一旦網站不能正常使用，最不建議的做法是同時調整 DNS、TLS、Caching 與程式碼。多處同時改動會使根因變得難以辨識，而且每一次改動都可能增加影響範圍。應先描述觀察到的症狀，再用最小範圍的檢查排除假設。

情境 A：Workers 預覽網址正常，自訂網域無法開啟。 優先檢查 Worker 的 Custom Domain 是否已正確連接、網域是否屬於預定的 Cloudflare Zone、是否與既有 DNS 記錄衝突，以及 TLS 是否完成。因為程式在預覽網址可用，先別急著改寫程式碼。[S07]

情境 B：首頁正常，重新整理內頁就 404。 如果是 SPA，可能需要調整 not_found_handling 或對應前端 Router；如果是多頁網站，也可能真的缺少內頁 HTML。不要把所有錯誤都改成回傳首頁，否則會掩蓋不存在的路徑。[S02]

情境 C：更新後有人看到新版，有人看到舊版。 核對部署版本、實際請求到的 Host、靜態檔案雜湊、Cache-Control 與瀏覽器快取。若設定多環境或多分支，還要確認正在看的不是預覽網址。Cloudflare 的版本管理可幫助判斷目前真正服務流量的版本。[S09]

情境 D：綁定 Cloudflare 後 WordPress 不斷重導。 優先核對來源主機的 HTTPS、反向代理感知與轉址設定，再檢查 Cloudflare 加密模式，避免把不相容的來源與代理設定互相疊加。不要把切到 Flexible 當成萬用修正方式。[S05]

情境 E：購物車忽然出現錯誤、會員登入反覆跳轉。 先檢查動態 HTML 的快取規則、Cookie、Redirect 與 Session 行為。可以暫停最近新增的高風險快取規則，在測試流程中比對恢復前後的差異，但這不等於讓所有資安控制一起關閉。[S19]

情境 F：新版本部署後 API 失敗。 檢查 Secrets 是否存在、Bindings 名稱是否正確、請求是否超時、API 是否有 CORS 或身份驗證問題；並使用 Workers Logs 查看錯誤狀態。若同時修改資料庫 Schema，必須評估向下相容與資料遷移，不能單靠切回程式碼版本解決。[S08][S21]

情境 G：部署變得很慢。 先分清楚慢的是安裝依賴、建置、上傳資產、冷啟動、API 執行，還是使用者網路。不同層的改善方式不同。縮小 JavaScript bundle 對純前端下載有幫助，但不能修正外部 API 本身的回應延遲；增加 CDN 也不能修正寫入資料庫前的昂貴運算。

十四、回滾與變更控制：讓上線變成可管理的決定

Cloudflare Workers 的版本與部署是兩種概念。版本保存特定時間點的程式與設定快照；部署才決定哪個版本真正服務流量。預設執行 wrangler deploy 會建立新版本並部署到所有流量，但平台也提供先上傳版本、經檢查後再部署的操作方式，供需要人工核准或逐步放量的團隊使用。[S09]

當發現新的程式邏輯造成嚴重問題，可以在確認適合回滾的情況下使用：

npx wrangler rollback

此命令涉及目前線上流量，不能把它視為無害的檢查指令。Cloudflare 官方說明，回滾會立即建立新的 Deployment，將指定舊版變成現行流量版本；若未指定 Version ID，行為依指令定義與當前部署歷史處理。對多次頻繁部署的專案，建議先在控制台找出目標 Version ID，再由授權者核准回滾。[S09]

回滾作業的前提是有明確的健康指標，例如錯誤率、關鍵 API 回應、登入成功率、表單完成率與支付交易是否正常。不是任何微小 CSS 問題都需要立刻回滾，也不是發生嚴重錯誤仍應堅持等待更多數據。好的變更流程會先定義容忍條件、觀測窗口、決策權限和通知對象。

若程式變更同時包含資料庫欄位的刪除或重命名，回滾可能遭遇資料格式不相容。更穩健的方法是採取可向下相容的資料庫變更：先新增欄位、讓新舊程式共同理解，再遷移資料，經過驗證後才逐步移除舊欄位。這是一般系統變更設計原則，不代表 Cloudflare 自動幫你執行資料庫遷移。

十五、用 Cloudflare 部署 AI 專案，為什麼不能只看 Demo？

現在許多網站可以透過 ChatGPT、Claude 或其他 AI 工具快速做出原型。問題不在於程式能否生成，而在於生成後是否具有權限管理、資料結構、可測試性及責任歸屬。模型可以幫你寫 Cloudflare Workers 程式，也可以提出部署指令，但它不應自動取得公司的 DNS、GitHub 與生產環境最高權限。

假設一家小型企業做了一個「報價查詢助手」。介面是靜態前端，使用者在頁面輸入產品條件，後端透過 API 查詢模擬資料並回傳建議。這個案例的合理架構可能是 Static Assets 提供前端、Worker 提供經過驗證的 API、Secrets 保存外部服務金鑰，再使用額外受控資料服務儲存必要資訊。若只是產品展示，甚至可以先使用不含真實客戶資料的模擬 API，避免第一版就把 CRM、ERP 和正式報價系統全部接上。

對企業內訓而言，適合教學的成果不是讓每位學員拿到一串「已部署成功」的畫面，而是讓他理解從使用情境、資料流向、原始碼、測試、網址到維護的完整責任鏈。這也能直接解答常見問題：明明課堂上專案很好看，為什麼下課後不能給別人用？因為 Demo 驗證的是功能可能性，正式部署還要驗證可用性、風險與可維護性。

可以把專案成熟度分成四個階段。第一階段是可在本機執行，第二階段是有公開或受控的測試網址，第三階段是有自訂網域與基本上線檢查，第四階段才是具有持續交付、監控、回滾及明確維護責任的服務。四個階段沒有必然的時間門檻，也不應以昂貴架構作為成熟標誌；與真實需求匹配才是關鍵。

十六、企業應如何選擇部署治理程度？

對只有單次活動頁的組織，要求完整多環境、監控平台與繁複簽核，可能反而延誤交付。相反地，對涉及個資、付款與大量業務流程的系統，只有一個擁有所有權限的帳號及手動部署，同樣不是合理的節省成本。治理的目的，是讓風險控制與業務重要性成正比。

可以先以兩個軸評估：若服務停止，影響範圍有多大；若資料洩露或被錯誤修改，後果有多嚴重。低衝擊、低敏感的活動頁，可採簡化部署與基本測試。高影響、高敏感的會員系統，則需加上正式的測試環境、權限分離、變更核准、備份、稽核紀錄及事故通報機制。

可用性與安全性也不等於同一個指標。 一個網站可能載入非常快，卻把不該公開的檔案放在公共路徑；也可能配置了多重安全規則，卻因為錯誤封鎖正常表單而造成營運流失。好的部署策略會同時評估使用者完成任務的成功率、資料保護、維運成本與事故復原能力。

對應的交付物應依風險加深。最簡單的專案至少要有 README、部署設定、Git 版本及網站測試；進階專案再加入資料流向圖、風險盤點、Secrets 管理、監控告警及操作手冊。遇到跨部門服務，還需要指定系統擁有者及後續維運窗口。真正能規模化的系統，不該只靠最初寫出原型的那個人才能更新。

十七、給既有企業網站的建議：先隔離實驗，不要動正式主機

如果你目前已經有一套仍在營運的 WordPress 網站、來源主機、WooCommerce 商品與既有 SEO 資產，第一個 Cloudflare Workers 練習不應以主網站為目標。更好的做法是建立獨立測試子網域，在這個子網域部署靜態小工具、互動式說明頁或企業內部 PoC。它能獨立測試 Workers、GitHub、Secrets、DNS 與自訂網域，不會因為教學實驗而改動現行訂單或網站版型。

如果要把這個 PoC 嵌入原站，需先評估整合方式。例如透過內嵌連結、獨立子網域或經核准的 API 串接，通常比直接改寫主站所有內容更容易控制。嵌入 iframe 時應另行檢查同源限制、Cookie、響應式排版與無障礙問題；若使用反向代理，則須確認來源路徑、標頭、Cookie 與快取的相容性。

同樣重要的是不要把 CDN 產品能力與主機 PHP 版本安全性混淆。即使網站流量已經經過 Cloudflare，原主機的 PHP、WordPress 核心、外掛、佈景主題和資料庫仍需獨立更新維護。Cloudflare 在邊緣可提供部分防護，但不能替代對後端已知漏洞的修補。若主機正在報告安全更新警示，應先依原主機的備份與升級作業處理，而非誤以為更改 DNS 就能消除漏洞。

建議企業採行的 7 日 PoC 範圍

第 1 日整理目標與資料流向，明確決定只使用示範資料。第 2 日以 Workers Static Assets 部署一個靜態首頁。第 3 日加上 GitHub 版本與 Preview。第 4 日使用獨立測試子網域驗證 HTTPS、路由及手機排版。第 5 日模擬錯誤、查看部署與日誌、練習回滾。第 6 日進行權限與資料外洩測試。第 7 日提交驗收表與後續選型決策。

這是示範性的七個工作階段，不是對所有企業的工期保證。它的目的在於讓管理者能看見產出物，並把「想上 Cloudflare」轉化為可驗收的小型專案。若牽涉正式資料庫或支付，實作應增加安全與測試範圍，不能硬塞入同樣天數。

前半部說明了從選型、部署到驗收與回滾的基本流程。接下來進入企業維運：先界定資料與系統的責任，再安排自動化測試、環境隔離、SEO、資安與交接。若只想先完成靜態頁練習，可保留後半部供專案擴充時查閱。

十八、Cloudflare 部署架構設計：先決定系統邊界，不要讓平台選型替代需求分析

企業常問「Cloudflare、AWS 或原本主機哪一個比較好」，但在回答平台之前，應該先確認系統究竟要處理哪些工作。一般商務應用至少存在四類責任：呈現介面、接收請求、處理與保存資料，以及操作維運。四者可以部署在同一環境，也可以分散在不同服務。部署平台只是承擔這些責任的一種實作方式。

假設一個課程報名頁面，需要顯示課程資訊、接受聯絡表單、發送通知並將資料寫入 CRM。頁面展示部分可以做成靜態資產，表單 API 可以由 Worker 實作；但這不代表 CRM 也搬到 Cloudflare。資料可能仍保存在既有 SaaS，或由企業原本的後端服務管理。這樣分工的好處，是新功能可以採逐步導入，而不是為了新增一個表單就重建整個系統。

第一個決策是資料所有權。 表單資料由誰保管？哪個系統才是正式紀錄？Worker 若送出請求後網路中斷，是否應重試？同一筆資料被提交兩次時如何避免重複建立？只要答案涉及客戶資料與後續追蹤，就不應只談 UI 及部署成功畫面。需要一個清楚的資料流向與主鍵設計，才知道哪些失敗需要補送，哪些情況需要人工對帳。

第二個決策是執行責任。 純靜態前端的 JS 在訪客瀏覽器執行，不能保護私人金鑰；Worker 程式在 Cloudflare 執行環境執行，可以使用受保護的 Secrets 與服務 Binding；外部資料庫、郵件、AI 模型仍可能位於不同供應商。企業要避免的一種混淆，是看見「網站在 Cloudflare」就以為資料、模型與所有執行邏輯都留在 Cloudflare。真正的資料流向要依程式的網路呼叫追蹤，而不是根據單一網址的 DNS 反推。

第三個決策是失敗隔離。 如果第三方 AI API 無法使用，整個網站是否必須跟著停擺？如果報表服務延遲，前台是否仍能顯示基本資訊？可以藉由把可快取的公開頁面與昂貴的動態處理分開，讓一項服務異常不至於波及所有使用者。但隔離也意味更多介面契約、監控點與部署版本需要管理，並非拆分越多越好。

第四個決策是維運能力。 企業內部是否有人能閱讀程式碼、檢查錯誤與執行回滾？若沒有，就不該把需要複雜資料遷移與二十種服務連線的架構包裝成「只要按一下部署」。與其堆疊技術名詞，不如先讓第一個服務具備可測試、可修改、可回復的最小閉環，再逐步增加實際有用的功能。

實務上可先畫一張資料流程圖：使用者透過什麼網址進入，前端載入哪些資產，呼叫什麼 API，每個 API 讀寫哪些服務，產生什麼資料，以及誰可以查看或刪除。這張圖的目的不是讓提案顯得高深，而是讓開發、營運與管理者對同一份系統邊界達成共識。

十九、從手動部署走向 CI/CD，應建立哪些自動化測試？

部署自動化不只包括上傳程式碼。真正有價值的是把原本要靠經驗判斷的錯誤提前攔住，讓它們在正式環境之外被發現。當團隊只有一人時，也可以使用簡單的檢查；當多人維護時，則應讓這些檢查在每次提交時執行。

最基本的第一層是靜態檢查。 HTML 是否有語法或連結錯誤？程式是否能通過 TypeScript 的型別檢查？打包是否產生預期目錄？是否把 .env、*.pem、授權憑證或實際個資資料集提交到 Git？這些檢查未必能發現所有漏洞，但能攔截很多不應進到部署階段的問題。對 AI 產生的程式碼更重要，因為生成結果可能看起來完整，卻缺少真正的例外處理。

第二層是單元與介面測試。 例如報價計算函式應用輸入輸出案例驗證；表單 API 不只測試成功，還要測試欄位缺漏、格式錯誤、過長文字、重複送出與未授權操作。假如涉及日期、金額或稅率，應明確記錄資料型態與四捨五入規則，避免某次 AI 改寫後產生不一致結果。這種測試是把商務規則固定下來，而不是單純檢查程式能否執行。

第三層是整合測試。 Cloudflare Worker 往外呼叫 API 時，可能遇到逾時、401、429 或外部服務格式改動。測試應能辨別「外部暫時失敗」與「程式邏輯錯誤」，並決定是否重試。對任何可能產生重複交易或重複寄信的操作，都應先考慮冪等性設計。重試是提高可靠度的工具，若沒有重複防護，反而可能放大錯誤。

第四層是端對端測試。 真實使用者不會只呼叫一個函式，他會從首頁一路走到表單提交或資料查詢。應模擬手機、桌機、不同權限與主要瀏覽器，確認使用者能完成整段任務。對具有付款流程的系統，請使用支付服務提供的測試模式；對 CRM，請使用獨立的測試資料或 Sandbox，不要把正式客戶紀錄拿來試。

第五層是部署後 Smoke Test。 就算所有 CI 測試通過，正式網域仍可能出現 DNS、TLS、路由、Secret 或資源設定的差異。部署完成後應使用正式網址執行少量低風險檢查，例如 GET 首頁、GET 健康檢查端點、確認主頁標題與預期版本；對會修改資料的測試則應使用特定測試身分與隔離資料，不能用真實交易做例行測試。

好的 CI/CD 流程不需要一開始就部署大量專業工具。可以從 npm run build 與少量測試開始，把成功判斷寫進 Pull Request，再逐步補上程式品質、安全掃描與自動化瀏覽器測試。最重要的是，任何一步失敗時應停止後續發布，不能只產生紅字報告，卻仍允許正式版本自動上線。

二十、測試、預覽與正式環境應如何切分？

不少團隊以為只要在專案名稱後面加上 test，就已經完成環境隔離。事實上，真正的環境不只包含程式版本，還有環境變數、Secrets、資料儲存、對外網址、第三方服務權限與可接觸的使用者。兩套網址若共用同一把高權限正式 API 金鑰、同一個客戶資料庫，便不能說彼此已經充分隔離。

本機環境 的目標是快速修改與偵錯，可以使用模擬資料，不應持有正式管理者金鑰。預覽環境 的目標是讓審核者確認改動，不應向真實顧客寄信或修改正式訂單。正式環境 才對真實流量負責，所有變更都需要記錄及回復方式。大型系統可另外增加 staging，但不要因為要符合某種教科書架構，就為低風險小工具建立過度複雜的環境。

在 Cloudflare Workers 的文件裡，Previews、Version URLs 與 Wrangler Environments 的用途有所不同。Version URL 可測試特定 Worker 版本，但可能仍使用該版本配置的資源；對想測試特定程式版本的情況有用，卻不能自動保證隔離所有生產資料。Previews 則可提供分支／Pull Request 的測試流程，並依設定使用獨立的變數與資源。實作時應依功能差異選擇，不要只看哪個網址比較容易分享。[S06][S18]

例如一個內部 AI 助理，正式環境可以查詢已授權的企業知識庫；Preview 環境則只查詢公開文件或匿名化測試文件。測試者仍能驗證搜尋與答案品質，但不必把整份企業內部資料開放給外部審稿人。若無法在成本與時間內做到資料隔離，至少要關閉高風險寫入、限制預覽環境存取並清楚標示仍存在的風險。

環境命名也應被視為治理的一部分。像 sample-form-dev、sample-form-staging、sample-form-prod 這樣容易辨識的名稱，有助於管理者避免把測試指令送往正式服務。不過，名稱只是提示，不能取代平台上的權限、獨立 Token 與正式發佈核准。

二十一、SEO 與部署的關係：網址與內容搬遷不能只靠 CDN

對商業網站，部署的工程成果往往會和搜尋結果綁在一起。網站頁面已被 Google 建立索引後，改動網址、渲染方式、標題、HTTP 狀態碼或轉址規則，可能影響搜尋引擎對內容的理解。因此 SEO 不是部署完成後才交給行銷部門處理的裝飾項目，尤其網站已經具有長期自然流量時更是如此。

第一項是 URL 對應。 如果舊路徑 /insights/old-guide 在新系統移到另一個路徑，應評估正確的永久轉址與內容對應，而不是把所有舊連結都導回首頁。對搜尋者而言，搜尋某篇特定文章卻進到首頁，是使用體驗的斷裂。若原網址可以保留，通常更容易降低搬遷風險；但仍需兼顧站點架構與維運方式。

第二項是 HTTP 狀態碼。 網站在瀏覽器看起來正常，不代表伺服器回傳的狀態碼正確。如果不存在的內容一律回傳 200 並顯示首頁，會讓錯誤頁面變得難以判別。對使用 JavaScript Router 的 SPA，應特別檢查重整頁面、真正不存在的 URL 與實際可索引內容，而不是只測試從首頁點選內部連結是否成功。

第三項是 Canonical 與協定。 在正式網址從 http 改為 https、從子網域轉為主網域，或更換部署平台時，需避免 Canonical 指向舊版或測試環境。預覽網址應評估是否需要限制公開存取及避免被搜尋引擎當成正式內容；但不要把正式站的 robots 設定直接抄到預覽或反過來套用。尤其網站即將公開時，要檢查有沒有把測試用 noindex 留在正式頁面。

第四項是頁面實際內容。 對於僅在瀏覽器執行後才動態產生正文的應用，應評估首屏內容、標題與 Meta 是否能被搜尋引擎適當讀取。若企業高度依賴 SEO，部署選型可能需要考慮靜態生成、伺服器端渲染或其他可供抓取的內容策略。Cloudflare 可以提供平台，卻不能自動使缺少內容的頁面具有權威性。

第五項是實際監測。 上線後至少應在 Search Console 核對索引、抓取、網站地圖與關鍵頁面狀態，在 GA4 核對頁面瀏覽和重要轉換事件。若網站同時變更網域、頁面架構與追蹤程式碼，發現流量異常時就很難判斷原因。因此對大規模站點，應盡可能採分階段變更，保留前後比較基準。

站點部署的 SEO 驗收不能只寫「分數 90 分以上」。更可操作的紀錄是：哪些歷史 URL 保留、哪些正確轉址、哪些頁面可索引、哪些設定屬於測試環境、Sitemap 是否對應正式內容，以及上線後負責檢查 Search Console 的人是誰。這種清單既能給工程師執行，也能讓行銷與內容部門確認自己關心的資產沒有遺失。

二十二、Cloudflare DNS 遷移的變更管理：一份不能省略的清單

DNS 是許多部署事件中最容易被低估的風險點，因為從單一網站管理介面看出去，可能看不到整個網域正在承擔的所有服務。如果是新買的測試網域，設定簡單；如果是一個運作多年的企業正式網域，它背後可能存在信箱、CRM、支付、教育訓練平台、電子報、分析工具、網域驗證與多種外部服務。

開始前，先確認網域註冊商、目前 Nameserver、現有 DNS 託管者及有權修改的人。匯出現有 DNS 記錄，建立一份包含類型、名稱、值、TTL、代理狀態與業務用途的清冊。要特別保留 MX、TXT、CAA、CNAME、SRV 等容易被忽略的項目；即使某條記錄看不懂，也不代表它不重要。請先向系統擁有者確認，不要在匯入新平台後順手刪除。[S11]

若需變更 Nameserver，應先檢查新 DNS Zone 是否具有完整記錄，再安排可監測的變更時間。TTL 不等於全世界同步切換所需的精準倒數秒數，不同遞迴解析器與用戶端也可能有快取；因此切換期間要保留舊環境的必要服務能力，避免把它們立刻停用。對已有高營運依賴的站點，應有可聯絡到 DNS 管理者、來源主機管理者及業務負責人的變更窗口。

改動完成後，先查網域解析與 TLS，再確認首頁、深層路徑、API、第三方 Webhook 與郵件收發。不要只用公司內部一台電腦測試，因為本機 DNS 快取或網路出口有可能導致觀察不同。可使用不同網路或可信 DNS 查詢工具交叉驗證，但須避免把內部管理記錄或私有服務資訊公開貼到討論區。

對企業來說，DNS 變更紀錄應包含申請人、核准者、修改前後差異、操作時間、測試結果及復原方向。若變更涉及網域指向，復原並不是一句「再改回去」就結束，因為還要評估 TLS、代理、快取與傳播狀態。尤其不可讓任何人只憑 AI 生成指令，就在未確認現有 Zone 的情況下批次替換正式 DNS。

二十三、企業 AI 應用部署的最低資安基線

AI 專案在部署後會暴露更多原型階段不存在的安全問題。例如公開的問答介面可能連接內部知識庫，報表工具可能能讀取客戶資料，生成式 AI 服務可能產生高額呼叫費用。即使 UI 只有一個文字框，背後也可能具有真實的資料存取與成本權限。因此「看起來只是小工具」不應成為跳過權限設計的理由。

資料範圍必須先經過授權。 測試用資料要與正式資料區分；若需要使用真實資料測試，應明確限定用途、存取權、保存期限與刪除責任。避免在網頁原始碼、URL Query String 或日誌中留下完整的客戶識別資料、Token 或可回推個人身分的敏感內容。對外呼叫 AI 模型或其他第三方服務之前，也要查核組織的資料處理政策。

API 權限必須在服務端判斷。 JavaScript 前端的按鈕隱藏、欄位 Disabled、選單不顯示，都不能當成授權控制。任何可以讀取私人資料、寫入 CRM、寄送商務信件或觸發付費 API 的端點，都應驗證操作者身分與允許的操作範圍。授權策略要明確到具體資源，而不只是「只要登入就能看全部」。

祕密金鑰與環境隔離要一起設計。 即使透過 Cloudflare Secrets 儲存金鑰，如果 Preview 與 Production 共用同一個高權限金鑰，預覽失誤仍可能影響正式系統。理想狀態是不同環境使用不同憑證，外部系統也配置相應的最小授權。若 API 服務無法支援多組憑證，至少應設操作範圍限制與額外的核准機制。[S08]

對外公開的 API 要管控濫用與成本。 這不只關係到安全，也涉及企業預算。應依功能採取適當的驗證、速率限制、使用者配額及異常告警，而不是等月底看到費用異常才調整。錯誤重試需要上限與間隔，避免外部服務短暫故障造成大量重複請求。若使用 webhook，請查核來源簽章與重播攻擊防護方式。

維運觀測不能記錄不該保留的內容。 把整份請求本文及完整模型提示詞寫進日誌，對偵錯可能方便，但也會產生新的資料保護問題。日誌應記錄足以追蹤錯誤的事件、時間、結果與匿名化識別資訊，避免包含機密文字與完整個人資料。存取日誌的人、保留期間及匯出至外部監控服務的範圍，都應由企業決定。[S21]

更新與事故處理要明確指派責任。 知道哪裡能 Rollback、誰有權停用外部 API 金鑰、哪些業務負責人在事故時需要被通知，比在部署完成畫面上放更多綠色勾選符號有價值。最低安全基線不是一次性的表格，而是每次部署、每次新增串接時都應重新檢查的治理程序。

二十四、如何把 Cloudflare 部署整理成企業可複用的教學資產？

企業在培訓期間學會技術，只是能力建立的開始。要讓成果在課後繼續被使用，必須把教學產物轉換成可維護的資產。與其提供一份只適用當天帳號的操作截圖，不如同時交付最小可執行專案、可修改的設定檔、練習資料、測試清單及常見錯誤說明，讓學員能在自己的權限範圍內重新操作。

第一份資產是最小程式專案。它應盡量保持沒有真實金鑰、沒有需付費購買的外部依賴，並包含清楚的 README。學員下載後能在本機執行預覽，替換品牌名稱或內容，再用自己的練習帳號部署。要避免把老師的 Worker 名稱、API Token 或正式企業子網域寫死，造成學員直接複製後產生衝突或資安風險。

第二份資產是架構與決策表。學員應能判斷自己的專案屬於純靜態、SPA、API 或既有 WordPress，而不是看見別人的指令就全部照貼。決策表可包含資料是否敏感、是否有登入、是否需要資料庫、是否已經有主機、是否需要 SEO，以及誰負責後續維護。這能降低課後依賴老師逐一判斷的成本。

第三份資產是環境配置規範。它要教學員分辨公開變數與 Secret，並記錄「只填變數名稱，不寫真實值」的規則。對企業內部共用的 GitHub Repo，應規劃誰可以審查 Pull Request、誰可以修改 Cloudflare 設定、誰可以發佈正式版本。即使是二人小團隊，也應避免所有權限集中在一個難以交接的個人帳號。

第四份資產是發佈驗收表。要包含功能、手機排版、安全、DNS、TLS、日誌、成本與回滾。這份表的最大作用，是讓工程師和非技術主管對於什麼叫「完成」有共同標準。例如管理者只需確認「員工能在手機開啟測試網址並完成三項任務」，技術人員則負責提供對應紀錄和可重現步驟。

第五份資產是失敗案例庫。教學時可故意讓 assets.directory 指向錯誤路徑、讓前端深層路由刷新後 404，或在安全隔離的練習專案中演示錯誤版本如何回滾。學員會看見「正常流程」之外的判斷方法，而不是只記住一個成功時的按鈕位置。正式環境則不可故意製造會影響真實客戶的故障來演示。

第六份資產是交接文件。記錄專案用意、版本位置、部署負責人、網域、依賴外部服務、必要環境變數名稱、日誌位置、主要測試與回滾方式。未來換人維護時，只要權限合法移交，就可以依文件繼續更新，而不必從頭詢問原始開發者。對企業而言，這才是 AI 提高開發速度後最值得建立的長期能力。

二十五、從一個公開展示專案，走向可收費產品的額外門檻

不少開發者在部署第一個 AI 網頁後，就希望能把它分享給客戶甚至開始收費。Cloudflare 能協助提供執行與交付環境，但從 Demo 到商業產品，仍需要完整的產品與營運設計。對使用者來說，網站能開只是最低條件，真正願意付費通常是因為它能持續解決特定問題，而且服務品質與後續支援具有可信度。

首先要定義付費價值。假設這個工具能替行銷人員整理資料、輸出報告，價值不在於頁面有動畫，而在於節省了哪些重複工作、輸出是否正確、多久更新一次及產生錯誤時如何修復。若未驗證客戶是否願意為成果付費，不宜因為買了網域與做好主視覺，就推論這是一個成立的商業模式。

其次是帳號與資料權限。公開展示頁允許所有訪客看到相同的範例內容，商業系統卻可能需要區分每個客戶的專案、檔案及帳單。這會直接影響資料隔離、登入、Session、審計紀錄、備份及刪除機制。若涉及訂閱與付款，還需要處理交易狀態、退款、重複扣款、發票與金流服務的 Webhook 驗證；這些不是把「立即購買」按鈕放到網頁上就自動具備的能力。

第三是支援與服務水準。即使技術上可以部署到全球節點，也不代表公司有能力提供 24 小時客服或保證零停機。正式銷售前應清楚說明服務範圍、使用限制、計價方式、資料責任與支援管道。如果尚未建立事故處理和維護團隊，就不應承諾超過實際能力的 SLA。

第四是成長中的成本控制。若每次使用都會產生 AI 模型呼叫費用，客戶使用量增加不一定等於獲利增加；還要核算外部 API、儲存、頻寬、維運與客服。初期可採有限試用、可量測配額與人工審核的收費模式，累積數據後再調整自動化程度。Cloudflare 的部署與計價選型應服從這些產品指標，而不是先選完所有工具才嘗試找商業用途。

最後是信任。對商業客戶而言，正式網域、穩定的 SSL、可讀的隱私權說明、正常的聯絡管道、明確的服務責任與一致的產品體驗，往往比把所有熱門技術名詞堆到首頁更有說服力。一個小而穩定、定位清楚的工具，可以比複雜但難以維護的全端系統更接近市場需求。部署技術真正的價值，是讓經過驗證的產品假設有一個可靠的交付場所，而不是替產品創造尚不存在的需求。

二十六、正式上線前，管理者應該向技術團隊提出的十個問題

即使主管不會寫 JavaScript，也應有能力判斷一個部署計畫是否具有完整的責任設計。最容易發生的管理問題不是工程師忘記某一行指令，而是雙方對「完成」的定義不同：業務認為客戶已經可以使用，工程師認為測試網址能開就算交付，管理者則以為修改失敗隨時可以一鍵復原。若不先對齊，系統一旦進入真實營運，各種認知差距都會變成實際成本。

問題一：服務是提供給誰，並要完成哪個任務？ 部署範圍需要跟使用者任務一致。若唯一目的是在展場展示 AI 工具，不必一開始就建置完整會員及金流；若要對外收費，則不能忽略付款、資料刪除與客服。這個問題的產出應是一段可驗收的使用情境，而不是技術清單。

問題二：哪些功能是公開的，哪些需要登入？ 網站有公開首頁，不表示 API 都能公開讀取。工程團隊需提交端點與存取權限表，標示每一類使用者可讀寫什麼資源。當讀者看到一個長得像登入頁面的 UI，不能因此推論背後已有真正的授權檢查。

問題三：敏感資料儲存在何處，會傳往哪些外部服務？ 必須具體說明資料庫、CRM、AI API、日誌和備份的位置，以及誰能存取。若資料會跨不同供應商與地區處理，應依企業政策檢核合約和安全要求。對尚未決定資料範圍的 PoC，優先使用模擬資料。

問題四：誰擁有網域、Git 儲存庫與 Cloudflare 帳號？ 如果這些資產都由外部接案者的個人帳號持有，企業未來可能因帳號停用或合作終止而失去維護能力。至少需明確紀錄服務所有者、管理員、日常部署者與交接方法，並評估雙因素驗證及權限分工。

問題五：修改如何從測試進入正式環境？ 不必每個專案都建立大型審批系統，但應明確規定程式改動後由誰檢查、使用哪個網址測試、何時合併以及是否需要人工發佈。越是高風險流程，越不適合由 AI Agent 不經確認直接推到生產。

問題六：如果第三方 API 故障，訪客會看到什麼？ 對會呼叫模型、付款或訊息系統的應用，應有合理逾時、重試上限及錯誤提示。使用者至少要知道操作有沒有完成，而不是一直按送出，最後產生多筆重複交易或通知。

問題七：正式網址與舊網址有什麼變化？ 對已經營運的網站，要評估既有 SEO、第三方 OAuth Callback、Webhook、分享連結、Email 連結與會員 Cookie。如果會變更網址，需提出轉址對照表與查核方式，避免只在簡報裡寫「完成網域遷移」。

問題八：我們如何知道部署出問題？ 需定義日誌、基本健康檢查與重要使用者流程指標。不是單純讓平台顯示綠色圖示，而是能在真實錯誤發生後辨識到原因與影響範圍。若工具涉及銷售與商機，還應追蹤表單完成、通知送達與重要資料是否成功寫入。

問題九：能恢復到哪個版本，資料會不會一起復原？ 程式碼回滾與資料恢復不同。團隊應說明版本保留、設定變更、資料庫備份、復原權限及驗收方式。對涉及外部服務的系統，還要知道回滾是否會產生 API 格式或資料 Schema 的不相容。[S09]

問題十：三個月後誰負責更新？ 這題常被部署教學省略。網站與 API 會遇到套件更新、瀏覽器變化、服務定價調整與人員異動。若初次上線文件只留下一段無法理解的部署指令，三個月後的維護成本就可能超過初期省下的開發時間。

以上十題並非要求小型專案寫出冗長的規範書，而是建立一個實際的完成定義。對展示型網站，回答可以很精簡；對有真實會員與訂單的系統，答案則要附帶可追溯證據。只要能清楚回答這十題，管理者就比較不容易被「部署成功」四個字誤導。

二十七、實作成果如何驗收：使用獨立練習帳號的範例

這裡提供一個可供課堂、企業 PoC 或內部評估使用的情境：建立一個不收集真實個資的「工作流程說明頁」。假設頁面有首頁、方法說明、連結到官方資料來源，以及一個在瀏覽器本地運作的互動區塊。它沒有後端寫入，沒有員工登入，也沒有付費 API。這個範圍足以驗證 Cloudflare Workers Static Assets 與 Git 部署流程，同時避開不必要的資安敏感資料。

驗收的第一部分是作品可重建。由另一位學員複製專案，使用 README 的操作步驟重新安裝相依套件並在本機預覽；若此時無法重建，代表專案過度依賴原作者的電腦狀態。必要時需要固定 Node.js 的支援版本、保留 Lockfile 並說明作業系統差異。對於教學專案，能夠由第二個人重建通常比第一個人第一次成功更能證明成果品質。

第二部分是測試網址可操作。驗收者用自己的瀏覽器開啟 Cloudflare 提供的部署網址，在桌機與手機確認標題、圖片、選單及連結。頁面在窄螢幕上不應出現重要內容被截斷、字級過小或按鈕重疊的情況。如果是純 HTML，還要確認頁面是否出現預期的編碼與繁體中文標點。

第三部分是版本可追蹤。作者建立一個 Git Commit，在頁面上修改可辨識的一行文字，再執行一次部署，記錄新舊版本的差異。若已完成 GitHub Builds，就用 Pull Request 與 Preview 取代個人在終端機部署。驗收者必須能指出目前正式版本對應哪一個 Commit，而不是只說「最新那版」。

第四部分是錯誤可診斷。刻意在本機測試環境將設定檔的 assets.directory 指向不存在的資料夾，觀察建置或部署時出現什麼錯誤，再恢復正確設定。這項練習要在隔離測試專案進行，不能故意破壞正式站。它讓學員理解如何從錯誤訊息回到專案結構，而不是期待 AI 每次提供相同的一行解答。

第五部分是回復可演練。在已部署的練習專案中發佈一個明確標示為第二版的頁面，確認新版本之後，依 Cloudflare 官方指引選擇前一個穩定版本。記錄回滾前後畫面、版本 ID 和操作人。若專案接上資料庫，就不再把這個示例直接套用，因為資料遷移與外部資源需要更完整的相容性檢查。[S09]

第六部分是交付與維護。最後提交一份包含目的、架構、原始碼位置、部署網址、測試證據、回復方式與注意事項的簡短紀錄。驗收者應能不靠作者口頭說明，就理解如何重做與如何排查最常見的問題。至此，部署不再只是一張可分享到社群的截圖，而是可以納入企業內部知識管理的資產。

二十八、上線後三十天：從一次性成功變成可持續營運

系統正式上線不代表專案完全結束。很多問題不會在測試當下出現，而是在使用者流量增加、外部 API 偶爾失敗、團隊開始頻繁改版或不同權限的人操作時才會暴露。對企業而言，應把上線後第一個月視為驗證維運設計的觀察期，而不是發版當晚看到首頁正常就解散專案團隊。

第一週先觀察基礎穩定度。 除了網站是否能開啟，應記錄錯誤回應、慢請求與最重要的使用者流程。若網站的主要任務是讓客戶填寫需求表，最重要的不是只有首頁載入速度，還包括表單能否提交、資料是否寫入、通知是否到達，以及資料出錯時是否有對帳方法。以工作任務為中心的監測，可以避免團隊花很多時間優化與業務成果無關的技術細節。

第二週檢查權限與真實使用情況。 真正的使用者可能在手機瀏覽器中操作、開啟過期的 Email 連結、重複按下提交按鈕，或在網路切換時產生未預期請求。應利用合法且符合隱私政策的事件資料，找出哪些使用流程尚未被測試涵蓋。同時重新檢查擁有正式部署權限的人員、第三方金鑰使用狀況及異常存取紀錄。若測試人員仍保留高權限的正式金鑰，應在驗收後調整。

第三週評估成本與效能假設。 把實際 Worker 請求、CPU、外部 API、資料讀寫與錯誤重試等資料與原本預算比較。如果是純靜態頁，使用量增加可能不會線性地提高 Worker 動態運算成本；如果每次使用都觸發 AI 模型推論，則必須更仔細追蹤單次任務成本。此時可以討論哪些資料適合快取、哪些呼叫可以合併、哪些昂貴操作需要額度控管，但改善之前先確認不會犧牲資料正確性。[S13][S14]

第四週完成一次小型變更與回復演練。 由不是第一版作者的人依照 README 建立一個低風險改動，經測試和核准後部署，再確認監控與版本紀錄正確。若團隊已具備安全的測試環境，可額外演練如何選擇前一個版本、觀察回復結果並保存事故紀錄。演練應避開真實交易或高影響時段，且不應為了展示回滾而故意破壞正式服務。[S09]

到第三十天時，應產出一份精簡的營運回顧：目前誰是系統擁有者、主要功能是否如預期、發生過哪些問題、使用了多少資源、哪些操作還過度依賴某個人、下一輪要優先改進什麼。這份文件比只列出 Cloudflare 每天有多少請求更接近管理需要，因為它把技術行為轉化為業務風險與改善決策。

若經過一個月發現功能很少被使用，不能只因此責怪部署不夠快。應回到產品目的，檢查使用者是否有真實需求、入口是否容易找到、流程是否比原本方法更有效率。部署技術可以降低交付阻力，卻不能替市場驗證創造答案。同樣地，若使用量迅速成長，也不必急著把所有功能改造成大型架構；先從真實瓶頸與成本來源判斷，再決定是否需要擴充服務。

二十九、常見問題：Cloudflare Pages、Workers 與 DNS 的判斷

Q1：Cloudflare Pages 被 Workers 取代了嗎？

不應用「Pages 已不能用」這種說法。依 2026 年 Cloudflare 官方最佳實務，新專案建議優先使用 Workers Static Assets，Pages 仍持續可用。若 Pages 已經穩定服務業務，不需要單純因為選型潮流就立即遷移；應先比較功能需求、部署流程及維運風險。[S01]

Q2：使用 Cloudflare，一定要會寫程式嗎？

若只是設定 DNS、SSL 或 CDN，不一定需要自行寫 Worker 程式。若要部署使用程式框架建立的網站，至少要知道如何找到建置輸出、測試部署結果、設定網域與回復錯誤；即使用 AI 代寫程式，也需要有能力判斷部署行為。對不具工程背景的人，純 HTML 示例是合理起點。

Q3：可以直接把 AI 生成的 HTML 網頁放上去嗎？

可以先檢查其檔案是否完整、是否有外部資產依賴及是否包含不應公開的內容，再以靜態資產部署。不要把 AI 對話裡的 API 金鑰、真實客戶名單或敏感設定一併打包。含有後端驗證、資料庫或第三方 API 的功能需另做設計，不能只用 HTML 就假設全部功能上線。

Q4：為什麼 GitHub Pages、Vercel、Netlify 與 Cloudflare 都能部署？

這些平台都能支援某些網頁託管與部署情境，但各自的執行環境、框架整合、快取、計費、地理位置與維護流程不同。對新手而言，優先比較既有技能與應用所需功能，不要把平台名稱當成技術成熟度評分。本文選擇 Cloudflare 是為了建立一套完整的邊緣部署與網域管理實作，不代表其他平台不可行。

Q5：Cloudflare Workers 一定比一般主機快嗎？

不能一概而論。靜態資產能利用全球分散的網路節點與快取，但動態 API 可能仍需呼叫遠端資料庫或第三方服務。若最耗時的步驟在外部系統，改變前端部署位置不一定能消除主要延遲。應量測真實使用者感受到的載入時間、API 延遲、錯誤率及各服務距離，而非用平台口號替代性能測試。

Q6：WordPress 可以直接遷移到 Workers 嗎？

傳統 PHP 與資料庫架構的 WordPress 不能假設能以相同程式及環境原樣部署到一般 Workers。可考慮保留 WordPress 作為來源、Cloudflare 作為代理，或者另行規劃 Headless WordPress 與前端部署；後者需要額外的 API、路由、預覽、SEO、認證、快取與編輯工作流工程。遷移時要估算整體重建與持續維護成本，不能只比較雲端託管費。[S15]

Q7：如何判斷目前是否已經使用 Cloudflare？

需區分 DNS 託管、Cloudflare 反向代理與 Workers 實際部署。可檢查正式網域的 DNS Nameserver、Proxy 狀態、TLS、回應標頭，以及 Cloudflare 控制台是否存在對應的 Workers／Pages 專案，但單憑出現某個 Header 不一定足以完整判定所有配置。對沒有管理權的網站，應避免基於公開觀察做過度肯定的結論。

Q8：若網頁部署完畢，還需要購買網域嗎？

平台提供的 workers.dev 網址可以作為開發與測試入口。若要正式對外經營品牌，通常仍會希望使用自有網域及對應 DNS 設定。自有網域提供的是可控的名稱與品牌入口，不代表它替你完成系統可靠度、安全或 SEO 工作。[S07]

Q9：Deploy 成功就會被 Google 收錄嗎？

不會自動保證。公開部署只是讓頁面可能被存取。搜尋引擎是否發現、抓取及建立索引，還取決於網址可存取性、HTTP 回應、robots.txt、Canonical、網站內容品質與站內外連結等因素。對 SPA 或需要 JavaScript 才產生正文的網站，也要考慮搜尋引擎渲染與內容可辨識性；Cloudflare 部署成功不代表搜尋排名改善。

Q10：免費額度可以讓多少人使用？

沒有單一固定人數答案。單純靜態資產請求與執行 Worker 指令碼的請求有不同計量；使用者的瀏覽方式、圖片與 API 呼叫數、快取與外部服務都影響實際用量。應用官方最新限制、真實壓測與流量估算來判斷，不能把 Worker 的每日請求限制直接除以想像中的「每人一次」。[S13][S14]

Q11：用 Codex 或 AI Agent 自動部署是否比較好？

可讓 AI 幫忙準備設定檔、撰寫程式、分析 Build Log、產出驗收腳本及 Release Notes，但正式發布仍要定義最小權限、人工批准與回滾策略。對 DNS、憑證、Secret、會員及訂單等高風險功能，尤其不宜直接放任具有最高權限的工具修改正式環境。最有價值的自動化，是讓部署有紀錄且可重做，而不是省略所有審核。

Q12：企業真正需要哪一份交付文件？

至少有系統架構及資料流向圖、原始碼及版本、部署設定、網域與 TLS 紀錄、Secrets 清單（僅列名稱不存明文）、測試矩陣、監控與事故聯絡方式，以及回滾程序。這些文件最好與程式一起版本管理。即使後續更換平台，企業仍能保留重要的技術與維運知識。

結語：成功的 Cloudflare 部署，應能回答「發生問題時怎麼辦？」

若只以「是否成功打開網址」評估部署，就容易把有趣的原型誤判為可以承擔真實營運的產品。Cloudflare 提供從靜態資產供應、Workers、Git 整合、網域與 TLS，到日誌及版本回滾的技術選項；是否能把這些元件組合成穩定服務，仍取決於需求判斷、正確設定、資料保護與部署治理。

對第一次學習的人，先把純 HTML 站點以 Workers Static Assets 部署成功，再加上 GitHub、Preview、獨立子網域及驗收紀錄。對已經營 WordPress 或 WooCommerce 的企業，先保留原主機，隔離新的 Cloudflare 實驗，尤其要保護登入、購物車與支付流程。對要將 AI Demo 變成服務的團隊，請在發佈前把 API、資料、權限、費用與回滾都納入架構。

本文提供的原創最小範例及驗收表，可作為練習、教學與小型 PoC 的起點。若企業希望進一步把 AI 工具開發、資料流程與部署維運納入員工能力建置，可參考 天地人 AI 高效人才培訓課程 與 企業 AI 導入與培訓服務；實際課程內容與技術交付範圍仍以官方當期說明及個案需求確認為準。

主要資料來源與版本註記

資料以 2026 年 10 月 23 日當次公開官方頁面為準，若服務選單、價格或限制已更新，實作時須以 Cloudflare 最新文件與帳號實際介面確認。

• [S01] Cloudflare Workers Best Practices。新專案採用 Workers Static Assets 的選型依據。
• [S02] Workers Static Assets。資產上傳、綁定與運作機制。
• [S03] Install/Update Wrangler。CLI 安裝及版本管理。
• [S04] Static Assets Get Started。新專案與部署命令。
• [S05] Full（strict）TLS。來源憑證驗證。
• [S06] Workers Builds。Git 連接、Build 與 Preview。
• [S07] Workers Custom Domains。自訂網域與流量路由。
• [S08] Workers Secrets。敏感設定與儲存方式。
• [S09] Workers Rollbacks。版本回滾及限制。
• [S10] Cloudflare Pages Custom Domains。Pages 網域配置的對照。
• [S11] Cloudflare DNS Records。DNS 記錄管理。
• [S12] Always Use HTTPS。HTTPS 轉址與限制。
• [S13] Static Assets Billing and Limitations。資產請求計費規則。
• [S14] Workers Limits。免費與付費方案的執行限制。
• [S15] Speed Up WordPress。WordPress 快取與動態內容注意事項。
• [S16] Cloudflare Cache Get Started。靜態與動態內容快取差異。
• [S17] Workers External Services。外部程式庫及 API 整合限制。
• [S18] Workers Version URLs。版本測試 URL 與正式部署區別。
• [S19] Dynamic Content and Login Issues。登入、付款與快取問題。
• [S20] Bypass Cache on Cookie。依 Cookie 排除快取的官方示例。
• [S21] Workers Logs。日誌與錯誤追蹤。

圖像說明：主視覺為 AI 輔助生成的原創概念插畫；選型、版本流程與 TLS 圖為原創教學圖解，皆非 Cloudflare 管理介面截圖。