摘要：感謝大神的免費的計算機編程類中文書籍收錄并推薦地址，以后在倉庫里更新地址，聲音版全文狼叔如何正確的學習簡介現在，越來越多的科技公司和開發者開始使用開發各種應用。

2017-12-14 我發了一篇文章《沒用過Node.js，就別瞎逼逼》是因為有人在知乎上黑Node.js。那篇文章的反響還是相當不錯的，甚至連著名的hax賀老都很認同，下班時讀那篇文章，竟然坐車的還坐過站了。大家可以很明顯的感到Node.js的普及度還不夠，還存很多誤解。甚至說很多小白用戶也得不到很好的學習。大神都功成身退，書也跟不上，大部分都是2013年左右的，Node.js版本都是基于v0.10左右的，現在已經v9了。想想也是有點可惜，使用如此廣泛的Node.js被大家默認，卻沒人來科普。

反思之后，我就想準備一個科普的Live，于是就有了《狼叔：如何正確學習 Node.js？》，相信能夠對很多喜歡Node.js的朋友有所幫助。Live已完成目前1200多人，230人評價，平均4.8+，還算是一個比較成功的Live。現整理出來，希望對更多朋友有用。

感謝 @justjavac 大神的 免費的計算機編程類中文書籍 收錄并推薦

github地址，以后在倉庫里更新

Live地址，聲音版

Live 簡介

現在，越來越多的科技公司和開發者開始使用 Node.js 開發各種應用。Node.js除了能夠輔助大前端開發外，還可以編寫Web應用，封裝Api，組裝RPC服務等，甚至是開發VSCode編輯器一樣的PC客戶端。和其它技術相比， Node.js 簡單易學，性能好、部署容易，能夠輕松處理高并發場景下的大量服務器請求。Node.js 周邊的生態也非常強大，NPM（Node包管理）上有超過60萬個模塊，日下超過載量3億次。但編寫 Node.js 代碼對新人和其它語言背景的開發者來說，不是一件容易的事，在入門之前需要弄懂不少復雜的概念。

我身邊也有很多人問我：如何學習 Node.js ？作為一名 Node.js 布道者，我做過很多 Node.js 普及和推廣的工作，對它的基本概念和核心模塊都很熟悉； 此外，我還在撰寫一本名為《更了不起的 Node.js 》的書，已經寫了 2 年，積累了很豐富的資料，本次 Live 也將為你提供對 Node.js 更全面的解讀。

本次 Live 主要包括以下內容，目錄

Part 0 ：Node.js簡介

a）Node.js簡介
b）什么是Node.js？
c）基本原理

Part 1前言：學習 Node.js 的三個境界

Part 2準備：如何學習Node.js

2.1 Node 用途那么多，我該從哪里學起？

2.2 Node Web 框架那么多，我該怎么選？

2.3 關于 Node 的書幾乎都過時了，我該買哪本？

Part 3延伸：大前端變化那么快，如何才能做到每日精進？

Part 4實踐：從招聘角度來看， Node.js 開發需要具備哪些技能？

Part 5答疑：回答大家的問題

本次Live主要是科普，適用新用戶和比較迷茫的Node朋友，希望大家多多理解和支持。

a）Node.js簡介
b）什么是Node.js？
c）基本原理

Node.js 誕生于 2009 年，由 Joyent 的員工 Ryan Dahl 開發而成，之后 Joyent 公司一直扮演著 Node.js 孵化者的角色。由于諸多原因，Ryan 在2012年離開社區，隨后在2015年由于 Node 貢獻者對 es6 新特性集成問題的分歧，導致分裂出iojs，并由 iojs 發布1.0、2.0和3.0版本。由于 iojs 的分裂最終促成了2015年Node基金會的成立，并順利發布了4.0版本。Node.js基金會的創始成員包括 Google、Joyent、IBM、Paypal、微軟、Fidelity 和 Linux基金會，創始成員將共同掌管過去由 Joyent 一家企業掌控的 Node.js 開源項目。此后，Node.js基金會發展非常好，穩定的發布5、6、7、8等版本，截止發稿最新版本已經是8.6，長期支持版本是6.11。

Node.js 不是一門語言也不是框架，它只是基于 Google V8 引擎的 JavaScript 運行時環境，同時結合 Libuv 擴展了 JavaScript 功能，使之支持 io、fs 等只有語言才有的特性，使得 JavaScript 能夠同時具有 DOM 操作(瀏覽器)和 I/O、文件讀寫、操作數據庫(服務器端)等能力，是目前最簡單的全棧式語言。

早在2007年，Jeff Atwood 就提出了著名的 Atwood定律

任何能夠用 JavaScript 實現的應用系統，最終都必將用 JavaScript 實現

目前 Node.js 在大部分領域都占有一席之地，尤其是 I/O 密集型的，比如 Web 開發，微服務，前端構建等。不少大型網站都是使用 Node.js 作為后臺開發語言的，用的最多的就是使用Node.js做前端渲染和架構優化，比如 淘寶 雙十一、去哪兒網 的 PC 端核心業務等。另外，有不少知名的前端庫也是使用 Node.js 開發的，比如，Webpack 是一個強大的打包器，React/Vue 是成熟的前端組件化框架。

Node.js通常被用來開發低延遲的網絡應用，也就是那些需要在服務器端環境和前端實時收集和交換數據的應用（API、即時聊天、微服務）。阿里巴巴、騰訊、Qunar、百度、PayPal、道瓊斯、沃爾瑪和 LinkedIn 都采用了 Node.js 框架搭建應用。

另外， Node.js 編寫的包管理器 npm 已成為開源包管理了領域最好的生態，直接到2017年10月份，有模塊超過47萬，每周下載量超過32億次，每個月有超過700萬開發者使用npm。

當然了，Node.js 也有一些缺點。Node.js 經常被人們吐槽的一點就是：回調太多難于控制（俗稱回調地獄）和 CPU 密集任務處理的不是很好。但是，目前異步流程技術已經取得了非常不錯的進步，從Callback、Promise 到 Async函數，可以輕松的滿足所有開發需求。至于 CPU 密集任務處理并非不可解，方案有很多，比如通過系統底層語言 Rust 來擴展 Node.js，但這樣會比較麻煩。筆者堅信在合適的場景使用合適的東西，尤其是在微服務架構下，一切都是服務，可以做到語言無關。如果大家想使 JavaScript 做 CPU 密集任務，推薦 Node.js 的兄弟項目 fibjs，基于纖程(fiber，可以簡單理解為更輕量級的線程)，效率非常高，兼容npm，同時沒有異步回調煩惱。

按照 Node.js官方網站主頁 的說法:

