大家好，我是 Scott，2016 年 9 月 25 日在杭州大搜車總部舉行的杭州 Node Party 上分享了一個話題 - 《創業公司擼 Node》 ，分享之后我以文字的形式又記錄了一遍，分享給沒有與會的朋友，也方便大家通過搜索引擎者一些技術社區平臺來看到這篇文章。

寫在前面，感謝芋頭哥和大搜車，給了我這個機會跟大家在大搜車面基，說實話，從我出道以來，這還真的是我第一次正式在公開場合裝逼，尤其是當著這么多大牛大咖的面兒裝逼。

今天跟大家分享的話題是，現階段下創業團隊中對于 Nodejs 工程師的認可程度，以及如果有一天你進入了創業團隊，在做技術選型的時候，基于什么標準來判斷，要不要使用 Nodejs 開發，以及如何跟進技術的演變。

我特意加了前端逆襲這個小標題，是為了在咱們現場做個小調查，請從前和現在做過前端開發的的同學舉一下手好么，看看多少人搞了前端現在也在搞 Node?，F場舉手的超過一半人數，前端這個職業真的是屌爆了。

ok，首先做一個自我介紹，我跟大家一樣，從前也是一名前端工程師，從 2010 開始，在阿里媽媽做了四年前端，后期做了不少廣告投放相關的前端頁面，跟后端的創意投放管理系統對接，制作和優化廣告效果模板等等，大家如果去上 Youku, 微博，各種電影小說新聞媒體網站，應該會有印象曾看過這樣滿屏滾來滾去的淘寶豆腐塊廣告。

哈哈，很不好意思，2014 年以前，你在全網看到的差不多有 70% 的豆腐塊廣告都是我做的，你在淘寶搜了鮮花啊，內褲啊，硬盤啊，種子啊，再去訪問其他網站，都能看到豆腐塊里的類似商品，當時我的工作就是開發這些模板的樣式，優化這些模板的特效，測試在各種終端設備上的兼容性，數據方面需要跟各種算法引擎團隊約定各種異步數據格式，業務上需要考慮復雜的參數加密解密二跳透傳，Cookie 的讀取定向等等來落地不同推廣場景下的異步交互方案，最終基于各種廣告系統接入和投放到目標網站。

所以在最初我仍然是一個很純的前端工程師，后來怎么就開始折騰 Nodejs 了呢，我們可以看下上圖最右上角的這個輪播圖，它由上下兩部分組成，上面是輪播的商品列表圖，下面是推廣的商品關鍵詞，它倆是兩個獨立的數據接口，而且很可能是隸屬于兩個完全不同的數據引擎團隊，從前端開發的角度呢，我需要發兩次請求來分別獲取和控制這兩個數據接口的展現，而從后臺開發的角度看，兩個接口最好相對獨立，互不影響，因此我們前端工程師，盡管很希望將兩個接口合并成為一個接口，卻很難推動后端工程師團隊為我們這樣某一個模板，專門開發一個接口出來，由這個接口統一獲取兩個接口數據合并后再交給前端展現，于是我們就很難從至少是請求個數這個層面，來優化這個廣告的展現速度和展現完整度，有時候是圖片先出來，有時候是關鍵詞先出來，如果等待同時出來，萬一某一個接口掛了怎么辦，這時候再等待超時以后去獲取打底的接口或者類似接口，用戶早就離開了。

但是這樣一個模板在全網的每天為阿里帶來的收益，是非常巨量的，而它的生命周期也許只有 2 周，2 個月就撤下去換別的模板了，所以從維護的角度上，后端工程師的確也很難及時跟進前端和產品層面頻繁的改動，而從收益方面，就需要跟后端工程師努力的溝通解釋，非常費勁，協作成本居高不下。

但是現在有了 Nodejs 后，我們設想一下，如果把 Node 作為接口這一層，由它來決定調用哪幾個接口，合并哪幾個接口，哪些接口使用哪些打底數據，是不是這樣的場景就迎刃而解了呢，關于這個我就不再探討了，可能會涉及到公司保密協議，因為我后來從阿里離職出來創業了。

