搬兩個公司官網，我先做的不是重設計

這篇在講什麼？

先備份並重建忠實 baseline，不讓重設計綁住搬站期限。
部署流程固定 Wrangler 4，避免外層 action 版本掩蓋實際 CLI major。
DNS cutover 只處理網站的 A、AAAA、CNAME；MX 與 TXT 從刪除條件排除。

搬站最危險的，真的是重寫頁面嗎？

兩個公司官網原本掛在月租建站平台。這次沒有把「搬家」和「裝潢」綁成同一個大專案：先完整備份舊站，各自做出忠實的靜態 baseline，再把重設計留在 preview。搬站有期限，設計則可以繼續磨；兩條路分開，任何一邊卡住都不會拖垮另一邊。

DNS 切換怎麼留一條退路？

部署使用 Cloudflare Workers 的 assets-only 模式，workflow 明訂 Wrangler 4。正式 cutover 仍由人工觸發，腳本只處理 apex／www 的 A、AAAA、CNAME 衝突記錄，MX 與 TXT 從條件上排除。切換後四個網址都曾回 HTTPS 200；這能證明當時網站連得上，不能被放大成「全程零停機」或「郵件零遺失」。

怎麼做

我把流程拆成六個關卡：備份、baseline、獨立 repo、版本鎖定、preview 驗證、人工 cutover。每一關都留下查得到的產物；哪一關失敗，就從那一關重來，不必回到舊平台已經消失的原點。

「四個網址切換後回 200，不能自動等於整段過程零停機；MX／TXT 沒被刪，也不能等於郵件零遺失。」

Codex來源稽核

不可逆的切換不要靠勇氣完成；要靠前面每一步都留有證據與退路。

延伸理解

為什麼搬站時不直接一起重設計？

重設計需要另一輪內容與視覺驗收。先用忠實 baseline 完成可驗證的搬遷，能把期限與風險分開；新版則留在 preview 繼續調整。

為什麼 workflow 還要明訂 Wrangler 4？

cloudflare/wrangler-action 的版本是 action 本身的版本，不等於底層 Wrangler 的 major。明訂版本，才能避免部署環境在不知情下漂移。

這次可以說是零停機、郵件零遺失嗎？

不可以。現有證據只支持切換後四個網址曾回 HTTPS 200，以及流程沒有刪除 MX／TXT；沒有連續 uptime 或郵件投遞測試。

可回退搬站DNS 護欄

本篇由 AI 依去識別且已查核的公開素材包改寫，經人工放行發布。