Node.js? is a JavaScript runtime built on Chrome"s V8 JavaScript engine. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient. Node.js" package ecosystem, npm, is the largest ecosystem of open source libraries in the world.

從這段介紹來看，解讀要點如下

Node.js 不是 JavaScript 應用，不是語言（JavaScript 是語言），不是像 Rails(Ruby)、 Laravel(PHP) 或 Django(Python) 一樣的框架，也不是像 Nginx 一樣的 Web 服務器。Node.js 是 JavaScript 運行時環境

構建在 Chrome"s V8 這個著名的 JavaScript 引擎之上，Chrome V8 引擎以 C/C++ 為主，相當于使用JavaScript 寫法，轉成 C/C++ 調用，大大的降低了學習成本

事件驅動（event-driven），非阻塞 I/O 模型（non-blocking I/O model），簡單點講就是每個函數都是異步的，最后由 Libuv 這個 C/C++ 編寫的事件循環處理庫來處理這些 I/O 操作，隱藏了非阻塞 I/O 的具體細節，簡化并發編程模型，讓你可以輕松的編寫高性能的Web應用，所以它是輕量（lightweight）且高效（efficient）的

使用 npm 作為包管理器，目前 npm 是開源庫里包管理最大的生態，功能強大，截止到2017年12月，模塊數量超過 60 萬+

大多數人都認為 Node.js 只能寫網站后臺或者前端工具，這其實是不全面的，Node.js的目標是讓并發編程更簡單，主要應用在以網絡編程為主的 I/O 密集型應用。它是開源的，跨平臺，并且高效（尤其是I/O處理），包括IBM、Microsoft、Yahoo、SAP、PayPal、沃爾瑪及GoDaddy都是 Node.js 的用戶。

下面是一張 Node.js 早期的架構圖，來自 Node.js 之父 Ryan Dahl 的演講稿，在今天依然不過時，它簡要的介紹了 Node.js 是基于 Chrome V8引擎構建的，由事件循環（Event Loop）分發 I/O 任務，最終工作線程（Work Thread）將任務丟到線程池（Thread Pool）里去執行，而事件循環只要等待執行結果就可以了。

核心概念

Chrome V8 是 Google 發布的開源 JavaScript 引擎，采用 C/C++ 編寫，在 Google 的 Chrome 瀏覽器中被使用。Chrome V8 引擎可以獨立運行，也可以用來嵌入到 C/C++ 應用程序中執行。

Event Loop 事件循環（由 libuv 提供）

Thread Pool 線程池（由 libuv 提供）

梳理一下

Chrome V8 是 JavaScript 引擎

Node.js 內置 Chrome V8 引擎，所以它使用的 JavaScript 語法

JavaScript 語言的一大特點就是單線程，也就是說，同一個時間只能做一件事

單線程就意味著，所有任務需要排隊，前一個任務結束，才會執行后一個任務。如果前一個任務耗時很長，后一個任務就不得不一直等著。

如果排隊是因為計算量大，CPU 忙不過來，倒也算了，但是很多時候 CPU 是閑著的，因為 I/O 很慢，不得不等著結果出來，再往下執行

CPU 完全可以不管 I/O 設備，掛起處于等待中的任務，先運行排在后面的任務

將等待中的 I/O 任務放到 Event Loop 里

由 Event Loop 將 I/O 任務放到線程池里

只要有資源，就盡力執行

我們再換一個維度看一下

核心

Chrome V8 解釋并執行 JavaScript 代碼（這就是為什么瀏覽器能執行 JavaScript 原因）

libuv 由事件循環和線程池組成，負責所有 I/O 任務的分發與執行

在解決并發問題上，異步是最好的解決方案，可以拿排隊和叫號機來理解

排隊：在排隊的時候，你除了等之外什么都干不了

叫號機：你要做的是先取號碼，等輪到你的時候，系統會通知你，這中間，你可以做任何你想做的事兒

Node.js 其實就是幫我們構建類似的機制。我們在寫代碼的時候，實際上就是取號的過程，由 Event Loop 來接受處理，而真正執行操作的是具體的線程池里的 I/O 任務。之所以說 Node.js 是單線程，就是因為在接受任務的時候是單線程的，它無需進程/線程切換上下文的成本，非常高效，但它在執行具體任務的時候是多線程的。

Node.js 公開宣稱的目標是 “旨在提供一種簡單的構建可伸縮網絡程序的方法”，毫無疑問，它確實做到了。這種做法將并發編程模型簡化了，Event Loop和具體線程池等細節被 Node.js 封裝了，繼而將異步調用 Api 寫法暴露給開發者。真是福禍相依，一方面簡化了并發編程，另一方面在寫法上埋下了禍根，這種做法的好處是能讓更多人輕而易舉的寫出高性能的程序！

在Node.js Bindings層做的事兒就是將 Chrome V8 等暴露的 C/C++ 接口轉成JavaScript Api，并且結合這些 Api 編寫了 Node.js 標準庫，所有這些 Api 統稱為 Node.js SDK，后面模塊章節會有更詳細的討論。

微軟在2016年宣布在MIT許可協議下開放 Chakra 引擎，并以 ChakraCore 為名在 Github 上開放了源代碼，ChakraCore 是一個完整的 JavaScript 虛擬機，它擁有著和 Chakra 幾乎相同的功能與特性。微軟向 Node.js 主分支提交代碼合并請求，讓 Node.js 用上 ChakraCore引擎，即 nodejs/node-chakracore 項目。實際上微軟是通過創建名為 V8 shim 的庫的賦予了 ChakraCore 處理谷歌 Chrome V8 引擎指令的能力，其原理示意圖如下

目前，Node.js 同時支持這2種 JavaScript 引擎，二者性能和特性上各有千秋，ChakraCore 在特性上感覺更潮一些，曾經是第一個支持 Async函數 的引擎，但目前 Node.js 還是以 Chrome V8 引擎為主， ChakraCore 版本需要多帶帶安裝，大家了解一下就好。

我總結的編程3種境界

打日志：console.log

斷點調試：斷點調試：node debugger 或node inspector 或vscode

測試驅動開發（tdd | bdd）

大家可以自測一下，自己在哪個水平？如果是第三個階段，那么本場Live可能不太適合你。哈哈哈

Node不是語言，不是框架，只是基于V8運行時環境。結合libuv能夠通過js語法獲得更好的等價于c/c++的性能。

它很簡單，異步是解決并發的最佳實踐。本節主要講如何學習Node.js，是本次Live非常核心的內容，大家要注意聽。

1）js語法必須會

js基本語法，都是c語系的，有其他語言背景學習起來相對更簡單

