鑽石舞台

作者：BASS

https://chengpeiquan.com/article/rewrite-in-vite.html

本文寫於年初，文中提到的一些當時還不支持 Vue3 的包，現在可能已經支持了。

從 2021 年元旦 Vite 發布 2.0 Beta 版就一直在關注 Vite 的動態，借着春節放假有時間，而且 Vue 3.0 和 Vite 2.0 都才大版本更新上線不久，預感後面會火，先開荒嘗試一波，也當給以後工作上的業務先提前踩踩坑，對博客做了第三次重構，這一次把客戶端和服務端都重新寫了，由 PHP 的 LNMP 全家桶全部換成了前端側的技術棧。

在經歷了春節假期每天大概花 2 ~ 3 小時的投入，終於如期上線，第一個版本是發布於 2 月 14 日情人節 ，算是給自己的情人節禮物，當時是先部署在我閒置的香港服務器做了一波測試服調試，期間做了一些體驗上的優化，然後 2 月 18 日 在休假的最後一天，部署到我正式服務器上了。

而且特別巧的是，這一天也是 Vite 2.0 正式版發布的日子：Vite 2.0 發布了 - 尤雨溪[1]，同一天上線，就感覺特別美好，值得紀念。

本次重構後，從開發到部署更新的運作流程圖如下，日常只需要維護 GitHub 倉庫的代碼，其他的都是自動化完成。

這次重構，並非是因為放假有空就找點事情做，而是帶着幾個目的來的：

更多的更多，盡在未來，這肯定不是最後的一個版本，還有非常大的優化空間。

其實去年就有想法要對博客做一波改版，但有幾個原因導致一拖再拖，一個是因為業務比較忙（這個沒辦法，工作為重），一個是懶（主要是懶得去思考怎麼設計，當然期間有在考慮一些不同的落地方案），還有一個主要的原因是當時 Vue 3.0 剛發布，我當時主要的精力放在踩坑體驗 3.0，那段時間，大部分的時間和精力都放在撰寫 Vue3.0 學習教程與實戰案例[9] 上面去了，休息時間有限，能夠閒下來的時間也只有下班回來和周末，除掉一些自己的事情外，留下來搗鼓新東西的時間並不算很多，只能先押後了。

相比 2018 年那次改版，當時只是單純想重新弄一個乾淨的博客寫東西，這一次的目標是比較明確了，就是從基於 PHP 的 WordPress，用前端的技術棧全部重構一遍，做一個純前端的博客出來，當然還要保留 SEO ，就要求還要上 SSR（Server Side Render） 或者 SSG（Server Side Generation） 。

由於開工前已經是 2021 年了，因為有前面幾個月玩 Vue 3.0 的基礎打底，非常想用 3.0 來重構博客，加上元旦期間 Vite 2.0 Beta 版剛好發布（就很突然），注意力完全放在了 Vue3 和 Vite2 上面，非常想跑一下兩者結合有多爽。

由於重構的最終目標還是要保持網站的 SEO 能力，所以肯定不能使用默認的 SPA 應用模式，要走服務端渲染，所以技術棧方面只需要考慮兩條線：

雖然在此之前考慮過幾個方案，最開始是優先考慮做 SSR ，考慮過 Nuxt[10] 、Vapper[11] 等一些比較流行的開箱即用的 SSR 框架，但這些框架目前都還在弄 Vue 2.0，甚至部分框架看起來有點 「棄坑」 的趨勢（背靠字節大廠的 Vapper 居然一年多沒更新了 emm…… ）。

加上搞 SSR 的話，服務器成本比較高，我的低配 ECS 可能 Hold 不住，好好玩一玩的話還要投點錢，想了想先算了，那麼退而求次就是上 SSG 。

玩轉 SSG 也是有考慮過一些開箱即用的 SSG 框架，比如用的人最多的 Hexo[12]，但我本身一直對 Hexo 不太感興趣，而且似乎滿大街隨便找一個獨立博客都是基於 Hexo 的，模板也千篇一律，缺乏個人特色。

好友小毅 @chawyehsu[13] 安利的 Saber[14]，跑了個 demo 玩了一下，覺得真的蠻不錯的，原本打算就直接用 Saber 的，不過目前 Saber 還是以 Vue 2.0 為主（聽說下個版本會支持 3.0 ，不過也不知道什麼時候會發布），由於內心實在是非常想用 Vue3 ，所以這個方案最終作為備選。

