## 背景
Node.js 很簡單，容易上手。但也因此缺乏不少規範，使用者水平參差不齊。
最近經常看到的一個問題是：很多新手，在部署的時候，是直接在服務器上 npm install ，這是非常不推薦的。
## 存在的問題
1. 無法確定唯一性
因爲安裝是有較大的網絡耗時的，所以你甚至無法保證集羣情況下，兩臺服務器上npm install 下來的包是一模一樣的。
如果某個庫剛好更新了，並且它有 BUG，然後你就是百思不得其解：一定概率出某個問題。排查起來簡直想死。
當然，很多人爲了解決這個問題，就選擇「鎖版本」這個方案。
評論區的同學，不要急，看完下面第 2 點，即使鎖版本也是在 CI 上 install 而不是服務器上。
鑑於 「鎖版本」屬於 「屎色自行車問題」 ，這裏不想討論。
我們的觀點參見： 「知乎專欄 - 死馬：爲什麼我不使用 shrinkwrap（lock）」。
2. 上線耗時久，無法快速回滾
上線後，發現線上故障，要快速回滾止血的時候，就懵逼了：
- 要等待依賴安裝，萬一網絡有個抖動啥的，妥妥的 P4 故障變爲 P0 故障，年終獎沒了。
- 萬一問題是底層依賴導致的，回滾也沒用。
npm cache解決不了問題，如機器擴容的時候。
## 推薦方案
知乎圖片查看體驗差，請點擊大圖，清晰點
其中，關鍵點是：在構建期就把依賴打包進去。
優點：
- 解壓即可立刻啓動，無需等待網絡耗時。
- 能保證肯定是可以運行的，因爲此時依賴都是確定好的，且經過 CI 單測保障的。
- 可以快速回滾，止血。
- 打包方式可以是 tar 或 docker。（推薦後者）
缺點：
- 包體積大（但其實存儲不值錢。。。）
知乎圖片查看體驗差，請點擊大圖，清晰點
上圖是用 PlantUML 在語雀繪製的，想享受類 Markdown 的體驗來畫流程圖，就用 PlantUML
## 如何實施？
那有同學就要問了：我是小公司，不像你們有這些基建可以服務，怎麼辦？
其實成本真的很低：
- 代碼倉庫 GitLab 自帶 CI 了，你只需要寫個配置文件，觸發自動構建即可。（或 Jenkins）
- 然後把構建後的文件，找個地方存儲，如 OSS 。
- 服務器部署的話，有運維發佈系統最好，沒有的話，自己寫個 shell 把 OSS 文件下載解壓。
- 當然，很多雲服務都支持 Docker 鏡像了，那就更簡單了。