常見用法，比如正則，比如數據結構，尤其是數組的幾種用法。比如bind/call/apply等等

面向對象寫法。js是基于對象的，所以它的oo寫起來非常詭異。參見紅皮書JavaScript高級編程，很多框架都是自己實現oo基礎框架，比如ext-core等。

犀牛書，《JavaScript權威指南》，沒事就多翻翻，看少多少遍都不為過。

2）個人學習和技術選型都要循序漸進

先能寫，采用面向過程寫法，簡單理解就是定義一堆function，然后調用，非常簡單

然后再追求更好的寫法，可以面向對象。對于規模化的編程來說，oo是有它的優勢的，一般java、c#，ruby這些語言里都有面向對象，所以后端更習慣，但對于語言經驗不那么強的前端來說算高級技巧。

等oo玩膩了，可以有更好的追求：函數式編程，無論編程思維，還是用法上都對已有的編程思維是個挑戰。我很喜歡函數式，但不太會在團隊里使用，畢竟oo階段還沒完全掌握，風險會比較大。但如果團隊水平都非常高了，團隊穩定是可以用的。

可以看出我的思路，先能寫，然后再追求更好的寫法，比如面向對象。等團隊水平到一定程度了，并且穩定的時候，可以考慮更加極致的函數式寫法。

團隊是這樣選型的，個人學習也這樣，最好是循序漸進，步子邁大了不好。

3）各種高級的JavaScript友好語言

JavaScript友好語言指的是能夠使用其他語法實現，但最終編譯成js的語言。自從Node.js出現后，這種黑科技層出不窮。比如比較有名的coffee、typescript、babel（es）等。

CoffeeScript雖然也是JavaScript友好語言，但其語法借鑒ruby，崇尚極簡，對于類型和OO機制上還是偏弱，而且這么多年也沒發展起來，仍然是比較小眾的活著。未來比例會越來越少的。

顯然TypeScript會越來越好，TypeScript 的強大之處是要用過才知道的。

1）規模化編程，像Java那種，靜態類型，面向對象，前端只有TypeScript能做到

2）親爹是微軟安德斯·海爾斯伯格，不知道此人的請看borland傳奇去

3）開源，未來很好

4）組合拳：TypeScript + VSCode = 神器

當下前端發展速度極快，以指數級的曲線增長。以前可能1年都不一定有一項新技術，現在可能每個月都有。大前端，Node全棧，架構演進等等都在快速變化。可以說，前端越復雜，有越多的不確定性，TypeScript的機會就越大。

4）再論面向對象

面向對象想用好也不容易的，而且js里有各種實現，真是讓人眼花繚亂。

基于原型的寫法，縱觀JavaScript高級編程，就是翻來覆去的講這個，這個很基礎，但不好是很好用。可以不用，但不可以不會。

自己寫面向對象機制是最好的，但不是每個人都有這個能力的。好在es6規范出了更好一點的面向對象，通過class、extends、super關鍵字來定義類，已經明顯好很多了，雖然還很弱，但起碼勉強能用起來了。從面向過程走過來的同學，推薦這種寫法，簡單易用。但要注意面向對象要有面向對象的寫法，要理解抽象，繼承，封裝，多態4個基本特征。如果想用好，你甚至還需要看一些設計模式相關的書。好在有《JavaScript設計模式》一書。Koa2里已經在用這種寫法了。

js是腳本語言，解釋即可執行。所以它的最大缺點是沒有類型系統，這在規模化編程里是非常危險的，一個函數，傳參就能玩死人。于是現在流行使用flow和typescript來做類型校驗。flow只是工具，比較輕量級。而typescript是es6超級，給es6補充了類型系統和更完善的面向對象機制，所以大部分人都會對ts有好感，很有可能是未來的趨勢。

對于es6高級特性，我是比較保守的，一般node長期支持版本lts支持的我都讓用，一些更新的特性我一般不讓使用。根本lts版本保持一致就好。

我的團隊現在是采用es6的面向對象寫法開發，后面會一點一點轉到typescript上的。熟練oo轉到ts是非常容易的。

3m安裝法

nvm（node version manager）【需要使用npm安裝，替代品是yrm（支持yarn），nvs對window支持很好】

nrm（node registry manager）【需要使用npm安裝，替代品是yrm（支持yarn）】

npm（node packages manager）【內置，替代品是n或nvs（對win也支持）】

node版本發布非常快，而且多版本共存可能性較大，推薦使用nvm來安裝node

$ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.6/install.sh | bash

$ echo "export NVM_DIR="$HOME/.nvm"" >> ~/.zshrc
$ echo "[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" # This loads nvm" >> ~/.zshrc
$ source ~/.zshrc

$ nvm install 0.10
$ nvm install 4
$ nvm install 6
$ nvm install 8

https://registry.npmjs.com 是node官方的源（registry），服務器在國外，下載速度較慢，推薦安裝nrm來切換源，國內的cnpm和taobao的源都非常快，當然，如果你想自建源也是支持的。

$ npm install --global nrm --registry=https://registry.npm.taobao.org
$ nrm use cnpm

nrm切換完源之后，你安裝npm模塊的速度會更快。

$ npm install --global yarn

npm基本命令

1）oh my zsh是我最習慣的shell，終端下非常好用

配合iterm2分屏 + spectacle全屏，幾乎無敵

2）brew是mac裝軟件非常好的方式，和apt-get、rpm等都非常類似

安裝4個必備軟件

brew install git 最流行的SCM源碼版本控制軟件

brew install wget 下載、扒站神器

brew install ack 搜索代碼神器

brew install autojump 終端下多目錄跳轉神器

3）vim

我雖然不算vim黨，但也深愛著。janus是一個非常好用的vim集成開發環境。比如ctrl-p、nerdtree等插件都集成了，對我這種懶人足夠了。

關于Node.js的IDE和編輯器有很多選擇，對比如下

Visual Studio Code是一個運行于 Mac、Windows和 Linux 之上的，針對于編寫現代 Web 和云應用的跨平臺源代碼編輯器。它功能強大，便于調試，加上它本身也是基于 Node.js 模塊 electron 構建的，尤其要推薦大家使用。

Visual Studio Code（以下簡稱vsc）

vsc是一個比較潮比較新的編輯器（跨平臺Mac OS X、Windows和 Linux ）

vsc功能和textmate、sublime、notepad++，ultraedit等比較，毫不遜色

vsc尤其是在nodejs（調試）和typescript、go上支持尤其好

vsc提供了自定義 Debugger Adapter 和 VSCode Debug Protocol 從而實現自己的調試器

值得一學，我推薦VSCode編輯器！