好吧，對 3.0 的執念，還讓我想起兩個 Vue 官方的作品：VuePress[15] 和它的弟弟 VitePress[16]，他們的新版本都是基於 Vue 3.0，而且已經可以用了，但一直以來我覺得它們都更適合用來寫項目文檔……

期間，Vite 官網在 2.0 Beta 版發布後，也新增了一 Part Server-Side Rendering | Vite[17] 指導如何實現 Vite SSR，我覺得可行。

加上有兩個開源項目讓我非常感興趣，一個是 vite-ssr[18]，一個是 vite-ssg[19]，我也分別對他們跑了 demo ，很給力，So，最後決定基於這兩個開源項目之一，選擇自己搭腳手架……

最終用到的核心技術是：

Vite 2.0 —— 超快的構建工具

Vue 3.0 —— 更強大更靈活的 Vue

SSG —— 服務端渲染方案，利於 SEO 進行內容收錄

PWA —— 構建離線應用

當然還要考慮的事情很多，每個環節還要用到不同的技術棧，具體我在下面逐個環節說明。

下面來說說決定重構之後，整個思考的過程順序，以及對每一個技術模塊的技術棧選型原因分析吧，希望對有計劃重構項目的朋友帶來一些幫助。

其實 Vue-CLI[20] 對 Vue 3.0 的支持已經非常好了，我的 Vue 3.0 教程[21] 也是基於 Vue-CLI 寫的。

之所以選擇 Vite，一方面是它的構建速度真的比 Webpack[22] 要快好多，另一方面是，自從 Vue 3.0 推出以來， Vue 官方團隊就一直在投入精力優化和宣傳 Vite，儘管 1.0 版本的功能和生態不如人意，但超快的構建速度已經體現了出來。

加上在我準備動手重構的時候官方剛好發布了 2.0 大更新，對比了 1.0 簡直是質的飛躍，讓我非常感興趣，而且按照目前官方團隊的態度，我覺得後面 Vite 會逐步代替 Vue-CLI ，提前了解，提前踩坑，對以後的工作也有幫助。

而且在生態方面，Vite 2.0 的各種支持都算很完善了，不得不說整個春節期間，Vue 團隊的人都在忙着給 Vite 2.0 幹活，我在春節提的 Issue，基本上 2 ~ 3 小時就能給我回應，解決問題速度非常快（大過年的耶！），重構過程感覺自己擁有一個強大的技術支持團隊一樣!

開荒雖然辛苦，但也有另一番樂趣！

這是在選擇合適的構建工具之後，應該考慮的第二件事。

個人博客之前一直選擇用 WordPress ，一方面除了有 LNMP[23] 一鍵部署等快速搭建方案，和各種各樣的模板之外，主要也是歸功於 WP 對 SEO 的支持也是非常好，我這個博客的日常訪問都是來自於搜索引擎。

單純選擇用 Vue 3.0 重新開發 SPA 應用肯定會丟失 SEO，所以才有了前面的 技術棧的選擇[24]，本次是通過 SSG 方案來落地服務端渲染。

在開始動手之前，還要對網站架構做一波規劃，盲目動手只能給自己挖坑，自己的博客雖然說內容不多，但也有一些東西要考慮：

當然其他的如移動端適配啥的也要看情況顧及，之前博客還有一個小程序版本，不過因為沒人看（害，真的整整一年過去了，完全沒人看小程序版本…），所以小程序的依賴保留沒有在這次的重構兼容考慮範圍里，重構完畢後我就直接把原來的服務停了，回頭有空了再重新寫一版接口給小程序用。

基於 Vue 3.0 的項目，主要的模板肯定還是 Vue 文件，站點的主要結構、頁面的布局、美化等等都是基於 .vue 文件，只需要按照原來的習慣，路由頁面放在你的 src/views 文件夾下，組件模板放置於 src/components 下，就可以自動生成路由訪問。

同時也加入了 .md 文件的支持，用於書寫 Markdown 格式的內容，日常記錄博客會更方便，並且像 VuePress 那樣，同時支持在 Markdown 里嵌套 Vue，讓博客的定製更加靈活。

整個項目的路由頁面、組件結構，跟你平時開發 Vue 項目是完全一樣的，無縫切換。

在這裡推薦幾個非常方便的 Vite 插件：

vite-plugin-pages[25] ：能夠自動讀取指定目錄下的 Vue / Md 文件生成 Vue 路由，只需要管理好 views 文件夾的層級關係，無需再單獨維護路由配置

vite-plugin-md[26] ：一個能讓 Markdown 文件像 Vue 組件一樣導入使用的插件，它也基於 markdown-it，支持進行一系列 md 生態擴展

