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]，同一天上線，就感覺特別美好，值得紀念。

LightHouse 的打分

運作流程

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

博客運作流程

重構的價值

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

1. 提前開荒 Vite 2.0[2] ，為公司后續的業務提前踩坑，可以為團隊進行技術選型提供幫助，因為之前我在做 JSSDK、Vue Plugin 的時候，已經開始脫離 Webpack，用 Rollup[3] 作為構建工具，而 Vite 正是基于 Rollup ，不僅構建速度非?？欤乙蚕?Webpack 一樣提供了熱更新，對于一線開發來說，體驗上是非常好的，而且它還是 Vue 團隊大力推廣的新工具，這讓我很有興趣去研究它。
2. 了解一下當前的一些新生的前端工具，比如 UI 框架方面之前一直停留在適合 B 端產品的 Ant-Design、 Vuetify 、 餓了么等等，說實話我做 B 端產品的時候才會用，面向 C 端因為有設計稿，我基本上都是手寫樣式，聽聞新一代的 UI 框架 Tailwind CSS[4] 已經有一段時間了，雖然很奇怪為什么還會回到十年前一樣用原子類的 class，“開倒車” 竟然還有 3 萬多的 Star，讓我非常的好奇到底為什么，結果一用，真香！沒錯，這次博客的樣式，就是用的 Tailwind 。還有像 CSS 預處理器之前也一直停留在 Sass / Less / Stylus 三駕馬車，這一次我拋棄了他們，用上了 PostCSS Language[5] + CSS Variable[6]，也是真香！
3. 借此機會多了解一下生產環境的服務端開發，公司業務幾乎沒有機會讓自己實操服務端，所以大部分情況下都是在跑本機的 Server，很多場景是開發環境下遇不到的，要想進步，還是要多在生產環境磨練。
4. 接觸更多優秀的開源作品，比如代碼語法高亮之前一直只知道 highlight.js[7] （因為 WordPress 的高亮插件就是用這個……），這一次我是用了 prism[8] ，更小巧，顆粒度更細，雖然目前還沒有太多時間去定制代碼高亮的配色，不過后面有時間想要處理，prism 會更加方便。
5. 享受從 0 到 1 搭建腳手架的一個過程，目前這個版本算是實現一個簡易版的 VuePress ，但是如果一直使用開箱即用的 VuePress ，很多時候并沒有想去了解那些功能是怎么實現的，或者用哪些工具可以實現想要的功能（Btw: 我自從用了 Vue-CLI 之后就很久沒自己配置 Webpack 了，直到 Rollup 的時候才算重新玩轉了一次，這一次的 Vite 又是新的體驗）

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

重構前的目標

其實去年就有想法要對博客做一波改版，但有幾個原因導致一拖再拖，一個是因為業務比較忙（這個沒辦法，工作為重），一個是懶（主要是懶得去思考怎么設計，當然期間有在考慮一些不同的落地方案），還有一個主要的原因是當時 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

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

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

基于 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 方案來落地服務端渲染。

項目架構規劃

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

1. 對外展示的網站結構要保持不變，也就是原來的頁面地址要盡量一樣，避免用戶訪問不到原來的內容
2. 對實在不能保持原樣的 URL ，或者要廢棄的頁面，需要做 301 重定向
3. 降低后續更新的構建和部署成本，盡量自動化，減少人工操作
4. 數據需要無縫遷移，不能有丟失
5. 減少服務器壓力，把大部分資源消耗放在開源平臺上（諸如 Github、jsdelivr CDN 等等）

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

模板開發

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

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

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

src 
├─components 
│ ├─Footer.vue 
│ └─Header.vue 
└─views 
│ ├─[page].vue
├─article 
│ └─rewrite-in-vite.md 
│ ├─about.md 
└─index.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 是：

.container {
  display: flex;
  justify-content: center;
  align-items: center;
  width: 100px;
  height: 100px;
}

