1、如何利用node解決seo問題
NodeJS在SEO中的應用：快速採集分析頁面
一、安裝
網上有很多的教程，下載到https://nodejs.org，在Win系統下運行就可以搭上一個環境。下載Windows的Installer版本，雙擊安裝，就成功了。
然後配置神器Sublime開始使用。
為Sublime添加實時調試運行，打開Sublime-》Tools-》Build System-》New Build System
在新打開的文件中寫入下面的代碼
然後保存為NodeJS.sublime-build.
新建一個採集.js文件，設為NodeJS進行運行調試。
二、注意
在nodejs裡面需要require(庫名)的方式來引用一些外部的庫，這些外部的庫安裝NodeJS的時候，已經放在C盤的programfiles下面了。但是直接require是無效的。
因為NodeJS提倡的是自己的代碼用自己的庫，所以還需要把庫復制到採集.js這個文件下面。
引用的時候可以通過npm link 庫名的方式，來把系統C盤的庫引用到我們的項目下面。
三、直接使用了
注意require的庫必須使用npm link 庫名克隆到本地，或者自己下載包放到採集.js下面的node_moles目錄下面，如果 沒有這個目錄，自己創建。
其中：
使用Cheerio要取頁面的H1標題就簡單了
var title=$(『#article_details h1 a』).text().trim();//讀取Div下面的H1標簽文本。
有沒有jQuery強到爆的感覺。想分析頁面什麼的，還用正則嗎?不用了。還用分析嗎?不用了。找個大的Div，直接就讀出來了。C#當然也可以用Htmp Agility pack來解析Dom。
但是為此我要新建一個項目，運行，調試，用NodeJS的話，在Sublime裡面按Ctrl+B直接運行，可以馬上看到效果。而且可以放到服務端。放到我的伺服器上去。諸多好處也不大好形容。如果會點JS代碼的話，上手應該非常快。
2、2015 nodejs還會火熱嗎
這段代碼的問題是在上面兩個語句之間,在整個數據查詢的過程中,當前程序進程往往只是在等待結果的返回.這就造成了進程的阻塞.對於高並發,I/O密集行的網路應用中,一方面進程很長時間處於等待狀態,一方面為了應付新的請求不斷的增加新的進程.這樣的浪費會導致系統支持QPS遠遠小於後端數據服務能夠支撐的QPS,成為系統的瓶頸.而且這樣的系統也特別容易被慢鏈接攻擊(客戶端故意不接收或減緩接收數據,加長進程等待時間).
如何解決阻塞問題
解決這個問題的辦法是,建立一種事件機制,發起查詢請求之後,立即將進程交出,當數據返回後觸發事件,再繼續處理數據:
Js代碼
//定義如何後續數據處理函數
function onDataLoad(name){
output("name");
}
//發起數據請求,同時指定數據返回後的回調函數
db.query("select name from persons where id=1",onDataLoad);
我們看到按照這個思路解決阻塞問題,首先我們要提供一套高效的非同步事件調度機制.而主要用於處理瀏覽器端的各種交互事件的JavaScript.相對於其他語言,至少有兩個關鍵點特別適合完成這個任務.
為什麼JS適合解決阻塞問題
首先JavaScript是一種函數式編程語言,函數編程語言最重要的數學基礎是λ演算(lambda calculus) -- 即函數可以接受函數當作輸入(參數)和輸出(返回值).
函數可以作為其他函數的參數輸入的這個特性,使得為事件指定回調函數變得很容易.特別是JavaScript還支持匿名函數.通過匿名函數的輔助,之前的代碼可以進行簡寫如下.
Js代碼
db.query("select name from persons where id=1",function(name){
output(name);
});
還有一個關鍵問題是,非同步回調的運行上下文保持(稱狀態保持),我看一段代碼來說明何為狀態保持.
Js代碼
//傳統同步寫法:將查詢和結果列印抽象為一個方法
function main(){
var id = "1";
var name = db.query("select name from persons where id=" + id);
output("person id:" + id + ", name:" + name);
}
main();
前面的寫法在傳統的阻塞是編程中非常常見,但接下來進行非同步改寫時會遇到一些困擾.
Js代碼
//非同步寫法:
function main(){
var id = "1";
db.query("select name from persons where id=" + id,function(name){
output("person id:" + id + ", name:" + name);//n秒後數據返回後執行回調
});
}
main();
細心的同學可以注意到,當等待了n秒數據查詢結果返回後執行回調時.回調函數中卻仍然使用了main函數的局部變數"id",而"id"已經在n秒前走出了其作用域,這是為什麼呢?熟悉JavaScript的同學會淡然告訴您:"這是閉包(closures)~".
其實在復雜的應用中,我們一定會遇到這類場景.即在函數運行時需要訪問函數定義時的上下文數據(注意:一定要區分函數定義時和函數運行時這樣的字眼和其代表的意義,不然很快就會糊塗).而在非同步編程中,函數的定義和運行又分處不同的時間段,那麼保持上下文的問題變得更加突出了.
在這個例子中,db.query作為一個公共的資料庫查詢方法,把"id"這個業務數據傳入給db.query,交由其保存是不太合適的.但聰明的同學們可以抽象一下,讓db.query再支持一個需要保持狀態的數據對象傳入,當數據查詢完畢後可以把這些狀態數據原封不動的回傳.如下:
Js代碼
function main(){
var id = "1";
var currentState = new Object();
currentState.person_id = id;
db.query("select name from persons where id=" + id, function(name,state){
output("person id:" + state.person_id + ", name:" + name);
},currentState);//注意currentState是db.query的第三個參數
}
main();
記住這種重要的思路,我們再看看是否還能進一步的抽象?可以的,不過接下的動作之前,我們先要了解在JavaScript中一個函數也是一個對象.一個函數實例fn除了具備可函數體的定義之外,仍然可以在這個函數對象實例之上擴展屬性,如fn.a=1;受到這個啟發我們嘗試把需要保持的狀態直接綁定到函數實例上.
Js代碼
function main(){
var id = "1";
var currentState = new Object();
currentState.person_id = id;
function onDataLoad(name){
output("person id:" + onDataLoad.state.person_id + ", name:" + name);
}
onDataLoad.state = currentState ;//為函數指定state屬性,用於保持狀態
db.query("select name from persons where id=" + id, onDataLoad);
}
我們做了什麼?生成了currentState對象,然後在函數onDataLoad定義時,將currentState綁定給onDataLoad這個函數實例.那麼在onDataLoad運行時,就可以拿到定義時的state對象了.而閉包就是內置了這個過程而已.
在每個函數運行時,都有一個運行時對象稱為Execution context,它包含如下variable object(VO,變數對象),scope chain(作用域鏈)和thisValue三部分.詳見ECMA-262 JavaScript. The Core
其中變數對象VO,包含了所有局部變數的引用.對於main函數,局部變數"id"存儲在VO.id內.看起來用VO來代替我們的currentSate最合適了.但main函數還可能嵌套在其他函數之內,所以我們需要ScopeChain,它是一個包含當前運行函數VO和其所有父函數scope的數組.
所以在這個例子中,在onDataLoad函數定義時,就為默認為其綁定了一個[[scope]]屬性指向其父函數的ExecutionContext的ScopeChain.而當函數onDataLoad執行時,就可以通過[[scope]]屬性來訪問父函數的VO對象來找到id,如果父函數的VO中沒有id這個屬性,就再繼續向上查找其祖先的VO對象,直到找到id這個屬性或到達最外層返回undefined.也正是因為這個引用,造成VO的引用計數不為0,在走出作用域時,才不會被垃圾回收.
很多人覺得閉包很難理解,其實我們只要能明確需要區分函數定義和函數運行這兩個時機,記住閉包讓函數在運行時能夠訪問到函數定義時的所處作用域內的所有變數.或者說函數定義時能訪問到什麼變數,那麼在函數運行時通過相同的變數名一樣能訪問到.
關於狀態保持是本文的重點,在我看到的多數NodeJS的介紹文章,並沒有詳解這里,我們只是知道了要解決阻塞問題,但是JavaScript解決阻塞問題的優勢在哪裡,作為一個前端開發,我想有必要詳細解釋一下.
其實說到狀態保持還有一個類似的場景,比如用戶從A頁面提交表單到B頁面,如果提交數據校驗不通過,則需要返回A頁面,同時保持用戶在A頁面填寫的內容並提示用戶修改不對的地方.從提交到返回顯示這也是一個包含網路交互的非同步過程.傳統網頁,用戶的狀態通過請求傳遞到服務端,交由後端狀態保持(類似交給db.query的currentSate).而使用Ajax的網頁,因為並未離開原頁面,那麼服務端只要負責校驗用戶提交的數據是否正確即可,發送錯誤,返回錯誤處相關信息即可,這就是所謂前端狀態保持.可以看到這個場景里邊服務端做的事情變少了,變純粹了.正如我們的例子中db.query不再存儲轉發第三個state參數,變得更輕量.
我們看到通過JavaScript函數式語言特性,匿名函數支持和閉包很漂亮的解決了同步編程到非同步編程轉化過程中遇到的一系列最重要的問題.但JavaScript是否就是最好的?這就要回答我們引用新技術時需要考慮的最後一個問題了
使用NodeJS是否帶來額外的困擾,如何解決
性能真的是最好么?不用比較我們也可以得到結論NodeJS,做無阻塞編程性能較難做到極致.何為極致,處理一個請求需要佔用多少內存,多少cpu資源,多少帶寬,如果有浪費就不是極致.阻塞式編程浪費了大量進程資源只是在等待,導致大量內存和cpu的浪費.NodeJs好很多,但也正是因為一些閉包等JS內建機制也會導致資源的浪費,看下面的代碼
Js代碼
function main(){
var id = "1";
var str = "..."; //這里存儲一個2M的字元串
db.query("select name from persons where id=" + id,function(name){
output("person id:" + id + ", name:" + name);//n秒後數據返回後執行回調
});
}
main();
直到數據查詢完成,變數str所使用的2M內存不會被釋放,而str保持下去可能並沒有意義.前面已經解釋過閉包的原理,閉包並沒有智能到只包起來今後可能被訪問到的對象.即使不了解閉包的原理,也可以通過一段簡單腳本驗證這點:
Js代碼
function main(){
var id = "1";
var str = "..."; //這里存儲一個2M的字元串
window.setTimeout(function(){
debugger; //我們在這里設置斷點
},10000)
}
main();
我們在回調函數當中只設置一個斷點,並不指明我們要訪問哪個變數.然後我們在控制台監視一下,id和str都是可以拿到的.(此處結論不嚴謹，各種新瀏覽器已經就此做了相關優化，詳見評論2樓，特別是2樓給出的詳細測試報告的連接)
所以我來不負責任的預測一下,性能極端苛刻的場景,無阻塞是未來,但無阻塞發展下去,或者有更輕量的腳本引擎產生(lua?),或者V8JS引擎可能要調整可以disable閉包,或者我們可以通過給JS開發靜態編譯器在代碼發布前優化我們的代碼.
我之前談到過JS靜態編譯器:"如果給JS代碼發布正式使用前增加一個編譯步驟,我們能做些什麼",動態語言的實時編譯系統只完成了靜態語言編譯中的將代碼轉化為位元組碼的過程,而靜態語言編譯器的額外工作,如介面校驗,全局性能優化等待.所以JS也需要一個靜態的編譯器來完成這些功能,Google利用ClouserComplier提供了系列編譯指令,讓JS更好的實現OO編程,我來利用靜態編譯器解決一些JS做細粒度模塊化引入的性能方面的問題.而老趙最近的項目JSCEX,則也是利用JS發布前的編譯環節重點解決非同步編程的代碼復雜度問題.
我們習慣於阻塞式編程的寫法,切換到非同步模式編程,往往對於太多多層次的callback嵌套弄得不知所措.所以老趙開發的JS靜態編譯器,借鑒F#的Computation Expressions,讓大家遵守一些小的約定後,能夠仍然保持同步編程的寫法,寫完的代碼通過JSCEX編譯為非同步回調式的代碼再交給JS引擎執行.
如果這個項目足夠好用,那就也解決了一個使用NodeJS這種新技術,卻加大編程復雜度這個額外引入的困擾.甚至可以沿著這個思路,在靜態編譯階段優化內存使用.
NodeJS還要解決什麼問題
說了這么多,無阻塞編程要做的還遠不止這些.首先需要一個高效的JS引擎,高效的事件池和線程池.另外幾乎所有和NodeJS交互的傳統模塊如文件系統,數據訪問,HTTP解析,DNS解析都是阻塞式的,都需要額外改造.
正是NodeJS作者極其團隊,認清問題問題以及JS解決這些問題方面的優勢.基於高效的V8 JavaScript引擎,貢獻了大量的智慧和精力解決上述大部分問題後才有NodeJS橫空出世.
當前Node社區如此火熱,千餘開源的NodeJS模塊,活躍在WebFramework,WebSocket,RPC,模板引擎,數據抓取服務,圖形圖像幾乎所有工程領域.
3、為什麼前端精通Node.Js的人這么少
1.nodejs比較新，09年才發布距今不到10年，跟JAVA、C++這些老前輩沒法比；
2.更新比較頻繁, 因為新所以要經常改，改動有多頻繁？看人家更新日誌感受下（node/ChangeLog at master · joyent/node · GitHub），因而對應的第三方模塊改動也大，用過expres3.X跟4.X的同學都懂的。
3.戰線比較長，戰鬥力自然分散，就像html5的 hybrid app 三端通吃，結果每一端都被原生碾壓。前後端通吃的人，精力自然分散；哪能像單攻一端那麼強？
4.nodejs目前定位比較尷尬，高不成低不就，大項目穩定性、安全性被質疑，小項目還是沒人家PHP 各種CMS來得快。隨著更新完善，這點以後必定會有所好轉。
5.同行的嘲諷；我們行業總有那麼一群人，對新、舊技術（c# html5 nodejs）了解皮毛後，發現其缺點然後無限放大在各種社區發帖黑之。雖然無法理解 這種 損人不利己的行為，但其對技術的發展阻礙作用還是很明顯的。
PS：第4、5點導致nodejs開發領域，進來的新人多不了，自然就鮮少精通的牛人。
6.nodejs在技術層面上精通有一定難度，一方面前面有知友說了 nodejs後台需要有後端思維才能玩的轉，另一方面nodejs後台一些高階實現就是調用C++代碼模塊，對於大部分沒後台開發經驗的前端同仁要精通又得多一道坎。
4、nodejs是能寫前端嗎
nodejs生來就是為了前端項目服務的，提供了一個平台，可以快速開發網頁項目：如下摘抄的解釋：
基於：NodeJS 提供了一個﹝讓熟悉 JavaScript 的人可以快速上手並可進行後台系統開發﹞的環境/平台，這樣的設定。
Short answer: 是的
Long answer:
對於現在的前端來說，尤其是多以 JavaScript 為主做 web app 而不是傳統的以 HTML+CSS 為主的網站頁面的前端來說，本身業務需求就需要對 JavaScript 有比較深入的理解和認識。
基於此，其對於 NodeJS 的基本概念應該是已經有一定的了解了的。
其次，作為前端自動化（如項目初始化、「編譯」、測試等）的要求，需要一定程度上了解 Node，尤其是那些可編程式的工具，如Yeoman、Bower、GruntJS、GulpJS、Protractor等。
還有，作為 full stack engineering 的一種，NodeJS 只要求JS，所以使用 Node 可以讓專業的前端（除了前端專業性的基本功，至少還要了解演算法和數據結構等程序設計基礎的），能夠快速轉型成全棧開發。
同時，對於以 JS 為主要開發語言並且有比較深入了解的前端來說，學習 NodeJS 難度並不高，event-driven 應該是本就熟悉的，stream 也類似，其它如閉包、Promise、模塊化等更是如此；而關於網路、文件系統、進程等的概念理解和相關操作，對於計算機、電子、網路等相關專業出身的人來說，應該是已經有基本認識的，有此類背景的前端上手也會很快，而沒有此類背景的，也建議去學習了解一下，畢竟屬於計算機學科基礎知識。
綜上所述，不管是說為了前端自動化，還是前端開發人員為主的全棧式開發，又或者是擴展前端人員知識廣度，都是應該有一定 NodeJS 基礎的。
5、如何使用nodejs做爬蟲程序
作者：Mike Chen
鏈接：https://www.hu.com/question/31679802/answer/128390326
來源：知乎
著作權歸作者所有，轉載請聯系作者獲得授權。
首先樓主要使用nodejs作為語言或者平台來開發爬蟲是沒有任何問題的，反而nodejs的event io能夠讓你感覺到網路編程可以如此酣暢淋漓，一如http://nodejs.org 官網給出的http server 的例子，幾行代碼就能實現web服務，沒有apache 沒有tomcat也沒有iis，只要設置一個回調，監聽一個埠，你就可以使用瀏覽器訪問了。
其次，爬蟲是最明顯的IO密集型應用場景，顯然和擅長處理IO的nodejs是絕配，但是把它用好是需要一些功底的。如果你想要從頭開發，不藉助第三方框架，那麼你需要對nodejs中的event emitter 及 http 模塊有深入的了解，加上你的HTTP協議的知識，再到node平台中找到相應的實現方案，從而實現你要的功能。舉個例子，使用http模塊發送一個GET請求到百度，你需要弄清楚對req，也就是http.get的返回值，監聽什麼樣的事件，http的頭部信息和正文信息分別應該在什麼階段獲取。在python中方法很直白，簡簡單單的用urllib來open一個鏈接，接著read就算完事兒，寫到這里突然感覺可以理解之前那位仁兄認為的"不適合"，也許是覺得node 不如python的直白，又或許只是對node的理解不夠到位，不好拿捏？
最後，如果樓主想要把node作為平台來開發爬蟲，我建議直接從開源框架入手，立刻做出一些可用的程序來給自己一些正反饋，然後再慢慢學習體會。
6、對於一個有js基礎的人來說，nodejs難還是php難？
如果你之前寫js經常使用回調來回調去的函數式編程方法，那麼nodejs對你來說比較簡單，否則php就比較簡單。
7、nodejs對linux系統配置要求高么
檢查硬體支持，在安裝Linux之前，先確定你的計算機的硬體是否能被Linux所支持。首先，Linux目前支持幾乎所有的處理器（CPU）。
其次，早期的Linux只支持數量很少的顯卡、音效卡，而如今，如果要安裝Linux，已經不需要再為硬體是否能被Linux支持擔心了。
2、經過十多年的發展，Linux內核不斷完善，已經能夠支持大部分的主流硬體，同時各大硬體廠商也意識到了Linux操作系統對其產品線的重要性，紛紛針對Linux推出了驅動程序和補丁，使得Linux在硬體驅動上獲得了更廣泛的支持。
註：
如果你的音效卡、顯卡是非常新的型號，Linux內核暫時無法支持，那也不要緊，RedHat會自動把無法准確識別的硬體模擬成標准硬體來使用，讓硬體一樣可以在Linux發揮作用。由於設計Linux時的初衷之一就是用較低的系統配置提供高效率的系統服務，所以安裝Linux並沒有嚴格的系統配置要求，只要Pentium以上的CPU、64MB以上的內存、1GB左右的硬碟空間，就能安裝基本的Linux系統並且能運行各種系統服務。但是如果要順暢地運行X-Window，就需要有足夠的內存，建議128MB以上。
8、nodejs怎麼體現雲計算
nodejs是基於js預言的閉包來實現的非阻塞式方式，提高內存的使用效率，增大吞吐量。運行環境是谷歌的V8編譯器，提高了js的執行效率。
雲技術是基於大數據服務端存儲的技術。技術要點中就有高並發及對硬體的使用效率，而nodejs在這兩個方面都有不俗表現。
希望我的解釋對你有幫助。
9、如何在nodejs 中前端js調用後台的對象
前端通常作為模板，後端負責數據。
前後端合作的主要目的，就是把後端產生的數據丟到前端的模板中。通常這一步有兩種方式：
1. 前端的模板交給後端處理，直接寫到後端邏輯中，或者通過 MVC 框架整合成後端的相對獨立的部分；
2. 後端的數據通過 API 的方式交給前端處理，通過 Ajax 等方式傳輸數據。
（當然，也有兩種方式混合處理的）
如果採用了後端處理模板的方式，那前端開發完靜態模板後，需要交給後端開發人員進行模板的整合。這一步要求前端代碼整潔易讀，而且後端必須熟悉各種前端知識和調試技術。最後需要前端對後端處理過的頁面進行檢驗和調試。（這種方式對溝通要求很高，如果兩個人不坐在一起，那合作起來非常麻煩。出現問題或者需要升級時，往往很難定位誰的錯，誰去改。所以最好兩個人坐在一起開發，甚至一個人負責前後端）
如果採用前端處理數據，Ajax 等方式通信的話，前後端只要商量好所需的 API，然後持續交付一個個 API 就好了。前後端完全不需要了解，技術沒有限制，也不需要知道彼此的代碼和實現。
兩種方式如何選擇？
1. 如果前端頁面主要做內容展示，需要後端處理的內容比較多，而前端邏輯簡單時，建議採用後端 MVC。如博客、新聞類的網站；
2. 如果前端頁面的交互和數據處理較多，可以將邏輯放在前端，而後端只負責數據存取。比如各類管理後台。
10、express對於nodejs來說重要嗎
看具體項目，如果你對node熟悉的話express就不是很重要了，但是express是封裝了很多nodejs的api供使用者使用，他是一個不錯的框架，同類的還有koa