更多調試方法，參見https://github.com/i5ting/nod...

《Node.js in action》一書里說，Node.js 所針對的應用程序有一個專門的簡稱：DIRT。它表示數據密集型實時（data-intensive real-time）程序。因為 Node.js 自身在 I/O 上非常輕量，它善于將數據從一個管道混排或代理到另一個管道上，這能在處理大量請求時持有很多開放的連接，并且只占用一小部分內存。它的設計目標是保證響應能力，跟瀏覽器一樣。

這話不假，但在今天來看，DIRT 還是范圍小了。其實 DIRT 本質上說的 I/O 處理的都算，但隨著大前端的發展，Node.js 已經不再只是 I/O 處理相關，而是更加的“Node”！

Node.js 使用場景主要分為4大類

1）跨平臺：覆蓋你能想到的面向用戶的所有平臺，傳統的PC Web端，以及PC客戶端 nw.js/electron 、移動端 cordova、HTML5、react-native、weex，硬件 ruff.io 等

2）Web應用開發：網站、Api、RPC服務等

3）前端：三大框架 React Vue Angular 輔助開發，以及工程化演進過程（使用Gulp /Webpack 構建 Web 開發工具）

4）工具：npm上各種工具模塊，包括各種前端預編譯、構建工具 Grunt / Gulp、腳手架，命令行工具，各種奇技淫巧等

下面列出具體的 Node.js 的使用場景，以模塊維度劃分

Node.js 應用場景非常豐富，比如 Node.js 可以開發操作系統，但一般我都不講的，就算說了也沒多大意義，難道大家真的會用嗎？一般，我習慣將 Node.js 應用場景氛圍7個部分。

1）初衷，server端，不想成了前端開發的基礎設施
2）命令行輔助工具，甚至可以是運維
3）移動端：cordova，pc端：nw.js和electron
4）組件化，構建，代理
5）架構，前后端分離、api proxy
6）性能優化、反爬蟲與爬蟲
7) 全棧最便捷之路

可以說目前大家能夠看到的、用到的軟件都有 Node.js 身影，當下最流行的軟件寫法也大都是基于 Node.js 的，比如 PC 客戶端 luin/medis 采用 electron 打包，寫法采用 React + Redux。我自己一直的實踐的【Node全棧】，也正是基于這種趨勢而形成的。在未來，Node.js 的應用場景會更加的廣泛，更多參見 sindresorhus/awesome-nodejs。

Node.js是為異步而生的，它自己把復雜的事兒做了（高并發，低延時），交給用戶的只是有點難用的Callback寫法。也正是坦誠的將異步回調暴露出來，才有更好的流程控制方面的演進。也正是這些演進，讓Node.js從DIRT（數據敏感實時應用）擴展到更多的應用場景，今天的Node.js已經不只是能寫后端的JavaScript，已經涵蓋了所有涉及到開發的各個方面，而Node全棧更是熱門種的熱門。

直面問題才能有更好的解決方式，Node.js的異步是整個學習Node.js過程中重中之重。

1) 異步流程控制學習重點

2）Api寫法：Error-first Callback 和 EventEmitter

3）中流砥柱：Promise

4）終極解決方案：Async/Await

我整理了一張圖，更直觀一些。從09年到現在，8年多的時間里，整個Node.js社區做了大量嘗試，其中曲折足足夠寫一本書的了。大家先簡單了解一下。

紅色代表Promise，是使用最多的，無論async還是generator都可用

藍色是Generator，過度貨

綠色是Async函數，趨勢

結論：Promise是必須會的，那你為什么不順勢而為呢？

推薦：使用Async函數 + Promise組合，如下圖所示。

其實，一般使用是不需要掌握上圖中的所有技術的。對于初學者來說，先夠用，再去深究細節。所以，精簡一下，只了解3個就足夠足夠用了。

結論

Node.js SDK里callback寫法必須會的。

Node.js學習重點: Async函數與Promise

中流砥柱：Promise

終極解決方案：Async/Await

所以下面我們會分個小部分進行講解。

a）Error-first Callback
定義錯誤優先的回調寫法只需要注意2條規則即可：

回調函數的第一個參數返回的error對象，如果error發生了，它會作為第一個err參數返回，如果沒有，一般做法是返回null。

回調函數的第二個參數返回的是任何成功響應的結果數據。如果結果正常，沒有error發生，err會被設置為null，并在第二個參數就出返回成功結果數據。

下面讓我們看一下調用函數示例，Node.js 文檔里最常采用下面這樣的回調方式：

function(err, res) {
  // process the error and result
}

這里的 callback 指的是帶有2個參數的函數："err"和 "res"。語義上講，非空的“err”相當于程序異常；而空的“err”相當于可以正常返回結果“res”，無任何異常。

b）EventEmitter

事件模塊是 Node.js 內置的對觀察者模式“發布/訂閱”（publish/subscribe）的實現，通過EventEmitter屬性，提供了一個構造函數。該構造函數的實例具有 on 方法，可以用來監聽指定事件，并觸發回調函數。任意對象都可以發布指定事件，被 EventEmitter 實例的 on 方法監聽到。

在node 6之后，可以直接使用require("events")類

var EventEmitter = require("events")
var util = require("util")

var MyEmitter = function () {
 
}

util.inherits(MyEmitter, EventEmitter)

const myEmitter = new MyEmitter();

myEmitter.on("event", (a, b) => {
  console.log(a, b, this);
    // Prints: a b {}
});

myEmitter.emit("event", "a", "b");

和jquery、vue里的Event是非常類似的。而且前端自己也有EventEmitter。

c）如何更好的查Node.js文檔

API是應用程序接口Application Programming Interface的簡稱。從Node.js異步原理，我們可以知道，核心在于 Node.js SDK 中API調用，然后交由EventLoop（Libuv）去執行，所以我們一定要熟悉Node.js的API操作。

Node.js的API都是異步的，同步的函數是奢求，要查API文檔，在高并發場景下慎用。

筆者推薦使用 Dash 或 Zeal 查看離線文檔，經常查看離線文檔，對Api理解會深入很多，比IDE輔助要好，可以有效避免離開IDE就不會寫代碼的窘境。

回調地獄

Node.js 因為采用了錯誤優先的回調風格寫法，導致sdk里導出都是回調函數。如果組合調用的話，就會特別痛苦，經常會出現回調里嵌套回調的問題，大家都非常厭煩這種寫法，稱之為Callback Hell，即回調地獄。一個經典的例子來自著名的Promise模塊q文檔里。

step1(function (value1) {
    step2(value1, function(value2) {
        step3(value2, function(value3) {
            step4(value3, function(value4) {
                // Do something with value4
            });
        });
    });
});