創業以后，開始了我的職業轉型，這近 3 年時間，我一直在創業公司用 Nodejs 開發產品，我也就從一個標準的前端開發工程師逐步切換為一個會使用 Nodejs 的開發工程師，中間費了不少力氣，想了解我的技術成長路線的，可以看上一篇文章 - 4 年前端狗，2 年 CTO，進入一個新的 領域，作為新人是要踩很多坑的，有的是有必要踩，有的沒必要踩，我就把自己的一些心得整理做成視頻，放到了慕課網上。

地址見這里：http://www.imooc.com/u/108492/courses?sort=publish

如果是剛入行的新人可以去看看，里面知識點也許有點陳舊，講解也未必很嚴謹，可以選擇性的理解流程和項目思路。

那么現在，我是 CampusRoom 這個網站的技術負責人，大家可能都沒聽過 CampusRoom, 沒關系，估計部分同學聽說過 Moveha，創業這幾年中，無論是 CampusRoom，Moveha，還是微信服務號，包括其他的一些內部的外部的，做了沒上線，上線了又下線的大小項目，統統都是用 Nodejs 來搭建的，整個創業團隊也充分體驗到了使用 Nodejs 建站或者啟動一個項目時候敏捷所帶來的高效率，其中有一個小案例，近幾年，一些歐美國家不是太安全，我們為了讓學生和家長能對當地的居住環境有一個安全方面的了解，就用 Nodejs 很快速的搭建了一個爬蟲小系統，爬取一些州和城市的警署犯罪數據，然后合理的分類和評級打分后，給出一個數據可視化的效果，這個功能的產品價值可能是很大的，然而實現成本是非常非常小的，效果見下圖：

以上都是從我自身，從我們公司來來感受 Nodejs 的開發效率和對公司的價值，但是整個業界對于 Nodejs 的態度又是怎樣的呢，他們的接受度又是如何呢，我們再舉個例子，大家可能看到過 CNode 論壇上的這個招聘貼，我截圖了有贊的和大搜車的，最后一個就是我發的，也就是 Moveha 公司的招聘，哦，說一句，Moveha 是 CampusRoom 的前身，CampusRoom 是從 Moveha 孵化出來的，我要說的重點是，我發的這個 Node 工程師招聘貼，是論壇里最先被加精的招聘帖子，也是閱讀量最高的帖子，現在有 4 萬多個閱讀量，400 多個評論，這個帖子給我帶來了 100 多份簡歷，現在我們公司的所有工程師都是從這個帖子招過來的。

在這個帖子前后 - 2014 年秋季，在論壇或者社區中，很多公司對于 Nodejs 工程師的認知包括他們的價值定位其實是不夠清晰的，從招人的風氣中就能看出來，在我發這個帖子以前的時候，很多公司跑到 CNode 上發帖，都是姿態比較高，一副你愛來不來的樣子，對自己公司團隊文化介紹的三言兩語模棱兩可，薪資區間從來不敢放，自從我發這個帖子之后，逐漸的論壇的招聘貼開始接地氣了開始有誠意了，薪資夠不到 20K 的公司甚至都不好意思上來發帖了，從這件事情上就能反映出工程師社區的結果導向，玩虛的根本不行，結果好市場認同自然容易被人接受，CNode 上面大量的招聘也從側面證明了，這三四年以來，Nodejs 工程師越來越被認可，越來越被重視，一個職位到底含金量高不高，其實不是你說了算，也不是我說了算，而是這個市場說了算。

我們再來看下 indeed 上面統計的職位需求變化的趨勢，第一個圖是 Nodejs 的需求量變化，第二個是 Fullstack 的需求量變化：

這兩個職位，即便是在今天，現在依然處在井噴暴漲的階段，整個市場已經對 Nodejs 工程師有了足夠的認可，所以大家的職業黃金期真的是已經到了，再過兩三年，Nodejs 工程師就會真的遍布大街小巷各種公司，現在是跟上這個大潮的最佳時期。

那為什么這么多公司對 Nodejs 工程師這么認可呢，特別是中小型團隊，特別是創業團隊，為什么明明可以選擇 PHP，可以選擇同樣敏捷的 Ruby，可以選擇更加成熟，程序員相對更容易招聘的 Java，Python，卻非要費勁巴力的去招聘緊缺的 Nodejs 工程師呢，尤其是具備前端工程師能力的 Nodejs 工程師呢？

答案非常簡單，就是因為利用 Nodejs 開發一個新項目，會非常的高效敏捷，無論從最終的用戶體驗，還是上線后的產品迭代節奏，使用 Nodejs 都有巨大的成本優勢。

