Blog 的框架選擇

2026年7月13日· 約 14 分鐘閱讀

其實 Blog 前端框架是個很特別的存在，有的框架就是為了寫 Blog 和 Docs 而存在的。

我們在這裡，先探討為什麼主流框架不適合當 Blog。

主流框架和技術棧，適合當 Blog 嗎？#

但在談「主流」之前，我們先來劃分這條界限在哪？
我把它劃定在目前討論度很高，並且可以寫出各種網站的技術棧，並且不專為文字內容服務。

市場上的絕對主流#

那目前前端最熱門的技術棧，依舊是 React，與之搭配的，還有來自 Vercel 的 Next.js。

前者是老字號，什麼都能做，但是隨著更新，更多的 Virtual DOM，無論編譯時間，還是網站本身，都非常肥大。
Next.js 則是後起之秀，雖然是開源 JS，但實際上他的獨家特性，高度依賴 Vercel 服務，部署在 Vercel 上，體驗絲般順滑。

我上學期修的網頁課(前後端加資料庫)，明明只交三件套，結果期末也是出現至少 5 組 React，有大概 2、3 組搭配 Next.js，可見熱門程度。

但這兩個最早被我否決。
前者光是編譯就很肥了，產出來的網站更肥，一大堆 Virtual DOM，從根本上我對 React 排斥。
後者的完整優勢要搭配 Vercel 才能完全搭配。
但最主要的，作為 Blog，用上述兩個技術棧，完全是殺雞用牛刀，就跟為了玩 Galgame 跑去組工作站 HEDT 一樣。

關於 Vercel 那段，雖然部署和前端的選擇，對我而言是高度綁定的，但是這篇會專注在前端選擇，之後的供應商選擇會獨立一篇。
那裡會說 Vercel 對我有什麼問題。

新興勢力#

那看向新興勢力，我比較看好 HTMX、Svelte 和 Lit，這是更貼合三件套原始標準的技術棧。
雖然更優雅，但是我沒選，為什麼？

這三者同樣都是「用不到」的問題，讓我說說用這三者架 Blog，是怎麼「過度工程」的。

HTMX 設計理念是「把互動邏輯留在伺服器」，Blog 恰好互動邏輯通常不多，HTMX 要寫 swap 機制，只載入必要的 DOM。
除非 Blog 從設計之初，互動這件事就是首要考量，不然 HTMX 那高效的局部 DOM swap 會成為維護者的額外負擔。

Svelte 則可以說，就是一個編譯器，.svelte 寫完後，會編譯出一套靜態的 JS，從 React 在 Runtime 的開銷，轉嫁到 build time 上。
在心智模型上，React 不管什麼模式，都會比 Svelte 還要難掌握。

基本上要用 Svelte，大家都會用 SvelteKit，這樣不用自己重寫一堆函式和元件。
不過 SvelteKit 面對 Blog 這類需要 SSG (Static Site Generation) 的場景，其實不是絕配。
用 SvelteKit 來當 SSG 有多不配，我打個比方：你買了一個 9900X3D，結果碰到 CCD 調度問題，所以把沒有 3D V-Cache 的 CCD 關掉，換取打遊戲更順的體驗。

Lit 則是由 Google 主導的 Web Components 函式，Web Components 的目的主要是跨框架、跨團隊、多技術棧可以重複利用元件，基本上目標是 Adobe、Red Hat、SAP 這類大公司才會用到。
Web Components 本身對於 Blog 而言，正好不需要，誰會沒事一個網站同時有整套 React、Svelte + Vue.js、Next.js？
更要命的是，Web Components 依賴 JavaScript 與 Shadow DOM，這會使的 SEO、無障礙、SSR (Server-Side Rendering) 都要額外處理，正好弱點打在內容網站的痛點上。

三件套總行了吧#

三件套確實是網頁的起點中的起點，但問題是，這無異於你要從頭開始手刻所有東西。

寫個網頁，每個網頁都要先 <!DOCTYPE html>，然後接 <html lang=zh-Hant> 嗎？我可不要！
純靠 JS 直接手刻我現在的 Blog，我不敢想像，我的標籤系統怎麼寫，路徑怎麼寫，太恐怖了！

更不要說一旦牽扯到 MPA 和 SPA，那是真的很恐怖…

還有一點，我現有的文章都是 Markdown ，用三件套那我要全部重新編寫…

服務文字內容的前端框架#

生態多變的前端，有基於 JS 和 DOM 疊出全能獸，那自然就有針對我們這類，以內容為主的框架。

如果你不考慮盈利，或者盈利不是目的，單純想看適合個人 Blog 適合的框架，可以跳到主流 Blog 框架