這里只是做4步，嵌套了4層回調，如果更多步驟呢？很多新手淺嘗輒止，到這兒就望而卻步，粉轉黑。這明顯不夠成熟，最起碼你要看看它的應對解決方案吧！

Node.js 約定所有Api都采用錯誤優先的回調方式，這部分場景都是大家直接調用接口，無太多變化。而Promise是對回調地獄的思考，或者說是改良方案。目前使用非常普遍，可以說是在async函數普及之前唯一一個通用性規范，甚至 Node.js 社區都在考慮 Promise 化，可見其影響之大。

Promise最早也是在commonjs社區提出來的，當時提出了很多規范。比較接受的是promise/A規范。后來人們在這個基礎上，提出了promise/A+規范，也就是實際上現在的業內推行的規范。ES6 也是采用的這種規范。

Promise意味著[許愿|承諾]一個還沒有完成的操作，但在未來會完成的。與Promise最主要的交互方法是通過將函數傳入它的then方法從而獲取得Promise最終的值或Promise最終最拒絕（reject）的原因。要點有三個：

遞歸，每個異步操作返回的都是promise對象

狀態機：三種狀態轉換，只在promise對象內部可以控制，外部不能改變狀態

全局異常處理

1)定義

var promise = new Promise(function(resolve, reject) {
  // do a thing, possibly async, then…

  if (/* everything turned out fine */) {
    resolve("Stuff worked!");
  }
  else {
    reject(Error("It broke"));
  }
});

每個Promise定義都是一樣的，在構造函數里傳入一個匿名函數，參數是resolve和reject，分別代表成功和失敗時候的處理。

2)調用

promise.then(function(text){
    console.log(text)// Stuff worked!
    return Promise.reject(new Error("我是故意的"))
}).catch(function(err){
    console.log(err)
})

它的主要交互方式是通過then函數，如果Promise成功執行resolve了，那么它就會將resolve的值傳給最近的then函數，作為它的then函數的參數。如果出錯reject，那就交給catch來捕獲異常就好了。

Promise 的最大優勢是標準化，各類異步工具庫都按照統一規范實現，即使是async函數也可以無縫集成。所以用 Promise 封裝 API 通用性強，用起來簡單，學習成本低。在async函數普及之前，絕大部分應用都是采用Promise來做異步流程控制的，所以掌握Promise是Node.js學習過程中必須要掌握的重中之重。

Bluebird是 Node.js 世界里性能最好的Promise/a+規范的實現模塊，Api非常齊全，功能強大，是原生Promise外的不二選擇。

好處如下：

避免Node.js內置Promise實現 問題，使用與所有版本兼容

避免Node.js 4曾經出現的內存泄露問題

內置更多擴展，timeout、 promisifyAll等，對Promise/A+規范提供了強有力的補充

限于時間關系，這里就不一一列舉了，還是那句話，在學習Node.js過程中，對于Promise了解多深入都不過分。

推薦學習資料

Node.js最新技術棧之Promise篇 https://cnodejs.org/topic/560...

理解 Promise 的工作原理 https://cnodejs.org/topic/569...

Promise 迷你書 http://liubin.github.io/promi...

Async/Await是異步操作的終極解決方案，Koa 2在node 7.6發布之后，立馬發布了正式版本，并且推薦使用async函數來編寫Koa中間件。

這里給出一段Koa 2應用里的一段代碼

exports.list = async (ctx, next) => {
  try {
    let students = await Student.getAllAsync();
  
    await ctx.render("students/index", {
      students : students
    })
  } catch (err) {
    return ctx.api_error(err);
  }
};

它做了3件事兒

通過await Student.getAllAsync();來獲取所有的students信息。

通過await ctx.render渲染頁面

由于是同步代碼，使用try/catch做的異常處理

是不是非常簡單，現在Eggjs里也都是這樣同步的代碼。

4.1 正常寫法

const pkgConf = require("pkg-conf");

async function main(){
    const config = await pkgConf("unicorn");

    console.log(config.rainbow);
    //=> true
}

main();

{{BANNED}}寫法

const pkgConf = require("pkg-conf");

(async () => {
    const config = await pkgConf("unicorn");

    console.log(config.rainbow);
    //=> true
})();

4.2 await + Promise

const Promise = require("bluebird");
const fs = Promise.promisifyAll(require("fs"));

async function main(){
    const contents = await fs.readFileAsync("myfile.js", "utf8")
    console.log(contents);
}

main();

4.3 await + co + generator

const co = require("co");
const Promise = require("bluebird");
const fs = Promise.promisifyAll(require("fs"));

async function main(){
   const contents = co(function* () {
      var result = yield fs.readFileAsync("myfile.js", "utf8")
      return result;
   })

    console.log(contents);
}

main();

要點

co的返回值是promise，所以await可以直接接co。

co的參數是genrator

在generator里可以使用yield，而yield后面接的有5種可能，故而把這些可以yield接的方式成為yieldable，即可以yield接的。

Promises

Thunks (functions)

array (parallel execution)

objects (parallel execution)

Generators 和 GeneratorFunctions

由上面3中基本用法可以推出Async函數要點如下：

Async函數語義上非常好

Async不需要執行器，它本身具備執行能力，不像Generator需要co模塊

Async函數的異常處理采用try/catch和Promise的錯誤處理，非常強大

Await接Promise，Promise自身就足夠應對所有流程了，包括async函數沒有純并行處理機制，也可以采用Promise里的all和race來補齊

Await釋放Promise的組合能力，外加co和Promise的then，幾乎沒有不支持的場景

綜上所述

Async函數是趨勢，如果Chrome 52. v8 5.1已經支持Async函數(https://github.com/nodejs/CTC...，Node.js支持還會遠么？

Async和Generator函數里都支持promise，所以promise是必須會的。

Generator和yield異常強大，不過不會成為主流，所以學會基本用法和promise就好了，沒必要所有的都必須會。

co作為Generator執行器是不錯的，它更好的是當做Promise 包裝器，通過Generator支持yieldable，最后返回Promise，是不是有點無恥？

小結

這部分共講了4個小點，都是極其直接的必須掌握的知識點。

1) 異步流程控制學習重點

2）Api寫法：Error-first Callback 和 EventEmitter

3）中流砥柱：Promise

4）終極解決方案：Async/Await

這里再提一下關于Node.js源碼閱讀問題，很多人api都還沒完熟練就去閱讀源碼，這是非常不贊成的，不帶著問題去讀源碼是比較容易迷失在大量代碼中的。效果并不好。