而成本對于創業公司來講，是非常敏感的事情，現在市面上成千上萬家嗷嗷待哺的創業公司，其實跟屌絲無異，不是沒錢，就是沒人，沒錢，沒人也就罷了，很多 CEO 還想要有好的用戶體驗，還想要有更短的研發周期，更快的迭代節奏。

說白了，也只有通過這種快速迭代和小步快跑，才能跟同類產品的大公司競爭中拿到時間差優勢，最快的拿到用戶反饋和市場反應，最終才能在競爭中和夾縫中殺出一條血路，現實的確是如此殘酷?？焖俚耐瞥霎a品，熬過最艱難的階段，找準了產品的盈利點，抓住了目標用戶群，有了可以拿到桌面上的各種數據，自然更有優勢融資，那時候再去改進優化技術棧甚至更換開發語言也完全有足夠的緩沖余地。

所以我們 Nodejs 工程師的核心價值，尤其對于創業公司，就是能夠快速產出，迭代的速度更快，前端后端可以通吃，為創業公司節省巨大的人力成本，這就是為什么在市場上，Nodejs 這么受歡迎的原因，創業公司選擇我們，不僅因為它能最快速的滿足初創團隊的場景，也是因為 Javascript 也是唯一的能跨越前后端，用一種語言搞定產品實現的選擇了，關于 Nodejs 的適用場景，它的優勢劣勢，它的開發和維護成本，相信大家做了這么久都有自己的見解，不再過多贅述，我們且往下看。

究竟什么樣的創業項目，比較適合 Nodejs 呢，或者說， Nodejs 作為創業團隊立項時候所考慮的技術選型，有它適用的邊界么，如果有，邊界在哪里，有哪些衡量的標準。如果在創業公司，我們需要確定用 Nodejs 開啟一個項目，那么以怎樣的標準，或者說怎樣的準則來衡量， Nodejs 怎么用，框架怎么選，版本如何跟進呢？

太多的問號在腦海中回蕩，我個人認為，可以簡化為如下三個問題，就能解決從決策到執行的流程：

首先第一個，什么樣的創業項目，適合用 Nodejs，哪些又不適合用，我們從這三個因素來衡量：

1. 期望的迭代節奏

任何一個產品，立項之初，都有它特殊的商業背景和商業目標，在這個背景和目標下，會給予對它的一些期望，希望它以怎樣形式，多長時間開發上線，上線后，以多長的周期進行版本的更新迭代，這些都很好理解，如果是一個展示型的，扔上去不需要怎樣去增加功能，也不需要多么頻繁的改版升級，那么就沒必要一定要使用 Nodejs，用 PHP，Ruby 統統沒問題。

2. 團隊工程師能力

我們知道，就像這世界的大部分事物一樣，工程師的能力也是大概符合正態分布，除去特別弱的，比如 3 年前的我，除去特別強的，大部分工程師其實都處在中間的這個地帶，就像現在的我，對于 Nodejs 及周邊生態的掌握可能比較好，但不是特別特別好，而 Nodejs 又是一個新的職業方向，火熱的市場上根本沒有足夠時間來沉淀，于是大部分的創業團隊是并沒有足夠資深的 Nodejs 工程師，這意味著我們在快速開發的時候，往往也面臨著更高的業務風險，一旦 Nodejs 用的姿勢不對或者技術選型失誤，會給業務帶來災難性的打擊。

這一點其實被很多公司所忽視，整個團隊在當下與未來半年的一個規模，團隊成員的技術背景，自我學習的能力，對于新技術升級的接受程度，如果是不能很好的駕馭 Nodejs 而且自學能力又偏弱的話，就需要慎重考慮一下。

3. 跟產品的匹配程度

其實創業類的產品，往往很少有上來就規?；?，高難度的，所以許多類型都適合，我們與其想那些可以用 Nodejs 開發，不如反過來看，那些類型的不太適合用 Nodejs 開發，排除掉這些場景，剩下的都可以評估一下用 Nodejs 是不是可以。

我這里羅列了幾種，其實大家照著這個方向走，未必只有這 4 點：

極高并發數

密集 CPU 運算

高安全高可靠性

內存精密控制及釋放