vite-plugin-components[27]：可以像 VuePress 一樣，無需 import，會自動根據組件的標籤名去 components 目錄下尋找組件

基本上你只需要按照開發 Vue 項目的習慣去開發就可以了，如果有一些思路被卡住不知道怎麼下手，可以參考我倉庫源碼。

有設計稿的時候我更喜歡藉助 CSS 預處理器（目前常用 Stylus[28]），藉助他們的變量 、 嵌套書寫，以及 Mixin 、 Extend 等功能，避免寫原生 CSS 帶來的煩惱。

沒有設計稿的時候，會用上 Ant Design[29] 等 UI 框架來幫我減少頁面設計上的一些時間浪費，但這些框架通常更適合用在 B 端產品。

去年底在知乎刷到過一篇 如何評價 CSS 框架 TailwindCSS？[30] ，了解到一款全新的 CSS 框架 Tailwind CSS，乍一看很像是在開歷史的倒車，回歸原子類 className ，評價也是褒貶不一，自己光看文檔的時候也是想着這啥玩意…

但是考慮到如果真的是開倒車，憑什麼可以拿到 3 萬的 Star，抱着試一下的心態在這次重構裡面引入嘗試，確實真香！

目前感受到的好處就是：

延續 CSS 的屬性命名，你需要什麼屬性自己放，也就是自己必須有一定的 CSS 基礎，特別是在多端適配方面，不用擔心框架用久了自己不會寫 CSS 的問題

比如，你要實現一個容器內完全居中，手寫 CSS 是：

用 Tailwind CSS 的寫法是：

寫法跟你在 VSCode 里自動補全代碼時，敲入的命令非常接近，不像傳統的 UI 框架一樣，你寫個標籤就自動生成按鈕，都不知道它是怎麼寫出來的（這也是我比較少想用 UI 框架的原因，我怕久了自己都不會寫了），實際上，使用 Tailwind 之後，你還是在自己寫 CSS， 只不過更方便了！

支持 CSS tree-shaking ，構建後的文件非常迷你

傳統的 Atom CSS ，引入了就得整包引入，而 Tailwind 可以藉助 PostCSS ，可以在最終項目構建的時候，抽離出我們用到的樣式，用不到的會被直接扔掉。

我自己體驗了一下，核心樣式文件在配置 Purge 之前構建出來大概有 6M 多，Purge 之後只有 24K ！

可以組合使用，類似於 CSS 預處理器的 Extend

比如，我要寫一個通用的圖片樣式，讓圖片具備自適配不變型的效果，我只需要藉助 @apply 像這樣子：

編譯出來就是我想要的效果：

支持目前主流的暗黑模式，通過 dark:xxxxx 的前綴就可以輕鬆定製兩款皮膚

點一下切換皮膚：

用了 Tailwind 之後，你幾乎可以不用寫 Sass / Stylus 了，那麼問題來了：如何彌補 CSS 預處理器提供的一些功能？

藉助 PostCSS Language[31] 和 CSS Variable[32]，可以輕鬆的書寫像 CSS 預處理一樣的嵌套和變量。

獨立的文件使用 .postcss 或者 .pcss 作為文件後綴，在 Vue 組件里則使用 <style lang="postcss"></style> 來指定 PostCSS Language 。

當然，說的再多也不如親手寫一寫，我之前在知乎也是看了好久始終不能決定用不用，之前趕業務也沒時間，這一次也終於動手體驗了一把，後悔，特別後悔，後悔怎麼沒有早點用！！！

雖然前面的 服務端渲染[33] 幫我們解決了空 HTML 文檔的問題，但要更好的進行 SEO 優化，還需要落實到具體的頁面上去。

比如頁面的 title 、 description 、 keyword 等等，這裡我是用到了以下兩個工具來幫我實現每個頁面的 TKD 定製。

gray-matter[34]：支持對 .md 文件的 TKD 優化，你可以在 Markdown 文件的最前面加入這樣的代碼，即可實現對頁面展示對應的 TKD 信息。

@vueuse/head[35]：可以讓你在 .vue 文件里實現優化，在 Vue 組件里的 script 部分，寫入以下的代碼，就可以實現 TKD 信息的配置。

你還可以擴展更多的信息上去，具體都在各自對應的 Github 倉庫的 README 里有詳細的說明。

當然，SEO 優化遠遠不止這一點，包括 robots 、 鏈接語義化 、減少死鏈 、 舊地址重定向等等，後面也會有說明。