先用明白，然后再去閱讀Node.js源碼，然后探尋libuv并發機制。很多人買了樸大的《深入淺出Node.js》一書，看了之后還是不太會用，不是書寫的不好，而是步驟不對。

Node in action和了不起的Node.js是入門的絕好書籍，非常簡單，各個部分都講了，但不深入，看了之后，基本就能用起來了

當你用了一段之后，你會對Node.js的運行機制好奇，為啥呢？這時候去讀樸大的《深入淺出Node.js》一書就能夠解惑。原因很簡單，九淺一深一書是偏向底層實現原理的書，從操作系統，并發原理，node源碼層層解讀。如果是新手讀，難免會比較郁悶。

實踐類的可以看看雷宗民（老雷）和趙坤（nswbmw）寫的書

我一般給大家的推薦是把Node in action讀上5遍10遍，入門干活足夠了。剩下的就是反復實踐，多寫代碼和npm模塊就好。

目前所有的書籍幾乎都有點過時了，大部分都是Node.js v0.10左右的版本的，我得新書是基于Node.js 8版本的，預計2018年3月或4月出版。別催我，真沒法更快了。

目錄

01 Node.js初識

02 安裝與入門

03 更了不起的Node.js

04 更好的Node.js

05 Node.js是如何執行的

06 模塊與核心

07 異步寫法與流程控制

08 下一代Web框架Koa入門

09 Koa的核心擴展機制：中間件

10 HTTP協議必知必會

11 Koa練習

12 數據庫入門

13 數據庫進階

14 視圖模板

15 Koa項目實戰

16 自己動手寫NPM模塊

17 Node.js企業級Web開發

18 構建具有Node.js特色的微服務

19 讓Node.js跑的更穩

20 讓Node.js跑的更快

博文視點的美女編輯在苦逼的整理中，預計出版在3月之后（不要催我，我也沒法說），20章，800頁+，定價預計在130+。

一般，后端開發指的是 Web 應用開發中和視圖渲染無關的部分，主要是和數據庫交互為主的重業務型邏輯處理。但現在架構升級后，Node.js 承擔了前后端分離重任之后，有了更多玩法。從帶視圖的傳統Web應用和面向Api接口應用，到通過 RPC 調用封裝對數據庫的操作，到提供前端 Api 代理和網關，服務組裝等，統稱為后端開發，不再是以往只有和數據庫打交道的部分才算后端。這樣，就可以讓前端工程師對開發過程可控，更好的進行調優和性能優化。

對 Node.js 來說，一直沒有在后端取得其合理的占有率，原因是多方面的，暫列幾條。

1）利益分配，已有實現大多是Java或者其他語言，基本是沒法撼動的，重寫的成本是巨大的，另外，如果用Node寫了，那么那些寫Java的人怎么辦？搶人飯碗，這是要拼命的。

2）Node相對年輕，大家對Node的理解不夠，回調和異步流程控制略麻煩，很多架構師都不愿意花時間去學習。盡管在Web應用部分處理起來非常簡單高效，但在遇到問題時并不容易排查定位，對開發者水平要求略高。

3）開發者技能單一，很多是從前端轉過來的，對數據庫，架構方面知識欠缺，對系統設計也知之不多，這是很危險的，有種麻桿打狼兩頭害怕的感覺。

4）Node在科普、培訓、布道等方面做的并不好，國外使用的非常多，國內卻很少人知道，不如某些語言做得好。

盡管如此，Node.js 還是盡人皆知，卷入各種是非風口，也算是在大前端浪潮中大紅大紫。原因它的定位非常明確，補足以 JavaScript 為核心的全棧體系中服務器部分。開發也是人，能夠同時掌握并精通多門語言的人畢竟不多，而且程序員的美德是“懶”，能使用 JavaScript 一門語言完成所有事兒，為什么要學更多呢？

對于 Web 應用大致分2種，帶視圖的傳統Web應用和面向Api接口應用，我們先看一下 Node.js Web 應用開發框架的演進時間線大致如下：

2010年 TJ Holowaychuk 寫的 Express

2011年 Derby.js 開始開發，8月5日，WalmartLabs 的一位成員 Eran Hammer 提交了 Hapi 的第一次git記錄。Hapi 原本是 Postmile 的一部分，并且最開始是基于 Express 構建的。后來它發展成自己自己的框架，

2012年1月21日，專注于 Rest api 的 Restify 發布1.0版本，同構的 Meteor 開始投入開發，最像Rails 的 Sails 也開始了開發

2013年 TJ Holowaychuk 開始玩 es6 generator，編寫 co 這個 Generator 執行器，并開始了Koa 項目。2013 年下半年李成銀開始 ThinkJS，參考 ThinkPHP

2014年4月9日，Express 發布4.0，進入4.x時代持續到今天，MEAN.js 開始隨著 MEAN 架構的提出開始開發，意圖大一統，另外 Total.js 開始起步，最像PHP里 Laravel 或 Python 里的 Django 或 ASP.NET MVC的框架，代表著 Node.js 的成熟，開始從其他語言里的成熟框架借鑒

2015年8月22日，下一代 Web 框架 Koa 發布1.0，可以在Node.js v0.12下面，通過co 和 generator實現同步邏輯，那時候 co 還是基于 thunkfy 的，在2015年10月30日，ThinkJS發布了首個基于 Es2015+ 特性開發的 v2.0 版本

2016 年 09 月，螞蟻金服的 Eggjs，在 JSConf China 2016 上亮相并宣布開源

2017年2月，下一代Web框架 Koa 發布v2.0正式版

我們可以根據框架的特性進行分類

對于框架選型

業務場景、特點，不必為了什么而什么，避免本末倒置

自身團隊能力、喜好，有時候技術選型決定團隊氛圍的，需要平衡激進與穩定

出現問題的時候，有人能夠做到源碼級定制。Node.js 已經有8年歷史，但模塊完善程度良莠不齊，如果不慎踩到一個坑里，需要團隊在無外力的情況能夠搞定，否則會影響進度

Tips：個人學習求新，企業架構求穩，無非喜好與場景而已

Node.js 本來就為了做后端而設計的，這里我們再看看利益問題。Node.js 向后端延伸，必然會觸動后端開發的利益。那么 Proxy 層的事兒，前后端矛盾的交界處，后端不想變，前端又求變，那么長此以往，Api接口會變得越來越惡心。后端是愿意把Api的事兒叫前端的，對后端來說，只要你不動我的數據庫和服務就可以。

但是 Node.js 能不能做這部分呢？答案是能的，這個是和 Java、PHP 類似的，一般是和數據庫連接到一起，處理帶有業務邏輯的。目前國內大部分都是以 Java、PHP 等為主，所以要想吃到這部分并不容易。