并發數本來是 Nodejs 的強項，高吞吐量，但是如果上來就是要應對爆發式井噴的場景，需要堆機器的時候，顯然這些非 Nodejs 領域內軟實力會過度消耗工程師的時間成本，這一點一旦工程師的學習能力跟不上來，就會反過來制約業務的發展，如果非要給一個數字的話，可以以 10 萬作為一個衡量點，并發大于 10 萬的，都要慎重評估一下。

而對于大循環的數據結構，需要長時間的運算的，對 CPU 強依賴，導致時間片釋放遲緩的場景就盡量不要用 Nodejs 來做，可以交給 Scala，可以交給 Go，甚至可以交給 Java 和 C++ 來做。

舉一個例子，比如有旅游路線的實時計算，對用戶的出行路線進行推薦，需要基于多維度不同權重的因子進行算法推演，考慮進去用戶的性別，喜好，預算，期望的出行方式，天氣，當地景點的分布，目的地有沒有類似 G20 的大會等等各種因素，背后則可能依靠一些大數據做支撐，這時候用戶不可能等待太久，而是希望馬上拿到路線報告，這些場景下我們處于中段能力值附近的工程師就不要逞強，避免使用 Nodejs。

安全可靠也同理，一些支付或者銀行對接從場景，服務的穩定性非常之高，不能有任何可能異常導致的進程掛起，引起數據不一致，這種如果其他語言已經具備很好的線上解決方案的話，那么 Nodejs 就可以只做它擅長的方面，把這些交給其他更專業的技術來實現，Nodejs 只調用接口就行。

一個項目做大了之后，代碼中會有更多的隱患或者風險，一個疏忽就可能導致內存泄露，而如果業務層面是對內存非常敏感的，由于內存使用不精細導致對外的服務質量不平穩，這些都是業務不能接受的，那么這樣的場景也要慎重權衡一下。

其實，考慮到創業團隊特定的起步方式，不平衡的工程師能力，產品迭代的節奏，只要是一些略苛刻的場景，都應該要多思考一下，用 Nodejs 除了效率，能帶來的價值能否高過帶來的挑戰和風險，如果答案是否定的，我們就要慎重使用 Nodejs。

我們始終需要去找到一個在工程師能力，Nodejs 滿足和匹配業務的程度，以及公司的產品節奏之間找到這個平衡點，而且這個平衡點會隨著業務的膨脹，團隊的成長而不斷的變化，在變化之中我們需要不斷的評估，去反思。

那么我們回到產品本身，一旦我們排除掉這些場景以后，我們就可以大膽使用 Nodejs 了，或者說，不是我們，而是更多已經大力度投入到 Nodejs 陣營中的先驅者和執行者們，比如下圖：

太多全球的大公司，已經在使用 Nodejs 了，就連 微軟這樣印象中比較封閉刻板的軟件帝國，都已經對 Nodejs 有著很大的投入，對開源有很大的包容度，推出了很多 Nodejs 好用的工具和服務，甚至要 Fork 一個 Nodejs 推出新的引擎。

甚至更另類一點的，發射太空任務的 NASA 都要用 Nodejs 來開發一些應用或者是運行一些系統，甚至是 2016 年 Github 上評選的，最受歡迎的項目中，有將近一半都是 Nodejs 相關的項目，或者有用到 Nodejs 做一些構建工作。

總結起來就是一句話，Nodejs 上天入地，剛前剛后，流行只是我們看到的現象，背后是它較低的使用門檻，較小的協作成本，以及更好的開發體驗，和不錯的性能表現。

雖然有這么多我們樂于看到的方面，作為一個工程師，我們依然需要謹慎對待，當我們確定使用 Nodejs 以后，如何選擇版本或者語法層面的一些編程習慣，畢竟 JS 編程始終太靈活，有許多問題大家糾結好多年，而 JS 的快速進化也帶來更多的編程方向，站在這個十字路口，往前一步未必是大海，往后一步也未必是懸崖，但是前進總比后退要更能接近未來。

舉一個簡單的例子，讓很多工程師頭痛了很多年的例子，就是 Callback， 這是個老生常談的問題了，不同的團隊不同的項目歷史背景不同的技術風格，顯然對于 Callback 的態度和選擇是不同的，比如芋頭哥在大搜車，對于 Callback 的態度是相對寬容的，因為幾十萬行的歷史代碼，說實話交給我維護，我也不敢亂來。

