背景
以 Jenkins 服務器為例，在構建內部的這個項目時，CE 每部署一次服務，最快 6 分鐘，最
慢將近 13 分鐘左右。遇到多個項目并發打包會因為資源占用等問題時間會延長，甚至出現過
幾次 20 分鐘以上的情況。

所以經常收到一些友情提示：比如像這樣的截圖，往往對方只發一張圖，卻什么都不說：

原因
在了解原因之前，我們先回顧一下歷史，也就是當年為什么要用 Yarn。從這段歷史中，我們
可以分析出來慢的原因。

Yarn 工具沒有推出之前，通常是使用 NPM 進行依賴管理的，早期的 NPM 它有一個致命的
缺陷；需要等一個包，完全安裝好后，在對下一個包做處理；它沒有并發能力，所以才不會
涉及到高 IO 的問題，犧牲的是等待時間。

NPM 遇到相同版本的依賴庫時，會重新下載一遍這個包；因為它原生不具備緩存能力，所以
只能重新下載。這也不會涉及 IO 問題，因為它犧牲了下載時間和 node_modules 文件夾的體
積（這里是提前引用概念，下面第四條中有介紹）。

所以當時，我們引用了 Yarn 工具來提升安裝依賴的速度。

(1) 它最特殊的是，具備鎖（lock）文件，你從哪下載文件，你團隊的人就從哪下載文件，避
免包版本不一致的問題。能解決我線下好使啊，怎么到你那就不行，諸如此類的問題。

(2) 會緩存它下載的每個包，所以無需重復下載。

(3) 具備離線模式，之前安裝過的包會被寫入緩存目錄，以后安裝就直接從緩存中復制過來，
這樣做的本質是減少重復下載，減少不必要的網絡請求。

(4) 為了減少 node_modules 體積，會對依賴次數做選舉，把引用頻率高的類庫放到頂級目錄。

我們已經了解，它是依賴文件緩存的方式，提升了效率問題；僅僅是做選舉，就已經引發了
高頻 IO 的操作，因為它要分析引用次數來回的移動目錄。Webpack 打包構建情況也是類似，
具體就不在展開細說。

現象
所以我們有了一個印象，前端工程下載后，會做很多 IO 操作。這對 SSD 磁盤很有效。如果
是機械硬盤，遇到高頻讀寫，性能就會很慢。這是 Yarn 在做依賴庫選舉而優化磁盤占用時，
機械硬盤所消耗的時間耗時 13 分鐘：

這種情況我們很難避免，只有幾種選擇：
1. 后退，使用 NPM 工具，選擇等待犧牲網絡下載時間，這條路走不通。
2. Jenkins 更換 SSD 磁盤，更換硬件實際上是最好的方案，短期內也走不通。
3. 優化 Yarn 依賴庫的選舉方案，Yarn PnP 還不太成熟，我們還在調研中，有坑，也走不通。

解決方案
當時的情況是，正常的方案都無法走通了。直到有一天我的同事提供一個思路，說他當年在 Windows
下片時，為了加快 Copy 速度把內存當磁盤用了，Windows 設置這個東西很簡單。你們看看
Linux 支不支持。隨后我們就開始調研，本機測試后發現可行。

然后我們以線下的的環境做試點，部署腳本改好了測試近一周，發現可行。

優化前，最高 23 分鐘（開篇第一張圖），現在平均 3 分鐘：

另一個項目優化前，平均 8 分鐘：

優化后，平均 49 秒：

本次主要是給大家，提供一個解決 IO 問題的思路。我們使用的是 RAM disk 中的 temfs
方案。技術對比看下方鏈接的文章就行，很簡單：

參考鏈接
https://baike.baidu.com/item/tmpfs/1476960?fr=aladdin
https://blog.csdn.net/wz947324/article/details/80007122