三月即將過去了，這意味著很多，比如，上市公司要開始準備第一季度的財報了；比如，2019年不知不覺已經過去1/4；比如，金三銀四的跳槽季，你拿到滿意的offer了嗎？...

整個三月份，我大概做了一些事；

• 給阿里云服務器有續費了一年（整整去年漲了200RMB），完成了node、nginx、mongo配置
• 給個人域名續費了一年（做個個人站點）
• 蘋果降價,購入了iMac（整體感覺寫文檔時比macbook爽）
• 基于個人的React組件庫，做了個通用管理后臺，并完善了React組件庫
• 用React SSR方案做了我的個人網站
• ......其他的一些事，比如股票竟然沒漲。kao

回到正題，寫這篇文章是想跟記錄和分享下搭建個人網站項目的過程。發了大概三個周末，外加15個的20:00 ~ 22:30 。

我想大概可以按下面幾點來開始

王佳欣的小站?www.shuxia123.com

個人網站的大概定位，為什么想做？

技術選型，為什么用React SSR？

服務端開發，接口怎么做才規范？

接口測試，怎么完整的測試后臺接口，為后續前端開發提高效率？

后臺系統開發，基于要我的組件庫嗎？

前端頁面開發，React服務端渲染聯調，接口聯調。

為了用戶體驗，做了哪些事情？

再講講其他的？

2019.03.31 13:41:30 先上線了....

一：個人網站定位，為什么想做呢？

網站以前端總結文章為主。寫一些技術總結；一些讀后感；嘗試翻譯英文文檔；轉載一些覺得不錯的文章(會先取得作者同意)。

展示目前正在做的一些開源項目，代碼還是托管在github上。

展示一些比較有趣的demo。

為什么想做呢？因為意識到時間很快，工作很忙，而離開學校后漸漸沒有了寫日記的習慣，每當年尾月末常常不得憶，需要有一個可以放"東西"的地方。

還有也是最重要的，就是最近我真的很閑....

第二：技術選型的問題，為什么用React SSR?

技術選型的話大概是這樣的。

確定站點以響應式的形式展示。

服務器：nginx，用了阿里云windows server 2008，為什么不用linux？其實本來想用，無奈很久以前有一些數據用的SqlServer數據庫。

服務端語言選型：Koa2.0 + Mongoddb

前端工程化，webpack4.0，實現：React + Redux + React-Router

發布：本地git push，服務器git pull 完成發布

采用SSR的原因是，考慮到要適配PC端和移動端，如果采用前后端分離的方案的話，會造成首次訪問首屏的問題，這個問題在移動端，我們可通過添加Loading、占位符等方案處理，但是在PC端下屏幕比較大，問題會成倍放大，因為考慮做SSR服務端渲染。SEO？這個個人網站倒無所謂。

為什么用React呢？因為我的React組件庫，自動16年用在公司幾個項目上后，就很少再去優化了，18年年底升級到React16版本，我想借此機會看下它有什么問題，也看它還有什么欠缺，完善一下。

還有呢？我喜歡React，喜歡它組件分離；喜歡它的高階組件式的裝飾增強組件，實現依賴反轉很好擴展；喜歡函數組件簡潔的寫法；喜歡它每個大版本都站在應用者的角度，給人很大的驚喜。

第三：服務端開發，接口怎么做才規范？

這次服務端的選型是，Koa2 + Mongodb。當然考慮過用關系型數據如MySql，畢竟更加熟悉，后面做了份表結構設計，發現其實挺簡單的，基本上，可以不用到關聯等操作。因此還是用Mongodb，我也想借此機會，看下以后擴展起來，文檔型數據庫，是否會難以下手。

如果說網站的前端頁面是作品的長相，那么服務端開發和接口應該就是“柜子的背后了”。喬布斯他爸教導喬布斯，做為一名木匠，柜子的背面也是作品的一部分。所以，在這上面也發了比較多的精力。接口規范；數據返回規范；狀態碼規范等等。把以往和服務端人員配合時，疑惑的問題都考慮了進去。

接口規范方面采用了restful的規范，嚴格采用get、post、put、delete。這個在后續前端api層開發可以非常簡潔；

// api接口允許的options有：[get、post、put、delete] // 地址：http://www.shuxia123.com/services/classifies// 前端api層非常簡單如下 import Base from './base'; class Classifies extends Base {constructor () {// 構造函數聲明實體super('classifies');}fetch (param) {return this.request({});}fetchOne (id) {return this.request({ id });}create (param) {return this.request({ data: param, method: 'post' });}edit (id, param) {return this.request({ id, data: param, method: 'put' });}remove (id) {return this.request({ id, method: 'delete' });} }export default new Classifies();

數據返回規范；如下

{"meta": {"code": 0,"msg": ""},"response": [{"id": 0,"name": "所有","path": "","total": 2}] } // meta放狀態信息，錯誤信息等 // response放數據信息

狀態碼規范，制定了一些統一的狀態碼，這樣前端開發的時候，可以根據狀態碼做信息提示。

.......

第四：接口測試

這次個人網站的搭建，我決定采取的方式是，先搭建服務端，開發好對應接口；然后，再開發前端頁面。然后進行最后的聯調。

考慮到，為了最大程度的提高后續前端接口調用調試的效率。因此，對接口進行了完成測試。

首先，分好模塊，比如，文章模塊、demo模塊、開源模塊、用戶模塊；

然后，選好測試工具，我用的是postman進行測試，在里面建好集合，按模塊進行各個模塊的測試。

我建立的測試集合大概是這樣的，覆蓋了所有主要的接口。