那么我個人的看法呢，Callback 顯然是不爽的，是反人類的，我的觀點是，初創團隊，如果沒有歷史包袱或者歷史包袱不大的話，堅決丟掉，可以直接上 Promise，因為包袱只要背在身上，只會越來越重，越來越不敢扔掉。

如果再激進一些，可以將 Promise 和 Generator Function 混用；
如果再激進一些，就結合 Babel 來使用 async/await;

我們來看一個例子，通過這個搜索框，輸入學?；蛘叱鞘?，可以搜學校周邊或者城市周邊的房子。

搜索實現的路徑，我這里做了最大的簡化，只有兩種，在以后繼續升級的產品形態中，會更加復雜，比如有精確查詢和模糊查詢，有除了城市和學校以外的經緯度直接查詢，有標題查詢，也有郵編號碼查詢等等，他們的搜索顯然都是異步的。

那么這個簡化的例子，第一條路，輸入學校，搜索學校，拿到學校以后搜索周邊房源。第二條路，搜索城市，搜索到城市以后，搜城市里面的大學，再搜城市里面的房源。

由于我們不知道用戶輸入的是學校的類型，還是城市的類型，我們需要兩個都查，以學校的結果為主。

如果用 Callback 的方式開發，很容易就寫出這樣的代碼，通過嵌套就強行鎖定了搜索的優先級，以及并發和非并發的次序，當然每一個異步查詢都要處理一個后置的錯誤對象判斷，這些錯誤不能進行合并，要分別處理 5 次，有的會中斷流程，有的也許不會，加上如果使用 eslint，這里的 err 都需要多帶帶命名，不可以重名，單從維護的角度看，如果以后要調整這里的搜索優先級，就會很頭痛，相信這些事情大家都有遇到過，我們再來看第二段代碼，這一段我們使用了 Promise 和 Generator Function 結合以后的一個升級版本。

很顯然，這個升級直接就解決了 Callback 的幾個痛點，首先是邏輯可以分拆開來，升級維護更方便，如果先以城市為第一優先級搜索，直接把底下代碼整塊扔上來就行了，另外，錯誤的捕獲可以合并起來，當然也可以做更精細的控制，同時呢，比如搜索城市大學和城市房源它倆是可以并行的，我們就用 Promise 和 Generator 就能很自然的做到這件事，當然用 callback 也可以集合 eventproxy 或者 async 做流程控制，但是也會進一步引入代碼的復雜度。

其實只要解決掉 Callback 的問題，我們就已經往前邁了很大很大一步了，因為我們引入了 Promise ，引入了 Generator Function，甚至可以突進到 await 和 async，這意味著底層的 Nodejs 的版本也會有更大的升級，帶來更多編程思路的變化。

那么說到 Nodejs 的版本，我的觀點是，我們需要保持對 Nodejs 大版本的跟進，因為站在 2016 年的這個節點上，其實 Nodejs 已經經過了 7 年之癢，后面的日子比前面的幾年要幸福太多了，這個我可以從自身的一些經驗來說下吧：

我從 2013 年開始兼職創業做我們公司的項目，那時候的 Nodejs 版本是 0.8，我一直使用到 2014 年 7 月份，才從 0.8 升級到了 0.10，然后又使用到了 2015 年春節，沒有忍住，從 0.10 升級到了 0.12，一直使用到 2016 年 1 月份，再次升級到了 4.x，現在仍然保持在 4.x 的版本狀態，我經歷了這幾次大的版本周期，感覺是這樣的。

從 0.10 到 0.12 是一個比較大的飛升，從 0.12 到 4.x 是一個巨大的飛升
從 4.x 到 6.x 也將是一個巨大的飛升，當然了， Nodejs 有它特殊的歷史進程，比如 0.10 的版本中，有一個重大的安全漏洞，不升級都不行，在 4.x 推出以前，Nodejs 社區還分出來 io.js 陣營，結結實實的對抗了很長時間，再往后面合并后就正?；耍灰俜酵屏?LTS 版本，在首個 LTS 版本之后，可以觀望一個月左右，就可以考慮升級了。

當然，在 LTS 版本升級之前的至少 1 個月，我們本地的開發環境，就應該已經切換到了這個大版本了，在我們本地來開發來測試。