小公司，創業公司，新孵化的項目更傾向于 Node.js ，簡單，快速，高效

微服務架構下的某些服務，使用 Node.js 開發，是比較合理的

國內這部分一直沒有做的很好，所以 Node.js 在大公司還沒有很好的被應用，安全問題、生態問題、歷史遺留問題等，還有很多人對 Node.js 的誤解。

單線程很脆弱，這是事實，但單線程不等于不能多核并發，而且你還有集群呢

運維，其實很簡單，比其他語言之簡單，日志采集、監控也非常簡單

模塊穩定性，對于 MongoDB、MySQL、Redis 等還是相當不錯，但其他的數據庫支持可能沒那么好。

安全問題是個偽命題，所有框架面臨的都是一樣的。

這些對于提供Api服務來說已經足夠了，本書后面有大量篇幅講如何使用 Koa 框架來構建Api服務。

Web編程核心

異步流程控制（前面講過了）

基本框架 Koa或Express，新手推薦Express，畢竟資料多，上手更容易。如果有一定經驗，推薦Koa，其實這些都是為了了解Web編程原理，尤其是中間件機制理解。

數據庫 mongodb或mysql都行，mongoose和Sequelize、bookshelf，TypeOrm等都非常不錯。對于事物，不是Node.js的鍋，是你選的數據庫的問題。另外一些偏門，想node連sqlserver等估計還不成熟，我是不會這樣用的。

模板引擎， ejs，jade，nunjucks。理解原理最好。尤其是extend，include等高級用法，理解布局，復用的好處。其實前后端思路都是一樣的。

Node.js 編寫的包管理器 npm 已成為開源包管理了領域最好的生態，直接到2017年10月份，有模塊超過47萬，每周下載量超過32億次，每個月有超過700萬開發者使用npm。現在早已經超過60萬個模塊了。

這里就不一一舉例了，給出一個迷茫時學習Node.js最好的方法吧！

某天，我在3w咖啡整理書稿，然后小弟梁過來了，聊聊他的現狀，一副很不好的樣子，在天津我曾帶過他大半年，總不能不管，我給他的建議是：“每天看10個npm模塊”

對于學習Node.js迷茫的人來說，這是最好的方式，當你不知道如何做的時候，就要向前（錢）看，你要知道積累哪些技能對以后有好處。對于學習Node.js必經之路，一定是要掌握很多模塊用法，并從中汲取技巧、思路、設計思想的。與其不知道學什么，為什么不每天積累幾個技巧呢？

推薦一個repo即 https://github.com/parro-it/a... 小型庫集合，一天看十個不是夢！

更多討論 https://zhuanlan.zhihu.com/p/...

有朋友提問

狼叔，關注你和cnode很久了，最近有點迷茫，想請你指點下。
我的情況是這樣的，非科班出身，從事前端工作4年，公司使用的技術棧是vue2、vue-router、vuex、webpack，目前的能力處理工作還是比較輕松，但是也很明確自己有很多不足，只是對于如何提升比較迷茫。
不足：
1、非科班出身，計算機基礎薄弱
2、對當前使用的技術了解不夠深入，很多東西只停留在會用的層面
3、對服務端了解較少，想學node，卻不知道如何系統的學習

解答困惑：

1、計算機基礎薄弱該如何完善自己的知識體系？

答:追逐長尾，所見所聞不懂的都去學就好啦。我是這樣過來的，頭幾年每天14個小時+，很累，不過效果還可以。os，算法，數據結構，設計模式，編譯原理，基本也就這些重點。做到每天都有進步就好，別貪多求快。數學和英文當然也是越狠越好的！

2、如何在技術上做更深入的探索？

答:技術人只關注技術，想法創意通常比較少。最簡單的辦法就是抓自己的癢，比我大學時和朋友們翻譯過grails文檔，所以對翻譯有情節。為了翻譯，我用node寫了無數工具嘗試，反復對比各種翻譯工具，理解它們背后的設計。包括markdown里嵌html標簽標識中英文，然后gulp編譯成獨立文檔。甚至一度想上線賣服務。這種折騰真的很爽，甚至耽誤了不少翻譯。有時要警惕長尾，不要忘了自己的初衷

3、如何系統的學習node？

答:階段

1/要會用，能完成工作任務
2/寫點提高效率的工具
3/參與開源項目，甚至是node源碼

應對方法

1/《node in action》看五遍，然后就去寫吧，別管代碼質量如何，能寫敢寫
2/多用些模塊，理解它們，如果有機會就自己寫一下，萬一有很多人用你，我小弟寫過一個地區選擇加載的json數據，star數不少呢
3/給別人貢獻代碼，要去學別人的習慣，網上有git標準工作流和提pr方法，你要做的是精研該模塊代碼，關注issue，其他就是等機會。另外樸靈的深入淺出多讀幾遍，試著讀node源碼，你的理解會更好。推薦看看我寫的《通過開源項目去學習》https://github.com/i5ting/Stu...
4/跳出node范圍，重新審視node的應用場景，對未來你的技術選項和決策大有裨益

2.1 Node 用途那么多，我該從哪里學起？

答：如果有機會就直接上Web應用，如果沒有機會就從前端構建，工具等方面開始做，慢慢引入更潮更酷的前端技術，自然就把Node引入進來了。不要急。

2.2 Node Web 框架那么多，我該怎么選？

答：初學者推薦Express，如果有一定經驗，推薦Koa。當然真正項目里還是推薦Eggjs和Thinkjs這樣的框架。

2.3 關于 Node 的書幾乎都過時了，我該買哪本？

答：
1）Node in action和了不起的Node.js是入門的絕好書籍，非常簡單，各個部分都講了，但不深入，看了之后，基本就能用起來了
2）當你用了一段之后，你會對Node.js的運行機制好奇，為啥呢？這時候去讀樸大的《深入淺出Node.js》一書就能夠解惑。原因很簡單，九淺一深一書是偏向底層實現原理的書，從操作系統，并發原理，node源碼層層解讀。如果是新手讀，難免會比較郁悶。
3)實踐類的可以看看雷宗民（老雷）和趙坤（nswbmw）寫的書

如果你不著急，也可以等我的那本《更了不起的Node.js》，時間待定。

有朋友問現在Android開發和web前端開發哪個前景更好？我的回答是明顯是前端更好，看一下移動端發展過程

native < hybrid < rn/weex < h5

目前rn和weex的開發逐漸變得主流，組件化寫法已經由前端主導了。以前ios和android程序員占比很高，但現在就留1到2個寫插件，真是差別很大。