靜態資源指 js 、 css 、 img 這些資源，放自己服務器也不是不好，我之前就是放自己服務器上，沒有去改，雖然 WordPress 雖然有配置 CDN 的插件，但是 CDN 平台諸如七牛、又拍雲，免費額度只針對 http , 都是需要付費才可以使用 https，總的來說還是要多出一筆錢來處理這塊服務，反正自己的博客訪問量不大，而且技術博客很少多媒體資源，日常使用的帶寬消耗很少，我三年前在阿里雲充的 50 塊錢，三年過去了到現在還有 45.91 …

不過這次改版就不一樣了，後續我可能還會開闢一些圖片模塊，加上改版後是把項目託管到了 Github ，先天優勢存在，那麼就要多考慮一下利用 Github 提供的免費服務了！

開發過 NPM 包的同學，或者日常使用 NPM 插件比較細心的同學，應該能夠發現發布在 NPM 上的包都自動部署到了 CDN 平台，諸如 jsdelivr 、 unpkg 、cdnjs 等等，那麼 Github 和這些 CDN 能關聯嗎？在此之前其實我也沒去關注能不能，但這一次我查了一下，確實可以，而且其中對國內訪問速度最友好的 jsdelivr ，支持度最高！超棒的！

關於 jsdelivr 的速度可以參考：國內有哪些靠譜的 Javascript 庫 CDN 可用？[36]，也可以測試下我的博客，我自己對測試結果還是挺滿意的。

所以最後我是把所有靜態資源都指向了 jsdelivr CDN ，它無需你自己再做任何部署工作，只需要把代碼文件更新到你的 GitHub 倉庫里，就會自動同步到 jsdelivr 。

訪問格式為在 jsdelivr CDN 官網[37] 有案例說明，更多用法可以查看官網的文檔 Features - jsdelivr[38]，為了避免項目源碼過大，你可以像我一樣單獨創建一個類似 assets-storage[39] 這樣的倉庫用來存儲這些靜態資源，在倉庫的 README 也有簡單介紹下如何引用 CDN 地址和清除 CDN 緩存。

回到項目里，只需要在 vite.config.ts[40] 里修改 base 的路徑即可。

詳細可以看官網的文檔 Configuring Vite | Vite[41]。

當然這種方式如果你用平時的命令行或者老烏龜界面工具來提交文件，始終還是比較麻煩，這裡推薦一個現成的圖床工具 PicGo[42] ，支持多個平台的 CDN 服務，其中就有 Github 。

你可以在 Github 倉庫上的 Releases[43] 下載最新的客戶端版本，只是使用的話，可以單獨下載對應系統的安裝文件，不需要克隆整個倉庫下來自己構建。

本次的資源導出主要是指原來的那些圖片，前面有提到，我之前沒有啟動 CDN 服務，所以圖片資源都還在自己的服務器上。

WordPress 的上傳資源都存放在 /wp-content/uploads/ 目錄下，阿里雲非常方便的就是，你可以連 SFTP 上去把這些文件直接拖下來就可以了。

重新傳到 Github 上又非常簡單，克隆你的倉庫下來後，放到指定的文件夾里，重新提交就可以了。

等未來某一次你不想繼續用 Github 託管了，只需要把倉庫拉下來，所有文件又都在了，都是非常方便和靈活。

這一部分主要針對原來的文章，雖然我之前的 WordPress 就開啟了 Markdown 編輯器支持，但如 SEO 優化[44] 里提到的，缺少很多 TKD 信息配置，而且裡面的圖片地址也都要更換為 CDN 的路徑，所以就算用現成工具去處理 HTML / XML 轉 Markdown，都還要去補充這些信息，也比較繁瑣。

所以是藉助了 Node 編寫了個靜態爬蟲，在爬取過程中對一些內容進行追加、轉換。

具體的實現可以參考我之前寫的 網站改版遷移經驗記錄：基於 node 的爬蟲編寫[45] ，這裡就不重複贅述了。

既然是 Vue 項目，那麼當然支持 Vue 系的統計插件，之前寫的兩個統計平台插件，都是可以開箱即用的，均已支持 Vue 3.0 的使用。你可以在 main.ts[46] 里了解如何開啟流量的統計上報功能，如果你需要記錄埋點，也都有 API 可以輕鬆觸發數據的上報。

百度統計：vue-baidu-analytics[47]

友盟統計：vue-cnzz-analytics[48]

服務端之前是 WordPress 所依賴的 Nginx + PHP + MySQL ，這一次重構也把服務端直接換了，更換為 Node.JS + Express ，通過 PM2 守護進程來運行在阿里雲。