因為這段你有盈利的打算，會直接影響你的生計，並且這一段，可以看到上游的決策會怎麼影響一個套件的維護與操作。
如果有興趣就接著看即可。

老牌 Blog 王者：CMS 的代表#

以 Blog 來說，WordPress 是個壓倒性的存在，上個時代的霸主，是個資料庫驅動的 CMS (Content Management System)，但在現在逐漸沒落。

原因是多面向的，首先是其 PHP + MySQL，來自千禧年初的老組合擺到現在，效率低下。
對我這種寫過現代技術棧的人，這組合更是妖孽，PHP 放在網頁，代表 All in one 的全端代表，而現代網頁更多是前後端分離的架構。
MySQL 也是值得炮轟的對象，對比其他關聯式資料庫，MySQL 顯得更為奇葩，現代技術人選開源資料庫，首選會是 PostgreSQL，但相比 PHP，MySQL 的問題只能算是從罪行降級成技術品味和大眾度而已(畢竟 MySQL 仍舊很多人用)。

這類全端架構還帶來一個額外的問題：安全性
跟 Windows 一模一樣的配方，為了相容性，WordPress 核心雖然早已支援到 PHP 8.3，但大量外掛與主題仍停留在 PHP 7.x、甚至相容 PHP 5.x 的老舊寫法，開發者為了不打破舊站相容性，往往不敢貿然升級，十分糟糕。
但是更大的問題是，WordPress 的外掛與主題才是最大的破口。

權限模型上，任何主題、外掛沒有被隔離或沙盒化 (sandboxing)，就跟用 root 裝 AUR 一樣，可以橫著走。
然後 WordPress 在審核機制上，又很薄弱，只看有沒有明顯惡意程式碼，但不做漏洞審查。
供應鏈攻擊不用說，跟 6 月 AUR 同一個病種。

然後你再看看 WordPress 的運作架構：收到請求 -> 即時查詢 MySQL -> PHP 即時渲染 -> 每個 hooks 鏈式呼叫，任何外掛都能攔截、修改請求流程

最要命的是，WordPress 的易用性天生吸引非技術人，像我光看到 PHP + MySQL 就足以勸退了。
技術人更新個東西都不一定勤勞了(尤其臺灣，能動就好)，那非技術人呢？動輒數個月的上線週期，有洞，就算開源也不會修，搞不好連有洞都不知道。

最後補上比較少人會注意的：治理層面
WordPress 的創始人 Matt Mullenweg 從 2024 年就開始與 WP Engine 有很大的爭議，據報導，Mullenweg 採取了相當激烈的手段。

只是要命的是，Mullenweg 同時也是 Automattic (也是 WordPress 的商業公司) CEO。
WordPress 的主題雖然開源，但是抓取服務實際上在 Automattic 上，Mullenweg 實質上不止創造和維護 WordPress，更是直接控管 WordPress 生態，至於接管 Advanced Custom Fields 外掛這個最有爭議的行動則是後話。

從這場官司來看，我認為 Mullenweg 的身份和行為，顯示出了治理的窘境，權力過於集中，因此 WordPress 也流失了一批開發者。

不過最扎心的是，現在多數非技術人根本不需要網站——臉書、IG、Tik Tok 這些平臺直接就能經營個人品牌，順便還能變現，比起自己架站划算多了。

簡單來說：對技術人，WordPress 架構落後、坑又多；對非技術人，直接經營社交平臺就好；真要寫作變現，方格子、Substack、Medium 更合適；真要 CMS，Shopify、Wix 這幾年也在 WordPress 走下坡時持續成長。

WordPress 的替代品#

這個框架說來有趣，創始人 John O’Nolan 曾是 WordPress 的重度使用者，甚至是核心開發者之一，等到 WordPress 變成通用 CMS，變得過於肥大，他受不了了，公開炮轟。

這個背景之下，Ghost 誕生了。

先來說說治理這部分，親身經歷過 WordPress 的管理，他知道球員兼裁判的問題，所以選擇了非營利基金會，屬於商業上很中立的存在。

那 Ghost 延續的是 WordPress 那套個人網站理念，但卻內建會員訂閱、電子報等功能，因此更多是商業部落格在使用。
所以 Ghost 主要的競爭對手反而是 Substack 和 Medium。

那既然源自於 WordPress，那自然 CMS 那套運作架構被延續了下來，所以 Ghost 除了使用 Ghost Pro 來代託管以外——

你只能 Self-host 才可以架設 Ghost。

簡單說一下，由於我手邊沒有多餘的機器，也不想為了周更都不一定的 Blog 花電費，所以這是我不選 Ghost 的主因，但我有解法，所以後面會說其他原因。

說回架構，Ghost 有 Admin Panel、Content API、Ghost Core 和 MySQL 這些東西，畫成圖大概關係是這樣：

