公司之前所有的 Node 項目，其環境都是 8.9.4 版本，發布于 2018 年的一個比較古老的版本。   老版本有兩個比較明顯的問題： 1. Node 高版本的特性和方法都無法使用。 2. 有些第三方新版本的包無法安裝和升級，該包可能依賴比較高的 Node 版本。   之前在開發項目時就遇到第三方包自身的問題，必須升級或換個包才能解決，但因為 Node 版本的原因，無法替換，只能用其他方式來修補漏洞。   為了提升維護性和開發體驗，還是決定升級 Node 版本，2021年升級過一次，升級到 14 版本。   但是因為一些奇怪的問題加上業務繁重，沒有時間細究，就又回滾了，一直拖到今年的 7 月份，才繼續推進升級的事情，本次會升級到 16.15 版本。   目前總共有 4 個 Node 環境需要升級，測試資源緊張，在升級后，是沒有人力來驗證是否有問題發生，所以只能靠自己想辦法安全升級。 **1）分項目階梯升級**   在 4 個待升級的項目中，有 3 個是對外的項目，有 1 個是對內的項目。   那么先升級對內項目的 Node 版本，這樣有兩個好處： 1. 即使出問題了，影響范圍也能最小。 2. 響應也能最及時，因為有問題的話，在公司內部能馬上反饋到我們組。 **2）分環境階梯升級**   我們每個項目都會有 3 套運行環境：測試、預發和生產。   首先將測試環境升級，測試環境都是開發人員使用，影響最小，反饋最快。   觀察一段時間后，再升級預發，預發環境與生產環境最為接近，數據庫采用的也是一套。   最后才是生產，給真實用戶使用，再獲取反饋。 **3）邀請內部人員體驗**   首先升級的是那個內部項目，所以在飛書上建了個群，將各個組的負責人拉進來。   邀請他們在預發環境體驗各自的業務，再給出反饋。   在驗收時發現了時區的問題，糾正后，再讓他們驗收。 **4）部署自動錯誤告警**   讓人來驗收，難免會有遺漏，所以讓運維給加了個自動錯誤告警。   每分鐘有 5 個 500 以上的錯誤，就自動在飛書上發告警信息。   這類規則比較適合接口，而定時任務的規則比較特殊。   因為任務可能是 5 分鐘運行一次，那么報錯的頻率不會那么高。   因此改成 5 分鐘內有一個錯誤就告警，免得告警太多，也比較煩人。 **5）增加單元測試流程**   在將對內的項目升級完成后，公司員工在訪問一個服務時報錯。   讓運維查看后，發現是因為連接地址配置錯了。   為了避免這種問題的發生，就需要有地方可以測試服務連接是否異常。   手動測試比較繁瑣，最好的辦法是在發布代碼的流程中，加一環服務連接。   若成功，那么就繼續后面的流程，否則就中斷。   公司使用的是阿里云提供的發布系統，里面可以加一步單元測試。   服務連接是測試的一個場景，未來可以再加其他各類測試，保證項目質量。   從開始升級到全部項目升級完成，前前后后操作了 20 多天，因為在一個環境或項目升級后，就要觀察幾天，然后再升級另一個環境或項目。在升級完成后，還部署了阿里云提供的一款 Node 監控系統。 ***** > 原文出處： [博客園-Node.js躬行記](https://www.cnblogs.com/strick/category/1688575.html) [知乎專欄-Node.js躬行記](https://zhuanlan.zhihu.com/pwnode) 已建立一個微信前端交流群，如要進群，請先加微信號freedom20180706或掃描下面的二維碼，請求中需注明“看云加群”，在通過請求后就會把你拉進來。還搜集整理了一套[面試資料](https://github.com/pwstrick/daily)，歡迎閱讀。  推薦一款前端監控腳本：[shin-monitor](https://github.com/pwstrick/shin-monitor)，不僅能監控前端的錯誤、通信、打印等行為，還能計算各類性能參數，包括 FMP、LCP、FP 等。