用 Tailwind CSS 的寫法是：

<div class="flex justify-center items-center w-40 h-40"></div>

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

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

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

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

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

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

.img {
  @apply w-full h-full object-cover;
}

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

.img {
  width: 100%;
  height: 100%;
  -o-object-fit: cover;
  object-fit: cover;
}

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

點一下切換皮膚：

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

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

a {
  color: var(--fg-deeper);
  text-decoration: none;
  &:hover {
    border-bottom: 1px solid var(--fg-light);
  }
}

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

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

SEO 優化

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

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

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

---
title: 這是頁面的標題
desc: 這是頁面的描述
keywords: 關鍵詞1,關鍵詞2,關鍵詞3
---
下面是要書寫的 Markdown 內容…

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

import { useHead } from '@vueuse/head'
useHead({
  meta: [
    {
      name: 'title',
      content: '這是頁面的標題'
    },
    {
      name: 'description',
      content: '這是頁面的描述'
    },
    {
      name: 'keywords',
      content: '關鍵詞1,關鍵詞2,關鍵詞3'
    }
  ]
})

你還可以擴展更多的信息上去，具體都在各自對應的 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 的路徑即可。

export default defineConfig({
  base: isDev
    ? '/'
    : 'https://cdn.jsdelivr.net/gh/chengpeiquan/chengpeiquan.com@gh-pages/'
})

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

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

PicGo 圖床界面

你可以在 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 ，搜素引擎很多方法，這里也不贅述了，放幾個自己用到的關鍵命令參考吧。

1. 清除緩存然后升級系統和軟件

sudo yum clean all sudo yum makecache sudo yum update sudo yum upgrade -y

2. 安裝 NPM 并通過 stable 安裝最新版本的 Node

sudo yum install npm sudo npm install -g n sudo n stable

3. 全局安裝 yarn[49] ，沒錯，我現在更喜歡用 yarn 來進行包管理，這一步你可以跳過

npm i -g yarn

4. 然后是全局安裝 pm2[50]，這個是必須要裝的，否則我們的終端一關，服務就停了，需要通過 PM2 來守護進程，當然，你也可以用 forever[51] 。

yarn global add pm2

其他的步驟就不用說了，創建服務器的文件夾，初始化，安裝 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 里添加。

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

1. on 是指分支行為，我配置了合并分支才會觸發，因為平時都是托管在 develop 分支，包括未開發完畢的功能，寫一半的文章草稿，只有確認可以發布的代碼，才會合并到 main 進行更新
2. jobs 是觸發自動打包 / 發布一系列行為的各種操作，從上到下按順序處理，其中的 ACCESS_TOKEN 是 GitHub 的 Token，請來 Personal access tokens[54] 創建，創建后只會顯示一次，請保存好，后面涉及到 Token 的地方可以重復使用同一個 Token，請勿泄露！
3. gh-pages 分支是打包完畢后的文件，推送到阿里云服務器的也是這個分支下的所有文件，之所以托管一份在 GitHub，是因為我們前面部署了 CDN 支持，JS / CSS 文件是需要讀取這個分支的 CDN 文件
4. 部署到阿里云的環節，配置的 SERVER_SSH_KEY 是自己服務器的密鑰對，如果你也是跟我一樣使用阿里云的 ECS ，可以參考 創建 SSH 密鑰對[55]， 創建后還需要綁定給實例才能激活生效，綁定操作請參考 綁定 SSH 密鑰對[56]
5. SERVER_IP 是自己服務器的公網 IP，這個其實可以不用配置為密鑰變量，因為 ping 一下你的域名也知道是什么 IP ，只是因為我有兩臺服務器，所以配置為變量可以方便的通過 SERVER_IP 和 SERVER_IP_TEST 去切換，其他變量其實也有一個 TEST 版本
6. 最后的 TARGET 是你在服務器上，node 服務器所安裝的目錄。