Admin Panel（寫入/編輯）─┐
                       ├─→ Ghost Core (Node.js 常駐程序) ─→ MySQL
Content API（唯讀）─────┘

關鍵問題在於 Ghost Core 和 MySQL，前者需要常駐 Node.js LTS 程式，對，他是要一直存在，並且跟隨 LTS 版本。
MySQL 這塊則是大家都懂，關聯式資料庫要麼上專業託管平臺，要麼獨立一臺 Server，如果你真的經營得有聲有色，希望你跑 MySQL 的 Server 扛得住。
並且他還是強制綁定 MySQL，只有 SQLite 是作為開發，或者低資源 Self-host 場景才適合使用的，但想上生產環境，請乖乖 MySQL 上。

至於我喜歡的 PostgreSQL，非常難過，並不在 Ghost 的支援範圍裡面，1.0 前有零星使用案例，1.0 後官方直接沒有再跑過。
雖然社群還有零星嘗試，但用的人太少，官方大概也不會重新重視，認真想賺錢的話，還是乖乖上 MySQL 吧。

所以常駐 Node.js 和需要一個資料庫直接綁死機器環境，Cloudflare Worker 這類 serverless 的路別想了。
你只有 Self-host、或者上 Ghost Pro，這裡 Self-host 包括本地和上雲租 VPS。

你鐵了心想 Self-host，我建議你可以先學好 IaC (Infrastructure as Code，基礎建設即程式碼)，Ansible 的冪等性可以幫助你減低一些煩惱。
沒那技術，那我建議你直接上 Ghost Pro，畢竟資料庫調教也是一門學問，Self-host 還要注意 Node.js 和資料庫套件版本，你寫文章的時間會被這些瑣事分掉。

那總結來說，如果你有技術基底，或者你不介意多花代管的錢，並且打算成為職業寫手，Ghost 很適合你。

至於我，雖然高等教育學生身份要拿 Azure 等優惠很容易，但我不想要電子報和付費牆，這不利於知識傳播。
我站在開源技術和公開知識的肩膀上，我認為吸收這些公開知識後，然後再拿這個賺錢很不厚道。
所以這是我不選 Ghost 的另一個原因。Ghost 很不錯，只是不適合我。

主流 Blog 框架#

終於來到這塊了，到了這裡，恭喜大家，基本都是 SSG，只是偏好取捨而已。

常見的有 Hugo (沒有 Boss，不賣衣服)、Hexo (主要是中文圈)和 Jekyll (老了)。

這些 SSG 都支持 Markdown 解析，所以你可以寫完 Markdown 後，丟進去，讓框架編譯時幫忙轉成 HTML。

然後除了 Jekyll 以外，剩下的要嘛 Self-host，要嘛丟到 Cloudflare Worker、Vercel 等託管平臺，都可以。

Hexo#

先來說 Hexo，臺灣人寫的，所以中文領域很多人用。
我架設 Blog 的時候，兩個學弟用 Hexo + Fluid 搭配 GitHub Pages 架設，採用率跟 Hugo 持平。
但我身邊和我看的 Blog 樣本就這麼多，所以比例上不太準確，網路上 Hugo 的採用率還是最大宗。

那 Hexo 本身跟 Hugo 相比，沒有特別突出以外，近年維護率下降，TypeScript 支援加入的速度很慢。
這也導致了佈景主題的 TypeScript 採用率不高。

對於 Hexo，我的建議是不要看，我在逛 Astro 主題的時候，已經看到有 2 人從 Hexo 跳到 Astro 了。

Hugo#

市場上的絕對大宗，跟 Hexo 差不多時間點(晚 1 年)出來的。
不過我身邊 Hugo 實際使用者是 1 人，如果算上我有在看的 Blog，那就是已知 2 名使用者。

同樣是被 Jekyll 逼出來的專案，從 Ruby 改成 Go 來寫，Hugo 本身甚至只有單一執行檔。

編譯速度極快，1000+ 的 Markdown 文章編譯，1 秒以內就能編譯完成。

既然很多人用，編譯速度又快，為什麼我不選 Hugo？

因為 Go Template 比較難寫，我也沒有寫過 Go 語言家族的經驗，而且我當時有自知，能周更都算不錯，假設我真的要寫 1k 篇文章，我大概要花 2.5~3 年才到得了。

Go Template 難寫其實不是問題，去套用現成的主題就好，Hugo 的 Blowfish 就是非常知名的主題，為什麼不這麼做？

原因在於我想在 Blog 上做的系統，很多 Blog 其實還在用 WordPress 那一套分類法，在 Astro 章節我會稍微展開。
這時候不熟 Go Template 就是一大障礙，既然把功能設計列在第一順位，那不熟 Go Template，不是在從頭設計主題時會碰壁，就是套用現成主題要改時，還要先搞懂原作者怎麼寫主題。
不管哪一種，都會徒增開發成本。