第五：后臺系統開發

基于：React + Redex，組件庫用自己的組件庫。

其實，能做這個開源代碼非常多，antd、ele、等等，甚至有很多git提供了完整的方案。

我呢，出于想完善下我的組件庫的原因，做了一個決定，用我的組件庫進行開發。壞處是，可能要發更多的時間寫代碼；好處是，我給組件庫做了一些完善，比如，表單驗證，比如，文檔編輯器，比如，照片編輯器等等。

后臺也是需要好好設計，我見過很多工作很久好幾年的開發者，寫出來的后臺異常難用，這個在我這里是不能存在的，所以，也發了比較大的精力進行開發。結果比較滿意，非常簡潔，好用。好吧，可能我比較挑哈。

可以展示下界面（考慮后期開源哈）

第六：前端頁面開發

這次的前端頁面都是自己做的（連logo都是用css寫的，畢竟ps技術不善于），風格也比較符合我。有借鑒了一些網站。比如詳情頁，是看了airbnb(大愛airbnb的體驗)的頁面。

然后就是具體開發了，這個也比較擅長，因為也比較簡單，所以就不深入了。

更多的時間是發在在服務端渲染后，和react首次掛載時，如何考慮性能，避免不必要的請求浪費。

第七：用戶體驗

做了比較多的考慮。

loading采用什么形式？

試過了很多loading效果后，決定采用骨架圖，好處是再數據沒有出來前可以用骨架圖占住和數據一致的圖案，這樣比采用普通的loading造成的視覺沖突小。

因為本地的接口請求太快了，造成了閃屏，骨架圖沒出現的情況。為了能體現出骨架圖的效果，在前端對接口層做了統一的處理，既接口請求小于600ms的，等待到了600ms后再resolve這樣效果比較同意。為什么是600ms？試了很多次，覺得它很合適。等真實到線上后，可能需要再調優一次。

圖片加載，怎么優化？

圖片怎么加載呢？一般的做法是懶加載可視區域的圖片。但這次我想做一些不一樣的，因為這次服務端是自己開發，圖片上傳存儲也是自己開發，所以可以完全按照我的想法進行。

比如：3241234_w_500_h_300.jpg，對應的存儲的預覽圖未：3241234_w_500_h_300_preview.jpg。

這樣在服務端渲染時，可以通過正則替換的形式，替換文檔內的圖片路徑優先加載預覽圖。

以往做懶加載，大概可以保證用戶的需求。這次我的做法是，在上傳圖片的時候同時保持兩張圖片，一張原尺寸，一張寬度20px的小圖片，同時存儲是命名采用“時間戳_w_[width]_h_[height].[ext]”，這樣我從圖片名稱就可以利用正則匹配出圖片的寬度高度，在加載時，采用先加載20px小圖（按原圖尺寸展示），這樣可以做到模糊加載的效果。最終效果也比較符合我的想法。

路由間切換要不要做過渡動畫？

原本有考慮，PC端因為屏幕比較大，實現后發現，動畫動畫很大，因此放棄，移動端做了漸入的效果。

怎么提高閱讀體驗？

文章原本用了統一的背景，后來發現很死板，因此直接用封面預覽圖(20px)做模糊背景，實現起來效果還是很不錯的。

因為，文章大部分會涉及到代碼展示，所以支持在服務端渲染的時候支持了下代碼高亮顯示。

預覽圖加載時，為了讓用戶看到預覽圖的時候，不會覺得沒有在加載，因此，做了0.1 ->0.5透明度的animation動畫。

滾動條滾動時，讓背景和導航欄都變得更模糊(根據滾動范圍做0.35->0.8的透明度遞增)，讓內容更突顯，突出主要內容。

第八：講講其他的

接下來打算做PWA，做離線狀態下的緩存，因此，會利用阿里云的https部署https服務。這是后話了。

另外，部署方面，目前主要通過git push的推代碼，服務器 git pull拉取代碼進行發布。接下來需要考慮如何優化這個流程。

服務器運維方面的知識也需要加強下，畢竟大概三四年沒用過windows系統了。

目前小實驗室和開源項目兩個模塊，只簡單的實現了鏈接的存儲，沒有實現項目的結算，后續時間充足的話會逐步完善這兩塊。

體驗完善，這個版本制作了很基本的體驗考慮，接下來會根據用戶的反饋，逐步做更好的用戶體驗優化。

說一些最近的感想，最近有在看機會，有沒通過的，也有通過后我婉拒的。

說下沒通過的吧，暴露了我一個很大的問題，因為本身是閩南人說以口音有點重；然后是，復述和表述能力不強，很多時候，沒辦法把我的想法很完整清晰的傳遞給對方，尤其是復述技術原理這種抽象畫的話題。這方面我的確要加強。

我婉拒的，無非兩點；第一，有的面試官會講很多他們自己的技術團隊、產品，很能講，讓你覺得好像很強，然后你回家打開他們的官網、產品，或者他們的git源碼，體驗非常rubbish，最后覺得如果你進入了，可能沒辦法適應他們的無規范，便罷了，在我看來產品體驗很重要，我們應該對用戶負責。第二，給的崗位不太合適的，我目前還比較有技術激情，所以，我比較偏向開發崗位比重較大的崗位，因為在廈門所以多小廠，小廠很多需要你去發很多精力去處理其他的事情。

總之，寫好代碼吧。

王佳欣的小站?www.shuxia123.com

總結

以上是生活随笔為你收集整理的request payload怎么发_做了一个个人博客，但不知道怎么介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。