SSG 工具比較
網路上這類文章大多都是個人的遷移心得或是 CMS 廠商寫的劣質文章，本文可能是唯一一篇都試過而且告訴你真正的生態系、優缺點、權衡考量的文章，內容包含筆者用過的
Hugo 和 Docusaurus 因為用最多所以篇幅最長，此外還有一些筆者沒用過但是常見的工具介紹。
決策樹
-
如果你只是單純的內容創作者/部落客：直接挑一個現成的 Hugo 主題（比如 PaperMod），永遠不自己改程式碼，那 Hugo 的穩定、單一執行檔和快，很讚。
-
如果你是前端工程師或企業團隊：想要高度客製化、需要靈活的擴充功能，請果斷放棄 Hugo，轉向 Astro 或 11ty。不要為了那幾秒的構建速度用頭去撞 Go Template。
Astro/Eleventy 會說不使用現成主題是因為現成主題少的可憐；會說 Hugo 用戶無須現代 JS 工具請見下方的受限於 Hugo。
Hugo
Hugo 是使用 Go template 模板的 SSG 工具，只提供引擎，網站怎麼做完全由你自己決定。
Hugo 是一個強大且封閉的黑箱 (black box)，你無法知道他的內部運作。基本上你可以把他理解成 iOS，在他幫你規劃好的範圍內你可以使用的很開心，之外就非常痛苦，完全不支援任何外部處理和插件功能。
單一執行檔
筆者認為 Hugo 最大的特色是單一執行檔即可運行無須 JS 生態，因此你可以看到有些主題選擇自行管理 JS library，對比其他基於 JS 的工具你很難看到他們這樣處理 JS 套件，這帶來最大的好處是你的網站獨立於外部工具，即使外部全掛你的網站還是可以正常運行，這讓你在前端這種三年一小改五年一大改的環境中也能單純只依靠 Hugo 的單檔案就能獨立構建。
由於不強制綁定 JS 的關係，Hugo 還有一個特色是很多主題開發者都不是前端開發者，並且 JS 套件使用更少，網站通常都更簡潔輕量且無 JS 環境也能運行，PageSpeed Insights 滿分在 Hugo 是很常見的事情。
速度
如果你的需求就是要快那 Hugo 確實是一時之選，但是請繼續看完本文再想想是否能承受快的代價。
可規模化
速度快不見得可規模化，Hugo 的規模化已經經過實戰驗證，可以把美國政府的歷史紙本文件數位化，百萬級別的 V&A Explore The Collections, over 1 million pages generated by Hugo 也有能力構建，其他工具如 Docusaurus 在20000 個頁面的文檔則會失敗。
專案直覺簡單
Hugo 模板主要基於 HTML，因此不需要學習前端世界換來換去的各種框架，Angular React Vue 都和 Hugo 無關，從一而終就是 HTML/CSS/vanilla JS 搞定。
最重要的是大部分的錯誤都可以自行解決，報錯了就是找報錯檔案，不像現代前端重重依賴要判斷這個錯到底是誰引發的。
模板覆蓋功能
Hugo 可以在專案根目錄建立同樣路徑的檔案覆蓋主題的同路徑文件，這是很多 SSG 工具都做不到的重要優勢，這個功能讓你能夠輕鬆的覆蓋指定檔案且上游有新版本時仍然可以輕鬆更新。
整合現代前端
Hugo 的 js.Build 可以讓 assets/js 直接用 import 語句導入 node_modules 套件，然而如果是開發主題而不是自用，這種方式需要下游用戶也自行安裝 node_modules 套件造成麻煩，因此這也促使 Hugo 主題會把 JS 套件打包進主題內部或是直接使用 CDN。
js.Build 也支援 TypeScript 和 ESM 模組。
由於 Hugo 是模板語言因此不可能使用 CSS modules。Hugo 也難以整合 Svelte、React 等框架，如果需要他們獨有的特性那就不該選擇 Hugo。
前後端混雜
任何專案都應該縮小技術棧，技術棧不是生產力應該越少越好，這對新手、老手、專案初建、專案維護都是正面幫助。
然而這就是 Hugo 最大的問題，明明是在開發前端專案卻要顧及後端語言 Go，這是享受後端語言強大性能的必要妥協，但 Bootstrap 也因此從 Hugo 換到 Astro (ref1, ref2)。
就算不提語言特性單就語法本身，開發 Hugo 所有語法都要重學，舉例來說所有語言執行「一加一」都是 1+1，但是 Hugo 要用 {{ add 1 1 }}，這個範例展示了 Hugo 所有語法都要重看文檔，而文檔又是另一個問題。
再次強調 Hugo 所有 API 都要看文檔，所有學過的語言都無法協助判斷同樣功能怎麼在 Hugo 使用，所有東西都要看他的文檔才知道要怎麼用。
文檔糟糕透頂
文檔又導致 Hugo 語法學習問題更大。在 Bootstrap 從 Hugo 換到 Astro 裡面有提到文檔問題，網路上和 Hugo 論壇也都有人提到文檔問題。
行為需要用猜的
Hugo 運作就是黑箱，你不知道他裡面是怎麼做的，只能去翻 Go 源碼，這就讓前端開發者難以閱讀。為什麼不看文檔？因為文檔非常爛，連自己是怎麼運作的都寫不清楚，濫用 glossary，在 glossary 裡面卻又根本沒完整解釋，搞懂 Hugo 的行為是開發 Hugo 專案最痛苦的地方。
比如說 ToC，Hugo 連檢查有沒有 headings 這種超級簡單的工作都可以變成一個討論串還有多種解法，筆者看過最神奇的方法是判斷 gt (len .TableOfContents) 33，因為沒有標題的目錄會渲染 33 個字符，這個範例同時展示了受限於 Hugo、文檔不明確、開發不線性的問題，這只是冰山一角，實際上 Hugo 開發每天都會遇到類似問題。
受限於 Hugo
Hugo 內建整合非常多東西，如 Sass / Tailwind / Pipeline / 影像處理等等都開箱即用，但是不支援的就麻煩了，Hugo 完全是黑箱沒有任何插件功能，而且是 go 語言前端人員也難以做到自己 fork 修改。
此外，Hugo 沒有金主基本上是用愛發電，因此即使你的 PR 合理簡單維護者也有自己的想法決定要不要 merge。
成熟度
Hugo 的大優勢是已經十年了因此足夠成熟，不只現成主題數量大幅碾壓其他對手，也支援各種怪怪的方法，期待已久的 versioning 功能也已經支援，筆者的 hugo-yore 是全世界第一個支援 versioning 的開源 Hugo 主題。
Hugo 的成熟度也帶來很多開箱即用的方便功能，如 permalinks 設定、render segment、content adapter、UFS override 系統，這些在其他框架都需要手動完成甚至不好完成，而 Hugo 是開箱即用。
生態系
生態系的重要性不言而喻，然而 Hugo 即使已經十年還是有很多不足，例如 prettier 處理 Markdown shortcode 的方式錯誤，好在 Markdownlint 可以正確處理；但是對於包含 Go template 的 HTML，prettier-plugin-go-template 作者已經不再維護，對 Hugo 開發是致命問題1。
相反的，因為 Hugo 多數功能都只是 HTML 模板因此很少會有模組不能用的問題，會碰到過時模組通常也只是用了 Hugo 淘汰的 API 只要照 error message 提示就可簡單修復。相較之下 Hexo 專案修復過時模組就因為 JS 互相依賴變的非常複雜。
插件系統
Hugo 完全不支援插件，因為很重要所以這個資訊是獨立段落。
穩定性
作為單一 binary 無依賴的執行檔，他很穩定；在不同版本之間頻繁 deprecation，非常不穩定。
專案狀態
Hugo 最大的隱患是維護者只有兩人，加上前面說的前端開發人員難以貢獻 Hugo 專案，這是極度不健康的專案狀態。
請注意我絕對沒有要否定維護者的貢獻，他們已經穩定持續無償付出多年，這裡只是讓事實透明。
企業環境運行
Hugo 沒有應用程式簽章因此有 compliance 問題。
綜合專案狀態、語言特性、維護成本、人員招募問題，筆者也不覺得企業使用 Hugo 是明智的決定。
Hexo
Hexo 基於 JS 因此和 JS 生態使用更為融洽，適合有前端經驗的用戶，也意味著你需要處理 node_modules 的各種問題。
Hexo 構建效能已經不再是劣勢，然而專案維護狀態和他的生態系在 2025 的今天已經不忍卒睹，上網搜尋 Hexo vs Astro 全都是從 Hexo 遷移到 Astro 的文章，不過由於筆者沒親自用過 Astro 所以沒有把他寫成一個獨立段落。
Docusaurus
Docusaurus 是文檔 SSG，如果你的 Markdown 文件數量不超過兩萬23 就可以毫不猶豫的選擇 Docusaurus 放棄 Hugo，因為幾乎所有東西都幫你做好了而且構建時間還能接受，相較 Hugo 所有文檔主題 Docusaurus 可以說是爆殺級別的存在：
- 完美的 SPA 導覽，同時又有 MPA 的網站架構
- 官方完美整合 Algolia 搜尋
- 支援多版本文檔
- 豐富的插件生態
- 支援 MDX
此外還有幾個特點：
- MDX 對應的是 Hugo shortcode，但是 Hugo 使用 shortcode 只是很簡單的使用 template 把 MD 轉為 HTML，而 MDX 卻多了一套轉換步驟從 MD > JSX > HTML，且 MDX 有自己的獨特語法，又要多學一套不同的東西。
- Docusaurus 從 3.6 發佈 Docusaurus Faster 計畫的第一版本，使用 Rspack 加速，因此有追上 Vitepress 的速度。
- Docusaurus 使用 React 因此學習成本非常高，明明只是要簡單建立一個客製化頁面，卻要學習整個 React + Docusaurus 生態系，比如說在指定文章開頭加上遷移資訊，Hugo 改模板只要 20 行程式碼就可以搞定，Docusaurus 要學他的整套 API 加上 JS 套件的知識。不過對於本來就熟 React 的團隊這不是缺點。
唯二選擇 Hugo 放棄 Docusaurus 的原因筆者認為只有兩個，第一個是你的文檔數量超多需要 Hugo 的性能，第二是你需要連 Swizzling 都滿足不了的超級自定義，但是符合這些情境的用戶能有多少，所以才會直接說基本上文檔網站直接選 Docusaurus 就好了，而且選 Hugo 還要承受前面說的那些代價。
Vitepress
Vitepress 也是文檔 SSG，和 Docusaurus 的差別是兩者分別 Vue/React，以及 Vitepress 是新工具因此更少歷史債，比如說 Vitepress 直接整合 shiki 而 Docusaurus 用的是 PrismJS，其他筆者認為大同小異，主要還是看 Vue 和 React 的語言選擇上。
MkDocs
MkDocs 是使用 Jinja，基於 Python 的文檔工具，Python 專案可以使用因為有插件支援自動生成 Python 文檔也無須另一個語言的套件包，但是瀏覽體驗還是 Docusaurus/Vitepress 更好，即使用 Material for MkDocs 也一樣。
MkDocs 本地開發的響應速度明顯比上述工具更慢，且設定更破碎難找，跟 Hugo 文檔的程度有得比，筆者不認為 Python 專案以外的文檔應該用他。
Sphinx
Sphinx 是一個文檔建立工具，支援自動生成 Python 專案的文檔，其他功能都很陽春且古老，除了自動生成 Python 文檔以外的任何情況都不應該選擇 Sphinx。
GitBook
GitBook 原本是一個開源的文檔工具但現在已經完全轉型成商業 SaaS 平台。Markdown 是一個很簡單易學的語言，不認為任何有一點點技術能力的團隊需要選 GitBook。
docmd
docmd 特色是一鍵啟用的文檔網站，連設定都不用，並且支援多個 hook 讓你自定義構建邏輯。他的核心邏輯是在 node.js 環境構建網站，建立原生 HTML/CSS/JS 網站，預設幫你建好 AJAX 流暢換頁（類似 swup/barba.js 這種效果），背後的核心邏輯是 docmd 自己建立的模板工具 lite-template + markdown-it 轉換成 HTML。
對於一般用戶可以單行指令啟用網站，對於進階用戶提供的 hook 很實在：
- markdownSetup: 可自訂 markdown-it，如 custom container (
::: new-container-block) - onBeforeParse: 可自訂 markdown 在 docmd parse 之前的處理，因此甚至能做到建立 shortcode
docmd 內建離線搜尋，versioning 功能也很棒，看看 Hugo 非常 verbose 的 versioning 功能，至今 Hugo 官方連使用文檔都寫不出來。
然而問題也很實在，完全無法 override 模板，預設的 HTML 結構無法更改，只能用 onPostBuild 這種蠢方式來處理，不然就是自己 fork 一份。如果他能做到模板 override 功能至少可以吃掉一半的 Hugo 文檔網站用戶，因為 Hugo 網站普遍沒有 SPA-like navigation，而且 Hugo 本身的文檔也是一坨。
如果終究是如果，目前來說 docmd 的目標用戶真的就是想要一鍵建立文檔而且還不在意外觀的人，我想不到其他人有什麼理由不用 Vitepress、Docusaurus、Rspress、甚至 hugo-yore、hugo-deca。
其他沒用過的
- Astro: 最熱門的新框架，基於 JS 的島嶼架構，不再需要整個頁面 hydration，每個組件可獨立注水，除此之外最重要的是不限定 JS 框架，是目前最新穎最受歡迎的、基於 JS 的 SSG。2K Games, Cloudflare 和 Netlify 官網以前都用 Hugo，2025 的現在都用 Astro，由於個人網站幾乎用不到 Astro 提供的優勢因此我就沒有嘗試了
- 11ty: 和 Hugo 一樣核心是模板，只有一個維護者，構建速度能和 Hugo 打的有來有回，但是沒有主題概念。我覺得架構沒有設計的很好，到處都是 js 檔案，我很不喜歡把文件和原始碼混在一起，明顯是設計給開發者用的。
- Zola: 和 Hugo 一樣核心是模板，只有一個維護者，近兩年已經不再開發，不該使用
- Gatsby、Jekyll: 非常老，不該使用
- NextJS/Nuxt: 對於個人網站技術負擔明顯過重了
開發狀態也是重要指標，可以點進該專案的 insights > contributors 頁面查看，兩大重點是提交次數和提交人數，分別代表維護狀態和社群活躍度。