Day 2｜一次 Next.js 升級，讓我重新考慮部署架構

上一篇提到，這次網站選擇 Cloudflare ＋ Astro。除了成本和開發速度，還有一段之前的開發經驗，影響了這次的選擇。

當時我們為了使用新的功能，打算把專案從 Next.js 14 升級到 16。升級過程中，才碰到原本部署工具的支援問題，最後連部署方式也需要一起調整。

當初我們用 Next.js 開發網站，也希望能自動部署到 Cloudflare Pages。中間用到的工具，叫作 @cloudflare/next-on-pages。

翻回當時的部署設定，可以看到這些欄位：

Build command: npx @cloudflare/next-on-pages@
Build output: .vercel/output/static
Build comments: Enabled

它像一個轉接頭，把 Next.js 的建置結果整理成能部署到 Cloudflare Pages 的形式。next-on-pages 官方專案

這也代表，除了 Next.js 和 Cloudflare，我們還得留意這個轉接工具能支援哪些版本。

我們原本就有升級 Next.js 的目標，希望能使用新版本的功能。

但在升級過程中，我們遇到 @cloudflare/next-on-pages 的支援問題。原本搭配舊版 Next.js 使用的部署方式，成了這次升級需要一起處理的部分。

回頭查這個工具，官方 README 已經明確標示 deprecated，也就是棄用，儲存庫也已封存，並提供遷移到其他工具的方向。官方棄用公告

所以那次的工作，除了升級 Next.js，還包括調整部署方式。我們花了不少力氣，才完成從 14 到 16 的升級，並讓 Cloudflare 上的自動部署流程跑起來。

這段經驗讓我更在意：框架要升級時，原本搭配的部署工具能不能跟上。工具棄用不代表舊網站當下就不能跑，但對想繼續升級的專案來說，部署路線也需要重新評估。

所以到了第四個網站，我會先看框架和部署平台怎麼配合。尤其已經決定繼續用 Cloudflare，就會更在意這條部署路徑由誰維護、版本升級時要跟著調整什麼。

不過，前面那個 next-on-pages 也是 Cloudflare 提供的工具，是這條整合路線是否仍在維護，以及未來升級時該怎麼走。看到「官方支援」，也還是得留意它的維護狀態。

經歷過前一次升級，除了框架寫起來順手很重要，改完程式之後能不能順利上線，以及維護成本也要考量進去