對，這一次沒有數據庫，第一版暫時不打算做數據庫，暫時用不到，目前大部分數據都已經遷移到 Github 倉庫了，下個版本功能迭代用到了再考慮弄一下。

我的服務器系統是 CentOS 7，也就是 Linux 系統，關於 Linux 下如何安裝 Node ，搜素引擎很多方法，這裡也不贅述了，放幾個自己用到的關鍵命令參考吧。

其他的步驟就不用說了，創建服務器的文件夾，初始化，安裝 express[52] 或者其他你更熟悉的服務程序，搞起吧！

有幾件事要特別叮囑一下：

1. 因為服務端變了，如果原來有開啟 HTTPS，記得重新配置你的 SSL 證書（我用的是阿里雲的免費證書，只需要 1 年更換 1 次）

2. 域名也要重新做 301 重定向（HTTP 強切 HTTPS ， WWW 強切無 3W 等）

3. 檢查之前是否有在推廣的的鏈接掛掉了，也要重新 301 到新地址 （比如 RSS 源之前是 /feed/ ，現在是 /feed.xml）

4. 最重要的，配置上對路由 history 模式的支持

第一版其實不複雜，後面有需要會繼續迭代。

代碼託管在 GitHub 的好處就是 GitHub Actions 可以幫我們實現 CI / CD，通過配置分支的 push 或者 pull_request 等行為來實現自動觸發項目的構建打包，並實現一鍵部署到阿里雲服務器。

具體的腳本可以參考我寫的 workflow[53] ，裡面都提供了注釋。

workflow 里所有以 secrets.XXXXXX 的格式均為倉庫獨立配置的密鑰變量，在倉庫的 settings > Actions secrets 里添加。

其中一些關鍵環節說明如下：

如果其中有什麼環節不清楚的，善用搜索引擎，或者到我博客倉庫給我提 issue 也可以。

如果你不是託管在 GitHub ，而是別的 Git 平台諸如自建的 Gitlab ，你也可以通過 Jenkins[57] 去配置 CI / CD 的支持。

使用 Vue-CLI 創建新項目的時候，可以了解到有一個選項是關於 PWA 的，關於 PWA 的定義建議直接閱讀 漸進式 Web 應用（PWA） | MDN[58] 。

Vite 官方團隊也對 PWA 做了支持，通過 vite-plugin-pwa[59] 可以方便的實現一個離線應用的配置。

不過目前發現了一個問題就是，當 vite.config.ts 的 base 選項設置為 CDN 地址時，構建出來的 PWA manifest 資源路徑會讀取錯誤，原因是 manifest 不能走 CDN，要單獨從網站內讀取，雖然跟作者提了優化建議（詳見 #25[60]），不過還需要點時間去優化。

所以在原版進行版本更新之前，自己先發布了個私有調試包 fix 了這個問題，有遇到一樣情況的朋友可以先安裝 \@chengpeiquan/vite-plugin-pwa[61] 這個去用，不過最好還是留意原版的更新，這個私有包不會長期維護。

2021-02-22 更新：目前原版已更新，Fix 了我反饋的問題，請使用 v0.5.3 以後的版本可以避免該問題的產生，給作者點讚！

關於 PWA 的配置可以參考我的項目，這裡單獨說一下需要特別注意的點：

其他的選項根據實際需要去處理就可以了。

因為網站的設計一向不是我的專長，加上不喜歡花里胡哨的東西，所以這一次重構後的 UI 設計還是基本繼承了原來的風格。

但也有一些新的迭代，比如加上了跟隨系統的暗黑風格（也可以通過導航右上角進行手動切換），還有首頁的變化，對於內容不多的博客來說，挺好的一個 idea，這是來自好友小毅 The Art of Chawye Hsu[62] 和 Vite 開發者 Antfu Anthony Fu[63] 的博客參考。

當然，整個項目的重構，更多的技術支持來自於 Anthony，他也是 Vue 和 Vite 官方團隊的開發者，他比我早幾天上線的 Rewrite in Vite[64] 給了我很多思路，很多基於 Vite 的插件也是他寫的，都是在這幾天發布和迭代，有那種瞌睡來了枕頭的感覺，美妙！

完整的項目依賴和配置請查看倉庫的 package.json[65] 和 vite.config.ts[66] ，整個項目也完全開源了，具體的實現可以查看 Github 倉庫[67] ，在這裡就不贅述了，如果覺得對你有用，歡迎 Star 。