一、BS or CS ?

? ? ? ? C/S：即Client/Server，客戶機(jī)/服務(wù)器模式。

? ? ? ? 兩層：客戶機(jī)和服務(wù)器兩層，第一層，在客戶機(jī)系統(tǒng)上結(jié)合了界面顯示與業(yè)務(wù)邏輯；第二? 層，通過(guò)網(wǎng)絡(luò)結(jié)合了數(shù)據(jù)庫(kù)服務(wù)器。

? ? ? ? ? 特 點(diǎn)：如果用戶要使用的話，需要下載客戶端，安裝后就可以使用

? ? ? ? ? 優(yōu)缺點(diǎn)：界面和操作可以很豐富；兩層傳輸，安全性高；只有一層交互，響應(yīng)速度快。一般在局域網(wǎng)中，適用面窄；需安裝，用戶群固定；升級(jí)成本高，發(fā)生一次升級(jí)，所有程序都需要更新。

? ? ? ? ?B/S：全稱為Browser/Server，即瀏覽器/服務(wù)器結(jié)構(gòu)。

? ? ? ? ?三層：表現(xiàn)層主要完成用戶和后臺(tái)的交互及最終查詢結(jié)果的輸出功能；邏輯層主要是利用服務(wù)器完成客戶端的應(yīng)用邏輯功能；數(shù)據(jù)層主要是接受客戶端請(qǐng)求后獨(dú)立進(jìn)行各種運(yùn)算。?

? ? ? ? ?優(yōu)缺點(diǎn)：無(wú)需安裝客戶端，有瀏覽器即可； 架構(gòu)在廣域網(wǎng)上，交互性強(qiáng)；更新迭代方便，只需更新服務(wù)器即可。跨瀏覽器適配問(wèn)題；中間層較多，速度和安全性問(wèn)題；請(qǐng)求響應(yīng)的交互模式，需要刷新頁(yè)面，不友好。

? ? ? ? ? 架構(gòu)形式：客戶端-服務(wù)器-數(shù)據(jù)庫(kù)；

? ? ? ? ? ? ? ? ? ? ? ? ? ? 客戶端－web服務(wù)器－應(yīng)用服務(wù)器－數(shù)據(jù)庫(kù)

? ? ? ? ? ? ? ? ? ? ? ? ? ? 客戶端－負(fù)載均衡器(Nginx)－中間服務(wù)器(Node)－應(yīng)用服務(wù)器－數(shù)據(jù)庫(kù)

二、JavaScript發(fā)展歷程

? ? ? ?工具類庫(kù)-〉組件庫(kù)-〉前端框架-〉前端應(yīng)用(不斷抽象類化的過(guò)程)

? ? ? ?暴露的問(wèn)題：缺乏模塊。通過(guò)script方式引入代碼雜亂無(wú)章。

? ? ? ?Javascript規(guī)范：CommomJs

三、CommonJs規(guī)范

? ? ? Javascript缺陷：沒有模塊系統(tǒng)；標(biāo)準(zhǔn)庫(kù)較少；沒有統(tǒng)一標(biāo)準(zhǔn)接口；缺乏包管理系統(tǒng)。

? ? ? CommonJs目的：希望javascript能夠在任何地方運(yùn)行。使javascript能編寫服務(wù)端應(yīng)用程序，命令行工具，桌面應(yīng)用程序，混合應(yīng)用。

? ? ? Node借鑒了commonJs的modules規(guī)范。

? ? ? 規(guī)范：引用:require();定義:exports;模塊標(biāo)識(shí):小駝峰命名的字符患/路徑;

? ? ? 導(dǎo)出:在node中，一個(gè)文件就是一個(gè)模塊，模塊中存在module對(duì)象，它代表模塊本身，exports是module的屬性。

四、Node模塊實(shí)現(xiàn)

? ? ? ? node加載模塊三步驟：路徑分析 文件定位 編譯執(zhí)行

? ? ? ? node模塊分類：核心模塊 文件模塊

? ? ? ? 核心模塊：node提供，在node源碼編譯中編譯進(jìn)了二進(jìn)制執(zhí)行文件，在node啟動(dòng)時(shí)，部分加載到內(nèi)存中，不需要文件定位和編譯執(zhí)行，并且在路徑分析中優(yōu)先判斷，加載速度最快

? ? ? ?文件模塊：運(yùn)行時(shí)動(dòng)態(tài)加載，需完成三步驟，速度比核心模塊慢

? ? ? ?模塊緩存加載策略：node對(duì)引入過(guò)的模塊進(jìn)行緩存，緩存的是編譯和執(zhí)行之后的對(duì)象。