如果其中有什么環節不清楚的，善用搜索引擎，或者到我博客倉庫給我提 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 的配置可以參考我的項目，這里單獨說一下需要特別注意的點：

1. 因為使用了 CDN，所以 scope 和 manifest.start_url 選項需要顯式指定，否則資源會讀取出錯
2. 基于我上面提到的路徑問題，從 v0.5.3 開始，配置 CDN 的同時，也需要顯式指定 base 選項，避免出現 404

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

結語

因為網站的設計一向不是我的專長，加上不喜歡花里胡哨的東西，所以這一次重構后的 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 。

公眾號：小何成長，佛系更文，都是自己曾經踩過的坑或者是學到的東西

有興趣的小伙伴歡迎關注我哦，我是：何小玍。 大家一起進步鴨

們經常寫 HTML 、 CSS 和 JavaScript ，寫好這些之后，我們就會在瀏覽器中看到頁面，那瀏覽器究竟在這背后做了一些什么事情呢？本篇文章將揭曉答案！

了解瀏覽器的渲染原理是我們在通往更深層次的前端開發中不可缺少的，它可以讓我們從更深層次、角度去考慮性能優化等～

下面進入正文～

進程、線程

瀏覽器會分配一個線程“自上而下，從左到右”依次解析和渲染代碼，那么進程和線程是什么，它們之間有著怎樣的關系呢？

進程

一個進程就是一個程序運行的實例。當啟動一個程序的時候，操作系統會為該程序創建一塊內存，用來存放代碼，運行中的數據和一個執行任務的主線程，這樣的一個運行環境就叫進程

線程

線程不能單獨存在，它是由進程來啟動和管理的。線程依附于進程，進程中使用多線程并行處理能提升運算效率

兩者之間的關系

1、進程中的任意一線程執行出錯，都會導致整個進程的崩潰

2、線程之間可以共享數據

3、當一個進程關閉后，操作系統會回收進程所占用的內存

4、進程之間的內容相互隔離

渲染機制

從HTML、CSS和JavaScript開始

了解瀏覽器的渲染原理，我們就要從理解 HTML 、 CSS 和 JavaScrip 開始，我們先來看一張圖

HTML (超文本標記語言)，顧名思義，由標記（標簽）和文本組成，每個標簽都有自己的語意，瀏覽器會根據標簽和文本展示對應的內容。

CSS (層疊樣式表)，由選擇器和屬性組成，它可以改變 HTML 的樣式，比如上圖中，我們改變了 span 的顏色由藍色為綠色。

JavaScript ，我們可以通過 JS 完成很多事情，例如上圖中修改樣式。

下面開始分析渲染的原理

渲染流水線

渲染模塊由于渲染的機制的復雜，被劃分為了很多子階段，輸入的 HTML 經過這些子階段，最后會輸出為像素。這樣的處理流程就叫做 渲染流水線

按照渲染的時間順序，流水線可分為幾個子階段：構建 DOM 樹、樣式計算、布局階段、分層、繪制、分塊、光柵化和合成

構建DOM樹

由于瀏覽器無法直接理解和使用 HTML ,所以需要將 HTML 轉換為瀏覽器能夠理解的結構（ DOM 樹）

樹結構示意圖

DOM樹的構建過程

我們來分析一下下面這段代碼會構建出一棵什么樣的 DOM 樹

我們先將上面的代碼運行，然后在瀏覽器控制臺輸入 document ，看看會有什么效果

我們一層級一層級的打開就會看到如上圖的效果，我們可以根據這每一層級展開的效果，繪制出一棵 DOM 樹結構，如下：

接下來，我們試一下利用 JS 修改一下內容，看有什么改變：

我們可以看到“瀏覽器”的文字變成了“chrome”

再來看一下 DOM 樹是否有改變

我們看到在“瀏覽器”的位置換成了“chrome”，那么如何讓 DOM 節點擁有樣式？

樣式計算