接下來，我們都會面臨 6.x 版本甚至是即將發布的 7.x 版本，官方也羅列了一些重大的變化，我談下我覺得需要關注的點。

1. V8 升級到 5.0.x

每一次版本的升級，都不可例外的，會優化提升整體的性能，包括安全方面的增強，文檔的完善，測試用例的覆蓋，但是都沒有重大的引擎升級來的給力，作為一個 Javascript 運行環境，Nodejs 是依賴于 Chrome V8 引擎進行代碼解釋，所以 Chrome V8 的能力基本上限定了 Nodejs 的能力，那么這次，相比較于 4.x，6.x 的底層引擎 v8 升級到 5.0.x，這意味著，由于底層 v8 自身的很多缺陷和 Bug 都已經通過大升級而一下子就修復了，所以整個 6.x 的表現會跟 4.x 有很大不同。

2. 覆蓋 93% 的 ES6 特性

6.x 覆蓋 93% ES6 特性，則代表我們可以大膽的使用 es6 的幾乎全部特性了，比如 解構，剩余參數，類啊，super 關鍵字啊，我們知道，往往我們在使用一個庫或者框架的時候，甚至是語言，常常用到的總是那 5 成，6 成，頂天了 7 成的 API，就能完全滿足我們的業務需要，那么 ES6 的覆蓋率如此之高，我們的確可以敞開胸懷，去擁抱 ES6.

3. 模塊加載比 4.x 快 4 倍

模塊加載比 4.x 快 4 倍
，如果你是一個項目負責人，或者技術組長，那么這個對于你來講肯定是有意義的，我們線上應用啟動，或者重啟的時間會變得更短，讓我們的線上服務對用戶來說，切換更加的平滑，由重啟引起的波動也感知更小。

然而我們除了從語法層面去避免歷史疑難雜癥以外，我們更需要關注 Nodejs 版本本身帶來的巨大差異和變化，來看一下 Nodejs 這張表，從現在到 2018 年，我們自身的技能是不斷增長的，同時我們對于 ES6 的使用和了解會越來越深入，那么我們就應該選擇一個未來的版本來切入技能棧，說句老實話，接下來兩年我們會持續的在 6.x 的版本上跑我們的項目，那么接下來幾個月就是升級線上版本的緩沖期。

當我們把上面的問題都考慮清楚，剩下的事情就變得簡單很多，到了 2016 年，我們并不像是在 2014 年之前那樣，處在大躍進的年代，太多的變化導致太多的不穩定性，現在社區的生態環境已經相當完善。

從靜態資源、Web 框架，模板輸出，數據庫中間件到第三方通信，消息推送各種 SDK 和 CDN 內容分發，都有太多優秀的庫可以使用，我們做一些適當的定制和改造便可以拎到項目中大膽使用。

然而當我們把魔爪伸向后端，使用 Nodejs 搭建企業級應用的時候，我們抓過來的不僅是更多的價值體現，我們也抓過來更多的職責和信任，后端底層乃至團隊規范都需要我們花費更多的時間去了解對接的方式，接入的階段，不需要精通，但需要備份為基礎的常識，這些軟實力，是我們成為一個優秀 Nodejs 工程師的必備要素。

最后，我來對創業公司中使用 Nodejs，做一個小總結，我們在妥善處理了 運維、集群管理、性能調優等等這些傳統語言已經做的非常棒非常成熟的領域，在大部分的創業公司，都可以由前端團隊推動，來使用 Nodejs 去接管數據訪問層與渲染層的事情，等到公司規模上來以后，就可以依靠更資深的工程師以及原來團隊的沉淀，來做 比如日志、監控系統、分布式服務接入這些事情，Nodejs 的落地需要前端工程師，需要 Nodejs 工程師，更需要強大的運維之錘，了解除了 JS 以外的更多技能，比如數據庫，比如系統的設計，比如接口服務，比如團隊規范協作流程等等等等，在大公司可以扎根一個方向挖下去，在小公司則需要放眼天下，籌備未來。

無論是怎樣的技術背景，如果有一天你進入創業公司，在立項之初，你都可以先大膽的來做一個假設或者推演，假設說把賭注押到 Nodejs 上，會不會拿到一個更快更好的結果，如果是，請毫不猶豫的選擇 Nodejs。