? ? ? ?路徑分析與模塊定位：modules.paths，與js作用域鏈查找方式相似，逐級(jí)查找直到查找到文件。文件標(biāo)示符不包含擴(kuò)展名，按照.js 、.json、.node的順序依次補(bǔ)足擴(kuò)展名嘗試。

? ? ? ?模塊編譯：按照不同擴(kuò)展名采用不同載入方式

? ? ? ? ? ? ? ? ? ? ? ? .js 通過(guò)fs模塊同步讀取后編譯執(zhí)行。

? ? ? ? ? ? ? ? ? ? ? ? .node，c++編寫的擴(kuò)展文件，通過(guò)dlopen()加載后編譯生成文件

? ? ? ? ? ? ? ? ? ? ? ? .json，通過(guò)fs模塊同步讀取后，用json.parse()返回結(jié)果

? ? ? ? ? ? ? ? ? ? ? ? 其余文件按js文件載入

五、核心模塊

? ? ? ? ?編譯成可執(zhí)行文件過(guò)程中被編譯進(jìn)了二進(jìn)制文件。分為javascript編寫和c++編寫兩部分。C++編寫的放在node項(xiàng)目src文件夾下，javascript編寫的放在lib目錄下。

? ? ? ?Javascript核心模塊的編譯：轉(zhuǎn)存為c/c++代碼（v8附帶的js2c.py工具），通過(guò)process.binding(‘natives’)取出，編譯成功模塊緩存在NativeModule._cache對(duì)象上，文件模塊緩存在 Module._cache上。

? ? ? ? c/c++核心模塊的編譯：有的全部由c++編寫，有的c++完成核心部分，其他部分由javascript實(shí)現(xiàn)包裝向外導(dǎo)出。這種c++完成核心，javascript完成峰和鉆過(guò)的模式是node提高性能的常見方式。通常腳本語(yǔ)言的開發(fā)速度優(yōu)于靜態(tài)語(yǔ)言，但是其性能弱于靜態(tài)語(yǔ)言。Node的復(fù)合模式在開發(fā)速度和性能之間找到了平衡點(diǎn)。

? ? ? ? 核心模塊分類：由存c++編寫的部分稱為內(nèi)建模塊。如buffer、fs、os。內(nèi)建模塊的優(yōu)勢(shì)在于：首先它由c++編寫，性能上優(yōu)于腳本語(yǔ)言，其次，在進(jìn)行文本編譯時(shí)，編譯為二進(jìn)制文件，一旦node執(zhí)行，被直接加載到內(nèi)存中，無(wú)需標(biāo)識(shí)定位、文件定位、編譯過(guò)程即可執(zhí)行。

六、C++擴(kuò)展模塊??

? ? ? ? 通過(guò)預(yù)先編譯為.node文件,然后調(diào)用process.dlopen()方法執(zhí)行。

七、包與npm

? ? ? ? node第三方模塊通過(guò)包與npm將模塊聯(lián)系起來(lái)。

? ? ? 包結(jié)構(gòu)：package.json：包描述文件。bin：存放包可執(zhí)行二進(jìn)制文件的目錄。lib：存放javascript代碼的目錄。doc：存放文檔的目錄。test：存放單元測(cè)試用例的代碼。

? ? ? ?

?##代碼分類：源代碼/目標(biāo)代碼

? ? ? 源代碼：采用某種編程語(yǔ)言編寫的計(jì)算機(jī)程序，人類可讀，如result=1+2

? ? ? 目標(biāo)代碼：計(jì)算機(jī)可直接執(zhí)行，人類不可讀（專家除外），如11010010

? ? ? 將源代碼轉(zhuǎn)換為目標(biāo)代碼的方式：解釋/編譯

? ? ? 編譯：將源代碼一次性轉(zhuǎn)換成目標(biāo)代碼的過(guò)程。編譯是一次性翻譯，之后不再需要源代碼（類似英文翻譯）常用的.exe文件，就是經(jīng)過(guò)編譯后的源代碼。源代碼編譯生成機(jī)器語(yǔ)言，再由機(jī)器運(yùn)行機(jī)器碼（二進(jìn)制）。

? ? ??解釋：將源代碼逐條轉(zhuǎn)換成目標(biāo)代碼，同時(shí)逐條運(yùn)行的過(guò)程，解釋是每次程序運(yùn)行是隨翻譯執(zhí)行（類似英文的同聲傳譯）。程序時(shí)要由解釋器程序?qū)崟r(shí)地將源代碼轉(zhuǎn)換成二進(jìn)制形式運(yùn)行。

##語(yǔ)言分類

*根據(jù)解釋和編譯兩種執(zhí)行方式，編程語(yǔ)言分為解釋型語(yǔ)言和編譯型語(yǔ)言；

編譯型語(yǔ)言的優(yōu)點(diǎn)：運(yùn)行速度快，代碼效率高，編譯后程序不可以修改，保密性好。