樣式計算，顧名思義，就是 計算出 DOM 節點中每個元素的具體樣式 ，這個階段會分為三部分：

• 把 CSS 轉換為瀏覽器能夠理解的結構
• 轉換樣式表中的屬性值，使其標準化
• 計算出 DOM 樹中每個節點的樣式

CSS樣式來源

• link 導入外部樣式資源

瀏覽器會新開辟一個線程，去服務器獲取對應的資源文件（不阻礙主線程的渲染）

• style 內嵌樣式

從上到下解析，解析完繼續解析 DOM 結構。在真實項目中，如果 css 代碼不是很多，或是移動端項目，我們應該使用內嵌式，以此來減少 http 資源的請求，提高頁面渲染速度

• 行內樣式
• @import 導入

它是同步的，不會開辟新線程去加載資源文件，而是讓主線程去獲取，這阻礙 DOM 結構的繼續渲染；只有把外部樣式導入進來，并且解析后，才會繼續渲染 DOM 結構

把CSS轉換為瀏覽器能夠理解的結構

瀏覽器就像不能理解 HTML 一樣，不理解 CSS ，所以當渲染引擎接收到 CSS 文件時，會執行轉換操作，將 CSS 文本轉換為瀏覽器可以理解的 styleSheets 結構。

在 HTML 中，在瀏覽器中輸入 document 可以查看 html 的結構。在 css 中，可以輸入 document.styleSheets 看到 css 的結構

現在的結構是空的，我們來加一些樣式，看看效果

轉換樣式表中的屬性值，使其標準化

屬性值標準化就是將所有值轉換為渲染引擎容易理解的、標準化的計算值。我們大致看一下效果：

• 標準化前

body {
    font-size: 2em;
    color: black;
    font-weight: bold;
    ...
}
復制代碼

• 標準化后

body {
    font-size: 16px;
    color: rgb(0, 0, 0);
    font-weight: 700;
    ...
}
復制代碼

計算出DOM樹中每個節點的具體樣式

樣式計算有兩個CSS的規則：繼承規則和層疊規則

• CSS繼承規則

CSS 繼承就是每個 DOM 節點都包含有父節點的樣式。我們來看一下下面這段代碼中如何應用到 DOM 節點上

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Document</title>
    <style>
        h1 {
            color: red;
        }

        div {
            color: blue;
        }

        span {
            font-size: 16px;
        }
    </style>
</head>
<body>
    <h1>掘金</h1>
    <div>
        <span>瀏覽器</span>
        <span>渲染原理</span>
        構建DOM樹
    </div>
</body>
</html>
復制代碼

子節點會擁有父節點的樣式，由此我們可以畫出這樣一張圖

我們還可以打開控制臺，看一下選中 span 標簽，都會看到哪些內容

通過上圖，我們可看到一個元素的樣式、繼承過程等， userAgent 樣式是瀏覽器默認的內置樣式，如果我們不提供任何樣式，就會使用此樣式。

• 樣式層疊規則

層疊在 CSS 處于核心地位，它是 CSS 的一個基本特征，它定義了如何合并來自多個源的屬性值的算法。

樣式計算階段最終輸出的內容是每個 DOM 節點的樣式，并且保存在了 ComputedStyle 中。我們可以通過控制臺看到某個 DOM 元素最終的計算樣式

布局階段

現在我們不知道 DOM 元素的幾何位置信息，所以現在我們需要計算出 DOM 樹中可見元素的幾何位置，這個計算過程就叫做布局。布局階段有兩個過程：

• 創建布局樹
• 布局計算

創建布局樹

創建布局樹的意思就是創建一棵只包含可見元素的樹。我們來看下面一段代碼創建布局樹的過程

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Document</title>
    <style>
        h1 {
            color: red;
        }

        div {
            color: blue;
        }

        div span {
            font-size: 16px;
        }

        div span:last-child {
            display: none;
        }
    </style>