Web開發對移動端的沖擊非常大。當然現在Web技術也開發PC client了，比如vscode是通過electron打包的，效果還是相當不錯的。

前端可以說是最近幾年開發里最火的部分，原因很多，最主要是開發方式的變更，以今時今日的眼光來看，稱之為現代Web開發是不為過的。

先給出現代Web開發的概覽圖

每次演講我會都問大家是不是前端，回答“是”的人非常多，我會開玩笑的恭喜大家：“現在的前端就是錢端”，確實，現在前端發展異常的快，而且沒有趨向于類比java里ssh框架的那種穩定，所以未來很長一段時間，還會增長，持續混亂，這對前端來說是把雙刃劍，一方面有很強的壓迫感，不學習就跟不上時代，另一方它也是機遇，能夠帶給更多機會，包括money。

大家都疑惑的一個問題是如何在這樣巨變的時代能夠通過學習來應變，我可以很負責的告訴大家，沒有捷徑，但通過掌握 Node.js 能夠讓你降低這個學習曲線而已，畢竟Node.js是大前端的基礎設施。大家可以看一下，前端的開發過程，模塊化，構建，輔助工具，調優，架構調整，可以說Node.js是無處不在的。

其實，輔助大前端開發只是Node.js的一個非常無心插柳的衍生功能，通過掌握Node.js能夠讓你能做的更多、獲得的更多，甚至可以說有更多自我實現的快樂，這也是我那本書書名字里“更了不起的”要去闡述的內容。

綜上種種，就是我一直提倡以 JavaScript 語言為中心的 Node全棧 概念的緣由，JavaScript 覆蓋所有前端，Node.js 擅長做 I/O 密集型的后端，外加輔助開發的各種基礎設施，無疑是工作、學習和成為快速掌握全棧技術最好的途徑。你會的越多，你能做的就更多，你的人生也將會有不一樣的精彩篇章。

全棧核心

后端不會的 UI（界面相關）

前端不會的 DB（業務相關）

只要打通這2個要點，其他就比較容易了。最怕的是哪樣都接觸點，然后就號稱自己是全棧，建議大家不要這樣做，這就好比在簡歷里寫精通一樣，基本上都會被問到尷尬。全棧是一種信仰，不是拿來吹牛逼的，而可以解決更多問題，讓自己的知識體系不留空白，享受自我實現的極致快樂。

想問一下狼叔最近的業務一直都是簡單的用express搭一個后端服務，沒有其他更加深入node的業務了，這種時候應該如何自己給自己創應用場景呢

沒有目標就向錢看，有目標就向前看

從 java 開始，蹭課，背著機箱到深圳，3個月胖20斤

堅持翻譯英文文檔，看 《Thinking in Java》

畢業后開始 bi，整理 bi 文檔

學長明林清，傳授 jQuery，愿意學，別人就更愿意分析

接手《內蒙廣電數據分析與科學決策系統》，打通前、后端

廣東聯通，自己造輪子，寫 jQuery 插件，DRY

做云計算，學習 AIX，寫有《凌云志》

分手、離職，去做 iOS，從 cordova 開始搞 H5，研究各種移動端框架，自己寫框架，轉原生

面試也是學習的利器，輕松進新浪

總結了大量 iOS 經驗，想寫書，結果寫了一堆寫書的工具

既然無法逃避，就熱愛它，最后變成興趣

去網秦做技術總監，做首席，管架構，帶人，寫開源項目

創業，當 CTO，結婚，做公眾號運營，寫書，最苦的時候沒錢吃飯，又不能找媳婦要，只能在 StuQ 上講點課

加入去哪兒網，任職前端架構師

加入阿里巴巴，前端技術專家

人生不只有代碼，但它能讓我快樂，終生受益

也曾懵懂，也曾迷茫，但我這人比較傻，一直信奉：“一次只做1件事兒，盡力做到極致”，短時間看這是比較傻的，但一旦你堅持下去，你就會發現技術其實是門手藝，厚積薄發。

我沒辦法說自己最擅長什么，但在什么場景下用什么技術是我擅長的。或者說，應變是我最大的本事。很多框架，新技術我都沒見過，用過，但花一點點過一下，就能拿已有的知識快速的理解它，這其實是長期學習的好處。

現在越來越忙，寫代碼的時間越來越少，技術又越發展越快，我能做好的就是每日精進，仗著這點已有的知識儲備跟年輕人比賽。我不覺得累，相反我很享受這種感覺，沒有被時代淘汰，是一件多么幸福的事兒。

做后端的人

對數據庫是比較熟悉，無論 mongodb，還是 mysql、postgres

對前端理解比較弱，會基本的 html，css，模板引擎等比較熟悉

4階段循序漸進，build 與工具齊飛

前端開發4階段，我的感覺是按照順序，循序漸進就好。

從前端往后端轉，api 接口非常容易學會，像 express、koa 這類框架大部分人一周就能學會，最難的是對 db、er 模型的理解，說直白點，還是業務需求落地的理解

我們來想想一般的前端有什么技能？

html

css（兼容瀏覽器）

js 會點（可能更多的是會點 jquery）

ps 切圖

firebug 和 chrome debuger 會的人都不太多

用過幾個框架，大部分人是僅僅會用

英語一般

svn/git 會一點

那么他們如果想在前端領域做的更深有哪些難點呢？

基礎：oo，dp，命令，shell，構建等

編程思想上的理解（mvc、ioc，規約等）

區分概念

外圍驗收，如 H5 和 hybird 等

追趕趨勢，如何學習新東西

以上皆是痛點，所以比較好的辦法應該是這樣的。

玩轉 npm、gulp 這樣的前端工具類（此時還是前端）

使用 node 做前后端分離（此時還是前端）

express、koa 這類框架

jade、ejs 等模板引擎

nginx

玩轉【后端】異步流程處理（promise/es6的(generator|yield)/es7(async|await)）

玩轉【后端】mongodb、mysql 對應的 Node 模塊

從我們的經驗看，這樣是比較靠譜的。先做最簡單前后端分離，里面沒有任何和db相關，前端可以非常容易的學會，基本2周就已經非常熟練了。一般半年后，讓他們接觸【異步流程處理】和【數據庫】相關內容，學習后端代碼，就可以全棧了。

看一下移動端發展過程

native < hybrid < rn/weex < h5

目前rn和weex的開發逐漸變得主流，組件化寫法已經由前端主導了。以前ios和android程序員占比很高，但現在就留1到2個寫插件，真是差別很大。狼叔一直固執的以為未來是h5的。

現在的 Native 開發是姥姥不疼舅舅不愛，非常尷尬，很明顯連培訓出的人就業不要工資混經驗就