其他#

快速帶一下其他的：

Jekyll: 鎖死 GitHub Pages，使用 Ruby，不熟的人很痛苦，並且編譯速度慢到 Hexo 和 Hugo 誕生。
11ty (Eleventy): 2024 年被 Font Awesome 收購，2026 年初改名為 Build Awesome，核心維持開源 MIT 授權，但官方力推的付費 Build Awesome Pro 跟原本開發者社群的極簡哲學不太搭，長期方向會不會被稀釋，社群還在觀望。並且 11ty 預設乾淨過頭，要疊東西不太方便。

我的選擇#

最後我選擇的是——

Astro

選擇背景#

我選用 Astro 時的背景很特別，我身邊只有 1 個學弟使用，也沒其他在看的 Blogger 用，為什麼這種情況我會選 Astro？

先說 Astro 的設計，他是預設零 JS 產出，真的需要互動元件等 JS 元件，也有群島式設計，局部載入 JS。

這些設計讓 Astro 的編譯速度和瀏覽體驗還不錯。
怎個不錯法？無論是官方 Template，還是開源主題，可以看到很多 Lighthouse 100 (性能) / 100 (無障礙) / 100 (SEO) 的主題。
並且還有自動壓縮圖片，任何丟到 src/assets 的圖片都會被壓縮成 .webp，這對流量的節省帶來正面幫助。
對比之下，大多框架這件事要自己手動做，包括 Hugo。

除此之外，最主要是「開發成本」，當時無論 Gemini 3.1 Pro，還是 Claude Sonnet 4.5 都跟我推薦 Astro。

因為當時我沒有前端開發經驗，所以他們基於入門難易度，推薦了 Astro。
這個難易度有多重要？我要寫一套「幾乎沒有」個人 Blogger 會用的分類系統，也就是這 Blog 的 Tags (標籤)和 Series (系列文)。
為什麼這兩個是我創 Blog 的核心需求，我放到開發歷程再說。

再來部署難易度，跟 Hugo 一樣，GitHub Pages 和 Cloudflare Worker 都可以上去。

最後是編譯速度，我已經在前面算過那筆帳，Hugo 那種大量文章編譯，我需要寫至少 2、3 年才有感覺，並且也不是天天編譯。
就算文章多到 1 千多篇，不是日更的話，那跑個 1、2 分鐘也能接受。

其他誘因就是國外的首選也在從 Hugo 變成 Astro，熱門度可見一斑。

所以就是一個開發和瀏覽體驗皆屬於最優秀，編譯速度在文章量上去略慢，但能接受的狀況，並且熱門度也同屬第一梯隊(至少在歐美是這樣)。

實際使用#

從 3 月選用 Astro，到現在經歷 Astro 7 升級過後，我自己也積累一些心得。
順便說明一下當時到現在經過了哪些變化。

先說開發體驗，確實非常舒服。

.astro 寫頁面時，基底是三件套，寫元件時，則是 JS 和 TS 混合的感覺，元件和頁面自己的 CSS 用 Style 包起來(不是 inline CSS)，再來少部分服務 Astro 路由和其他功能的語法，所以門檻確實比較低。

如果你搭配 Cloudflare Worker，安裝好 Wrangler 後，pnpm preview 的運作環境，會跟 Cloudflare Worker 如出一轍，Preview 碰到的問題，推上去後 Worker 也會呈現。

在編譯上，雖然 Astro 7 把 Markdown 解析器預設換成 Sätteri，編譯速度有所提升，但對於我目前的文章數量而言，編譯速度理論上影響不大。
除此之外，用 Go 寫的編譯器也被替換成 Rust，換來小額的編譯性能提升，不過編譯器 Rust 化的意義，更多是跟 Vite 8 統一語言，降低維護難度的意義更大。

出於插件相容性和解析器穩定性，我暫時保留 Remark，沒有把解析器換成 Sätteri。
升級到 Astro 7 後，Cloudflare Worker 上線速度維持在 30 秒至 1 分半之間，附上最新的編譯記錄：

目前有統計的，新編譯器和 Sätteri，帶來的編譯速度提升約 15% ~ 61% 不等，比如：

金主 Cloudflare 的開發者文件(8,431 pages): 386.89s -> 261.94s
Astro 官方 Docs (~6,313 pages): 114.54s -> 73.53s

大致就是這樣，至於為什麼我會選 Cloudflare Worker，就是下一篇的主軸了，託管平臺說完，會再來講開發歷程。

Reference#

本文屬於：Blog and Author › Blog 架設之路 › 架設之前