</head>
<body>
    <h1>掘金</h1>
    <div>
        <span>瀏覽器</span>
        <span>渲染原理</span>
        構建DOM樹
    </div>
</body>
</html>
復制代碼

構建布局樹的過程中， DOM 樹中所有不可見的節點都不會包含在這棵樹中。瀏覽器會遍歷 DOM 樹中所有能看見的節點，然后把這些節點加入到布局中；不可見的節點就會被忽略， head 標簽下面的內容、 div 下最后一個 span 節點都不會在布局樹中，我們看一下這個過程圖感受一下～

布局計算

布局計算就是計算布局樹節點的坐標位置。這個計算過程極為復雜。

分層

渲染引擎會為特定的節點生成專用的圖層，并生成一棵對應的圖層樹。這樣做是因為頁面中可能含有很多復雜的效果，我們可以打開控制臺看一下頁面的分層情況

我們可以看到，渲染引擎給頁面分了很多圖層，這些圖層會按照一定順序疊加在一起，形成最終的頁面

那么圖層的來源有哪些？

1、擁有層疊上下文屬性的元素會被提升為單獨的一層

層疊上下文可以使能夠使 HTML 元素具有三維的概念，這些 HTML 元素按照自身屬性的優先級分布在垂直于這個二維平面的 z 軸上。哪些元素具有層疊上下文屬性？

2、需要剪裁的地方會被創建為圖層

當我們創建一個有寬度和高度的 div 時，里面的文字內容可能會超出這個區域，這時候渲染引擎會把裁剪文字內容的一部分用于顯示在 div 區域，例如

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
    <style>
        div {
            width: 100px;
            height: 100px;
            background: yellow;
            overflow: auto;
        }
    </style>
</head>
<body>
    <div>
        我們經常寫`HTML`、`CSS`和`JavaScript`，寫好這些之后，我們就會在瀏覽器中看到頁面，那瀏覽器究竟在這背后做了一些什么事情呢？本篇文章將揭曉答案！

        了解瀏覽器的渲染原理是我們在通往更深層次的前端開發中不可缺少的，它可以讓我們從更深層次、角度去考慮性能優化等～
    </div>
</body>
</html>
復制代碼

運行結果

我們再打開控制臺的 layers 看一下效果

可以看到渲染引擎為文字部分單獨創建了一個圖層。

在布局樹中的節點如果擁有對應的圖層，這個節點就是一個圖層，如果沒有，這個節點就屬于父節點的圖層，如下圖：

圖層繪制

創建好圖層樹后，渲染引擎會繪制圖層樹中的每個圖層。渲染引擎會將圖層繪制分解為很多小的繪制指令，然后將這些指令按照順序組成待繪制列表，我們可以打開控制臺的 layers ，選擇 document 層，看一下效果

柵格化操作

柵格化就是將圖塊轉換位位圖，圖塊是柵格化執行的最小單位。渲染進程維護了一個柵格化的線程池，所有圖塊的柵格化都是在線程池內執行的。

圖層繪制列表準備好之后，主線程會把這個繪制列表提交給合成線程，繪制操作由渲染引擎中的合成線程來完成。

合成線程將圖層劃分為圖塊，然后合成線程會按照視口（可見區域）附近的圖塊優先生成位圖。

合成與顯示

所有的圖塊都被光柵化后，合成線程會生成一個繪制圖塊的命令（ DrawQuad ），然后將該命令提交給瀏覽器進程。瀏覽器進程里面 viz 組件用來接收 DrawQuad 命令，將其頁面內容繪制到內存中，最后將內存顯示到屏幕。這個時候，我們就看到了頁面

完善渲染流水線示意圖

根據上文中描述，我們可以畫出這樣一張圖

我還在網上找到了另外一張圖

這兩張圖都是描述瀏覽器的渲染流程的。

.icon1 {
 background: url(data:image/png;base64,<data>) no-repeat;
 }
.icon2 {
 background: url(data:image/png;base64,<data>) no-repeat;
 }