從 Halo 和 WordPress 搬出來之後，他把部落格變成「該動的時候才動」

自架部落格這件事，每隔幾年就會有人宣布「我又重構了」。這次輪到 V2EX 網友 woodchen。他在分享創造節點發文，標題寫得直白：從 WordPress 和 Halo 中擺脫出來，意外發現一套有趣的動靜態結合方法。帖子發出約半天，累積五百多次瀏覽，對一個技術分享帖來說算是安靜但有回音的那種。

先看他為什麼要搬家

woodchen 這次其實寫了兩套系統，一個從 WordPress 遷移，一個從 Halo 遷移，場景不同但基本邏輯類似。搬家的理由也各有各的具體。

WordPress 那邊，他的說法是速度可以優化，但擴展不方便，不像私有倉庫那樣 push 之後就自動部署。

Halo 那邊的抱怨更具體。他提到 Java 記憶體佔用高，專案又去做了商城功能，加上一些變動讓他的文章頁面出錯了好幾週。他描述了一個頗有畫面的 bug：升級到 2.22.x 之後，當文章 slug 是四位數字，例如 1207，訪問文章會被導到文章歸檔頁面。他補充，部分文章是早年從 typecho 遷到 Halo 的，文章 URL 一直沒變過，這次卻中鏢。

為什麼不走純靜態

純靜態部落格是這幾年的主流答案， Hugo 加一個託管平臺就能跑一輩子。但 woodchen 列了幾個他不選純靜態的理由，每一條都跟 AI 有關。

他需要 MCP 讓 agent 能對部落格發布內容；需要接 AI 模型做文章翻譯、產生 SEO 描述，還要能跑自動化的 AI 任務佇列；另外閱讀數這類動態統計，以及內建的 indexnow 推送，用動態後端處理比較省事。

這個選擇剛好跟近期 AI 工具圈的氛圍對上。之前 V2EX 上那篇用 Claude Code 與 Opus 拼出 2D MMORPG 管線的展示文，討論的也是同一件事：把 AI 當成一個可以接上自己系統的協作對象，而不是聊天框裡的問答機。部落格作為自己完全掌控的一塊地，自然成了最順手的接點，這一點在AI 協作拼出完整作品的展示文裡也看得到類似的路數。

那為什麼也不走純動態

反方向的理由倒是簡單。速度，AI 爬蟲方便抓取和閱讀，以及「沒有必要」。三個詞，工程師式的誠實。

他的折衷作法

架構上，後端用 Go 寫，管理端是動態網頁，可以綁其他域名或放在某個 URL 路徑下。關鍵在於：當內容變更時，由 Go 負責觸發 next build，構建出靜態網頁，之後有兩種分發方式。

一種是另起容器，共享前端的網頁卷，需要後端 API 時就反代幾個動態接口到後端。另一種更精簡，直接一個容器搞定，用 go-web-utils/nextstatic 處理 Next 的靜態檔案路由。

他自己下的結論只有五個字：效果還不錯。文末附上部落格網址 woodchen.ink，歡迎圍觀。

部落格重構為什麼永遠有觀眾

把這件事放回脈絡看，自架部落格的重構分享從來不是新鮮事，但這一輪的動機明顯變了。早年是為了速度、為了擺脫平臺的限制，現在多了一條：為了讓 agent 能用。MCP、AI 翻譯、自動 SEO，這些需求在五年前的重構帖裡幾乎不會出現。

woodchen 的方案沒有什麼驚天動地的技術，就是 Go 加 Next.js 加容器編排的老組合。有意思的是那個判斷：哪些東西該靜態，哪些該動態。文章頁面構建成靜態檔案給讀者和爬蟲，翻譯、統計、AI 任務留在動態端。內容變了才重新 build，其餘時間整個站安安靜靜地躺著。

帖子目前還沒有留言，但瀏覽數會繼續爬。下一個正在猶豫要不要搬家的部落格主人，大概會在搜尋結果裡撞上這一篇，然後開一個新的終端機視窗。