編譯型語(yǔ)言的缺點(diǎn)：

代碼需要經(jīng)過(guò)編譯方可運(yùn)行，可移植性差，只能在兼容的操作系統(tǒng)上運(yùn)行。

安全性不如解釋性語(yǔ)言，一個(gè)編譯型的程序可以訪問(wèn)內(nèi)存的任何區(qū)域，并且可以對(duì)你的PC做它想做的任何事情（大部分病毒是使用編譯型語(yǔ)言編寫的）。

? 解釋型語(yǔ)言的優(yōu)點(diǎn)：

? ? ①解釋型語(yǔ)言提供了極佳的調(diào)試支持。

? ? ②解釋器比編譯器容易實(shí)現(xiàn)。

? ? ③中間語(yǔ)言代碼的大小比編譯型可執(zhí)行代碼小很多。例如，C/C++的.exe文件要比同樣功能的Java的.class文件大很多。

? ? ④可移植性好，只要有解釋環(huán)境，可以在不同的操作系統(tǒng)上運(yùn)行。比如在解釋執(zhí)行時(shí)可以動(dòng)態(tài)改變變量的類型、對(duì)程序進(jìn)行修改以及在程序中插入良好的調(diào)試診斷信息等，而將解釋器移植到不同的系統(tǒng)上，則程序不用改動(dòng)就可以在移植了解釋器系統(tǒng)上運(yùn)行。

? ? ⑤解釋型語(yǔ)言也可以保證高度的安全性—這是互聯(lián)網(wǎng)應(yīng)用迫切需要的。

? ? 解釋型語(yǔ)言的缺點(diǎn)：

? ? ①運(yùn)行需要解釋環(huán)境，程序嚴(yán)重依賴平臺(tái)。

? ? ②運(yùn)行起來(lái)比編譯的要慢，占用的資源也要多一些，代碼效率低。因?yàn)椴粌H要給用戶程序分配空間，解釋器本身也占用了寶貴的系統(tǒng)資源。

? ? ③由于解釋型應(yīng)用的decode-fetch-execute（解碼-抓取-執(zhí)行）的周期，它們比編譯型程序慢很多。

*根據(jù)語(yǔ)言的結(jié)構(gòu)是否可變，編程語(yǔ)言分為動(dòng)態(tài)語(yǔ)言和靜態(tài)語(yǔ)言；

? ? 動(dòng)態(tài)語(yǔ)言：動(dòng)態(tài)類型語(yǔ)言是指在運(yùn)行期間才去做數(shù)據(jù)類型檢查的語(yǔ)言，也就是說(shuō)，在用動(dòng)態(tài)類型的語(yǔ)言編程時(shí)，永遠(yuǎn)也不用給任何變量指定數(shù)據(jù)類型，該語(yǔ)言會(huì)在你第一次賦值給變量時(shí)，在內(nèi)部將數(shù)據(jù)類型記錄下來(lái)。優(yōu)點(diǎn)在于其結(jié)構(gòu)非常規(guī)范，便于調(diào)試，方便類型安全；缺點(diǎn)是為此需要寫更多的類型相關(guān)代碼，導(dǎo)致不便于閱讀、不清晰明了；

? ? 靜態(tài)語(yǔ)言：靜態(tài)類型語(yǔ)言與動(dòng)態(tài)類型語(yǔ)言剛好相反，它的數(shù)據(jù)類型是在編譯其間檢查的，也就是說(shuō)在寫程序時(shí)要聲明所有變量的數(shù)據(jù)類型。優(yōu)點(diǎn)在于方便閱讀，不需要寫非常多的類型相關(guān)的代碼；缺點(diǎn)：自然就是不方便調(diào)試，命名不規(guī)范時(shí)會(huì)造成讀不懂，不利于理解等。（由于類型容易混淆，不容易調(diào)試任何類型可以互相賦值的造成的結(jié)果）；

? ? 腳本語(yǔ)言：又被稱為擴(kuò)建的語(yǔ)言，或者動(dòng)態(tài)語(yǔ)言，是一種編程語(yǔ)言，用來(lái)控制軟件應(yīng)用程序，腳本通常以文本保存，只在被調(diào)用時(shí)進(jìn)行解釋或編譯。腳本語(yǔ)言是一種解釋性的語(yǔ)言，它不象c/c++等可以編譯成二進(jìn)制代碼，以可執(zhí)行文件的形式存在，腳本語(yǔ)言不需要編譯，可以直接用，由解釋器來(lái)負(fù)責(zé)解釋。

? ? ? ? ??

轉(zhuǎn)載于:https://juejin.im/post/5d079112f265da1b8b2b5f2a

總結(jié)

以上是生活随笔為你收集整理的node学习篇02-模块机制的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。