給正在進WEB前端坑的小白和已經進坑的老牛們進階的完整學習資源及學習路線

前端學習路線：

1、HTML、CSS基礎、JavaScript語法基礎。學完基礎後，能夠仿照電商網站（例如京東、小米）作首頁的佈局。

2、JavaScript語法進階。包括：做用域和閉包、this和對象原型等。相信我，JS語法，永遠是面試中最重要的部分。

3、jQuery、Ajax等。jQuery沒有過期，它仍然是前端基礎的一部分。

4、ES6語法。這部分屬於JS新增的語法，面試必問。其中，關於promise、async等內容要尤爲關注。

5、HTML5和CSS3。要熟悉其中的新特性。

6、canvas。面試時，有的公司不必定會問canvas，靠運氣。若是時間不夠，這部分的內容能夠先不學。但若是你會，絕對屬於加分項。

7、移動Web開發、Bootstrap等。要注意移動開發中的適配和兼容性問題。

8、前端框架：Vue.js和React。這兩個框架至少要會一個。入門時，建議先學Vue.js，上手相對容易。但不管如何，同時掌握 Vue 和 React 纔是合格的前端同窗。

9、Node.js。屬於加分項，若是時間不夠，能夠先不學，但至少要知道 node 環境的配置。

10、自動化工具：構建工具Webpack、構建工具 gulp、CSS 預處理器 Sass 等。注意，Sass 比 Less 用得多，gulp 比 grunt 用得多。

11、前端綜合：HTTP協議、跨域通訊、安全問題（CSRF、XSS）、瀏覽器渲染機制、異步和單線程、頁面性能優化、防抖動（Debouncing）和節流閥（Throtting）、lazyload、前端錯誤監控、虛擬DOM等。

12、編輯器相關。Sublime Text是每一個學前端的人都要用到的編輯器。另外，前端常見的IDE有兩個：WebStorm 和 Visual Studio Code。WebStorm什麼都好，可就是太卡頓；VS Code就相對輕量不少。我的總結一下：新手通常用 WebStorm，入門以後，用 VS Code 的人更多。

十3、TypeScript（簡稱TS）。ES 是 JS 的標準，TS 是 JS 的超集。TS屬於進階內容，建議把上面的基礎掌握以後，再學TS。

十四,前端框架知識 vue  react angular，三選一，必需要掌握熟，其他兩個能夠了解，但取決於你面試的公司

關於學習web前端的誤區和學習建議：

1.只看教程，不動手實戰

這個能夠說是學習的最大的一忌，也是提醒過最多的一個注是事項！網上的教程有許多許多，各個語言，各個知識點，各方面的都有，javascript，html5，css3等的一些，隨便一搜就一大把，畢竟互聯網最大的優點之一就是資源共享！可是不少人看教程就只是看教程，不動手實操。即便博客的教程，視頻教程再好，本身不動手實操，寫代碼，這樣的學習方式，記憶根本不深入，容易遺忘，到頭來，可能什麼都沒學會！並且有些教程，若是沒有跟着動手實操，可能會蒙圈。

我的建議：要挑以爲適合本身的教程，也要動手實操，寫代碼。即便不是邊看教程編寫代碼！在看完了教程以後，必定要本身動手實操！過程當中，可能會遇到些問題，可是這樣纔會學習到更多，記憶也更加牢固！

2.只學框架或者庫

這個狀況，針對javascript如今沒有之前嚴重了，在之前仍是jquery傲視羣雄的時候。不少人會在聊天的時候會說：有了jquery，爲何還要學js？有了vue，爲何還要學js？面對這樣的提問，我那時候沒有回答，內心想：jquery或者vue就是用js實現的，不會js，學jquery或者vue第一學得吃力，第二學jquery或者vue確定不會很深刻。並且，萬一有時候，項目不容許用jquery或者vue，那就基本不會寫代碼了。這時候，若是學習其它的框架或者庫，基本又等於從新學一門語言了。

我的建議：先把基礎（html+css+js）打牢，再學其餘框架或者庫。雖然在會js的狀況下，我不敢說學js的框架或者庫就是查文檔，查API。但至少學js框架或者庫能夠不會那麼吃力！

3.只顧着寫代碼

這個就是我以前的一個習慣，只顧着寫代碼，不知道：耦合，實例化，繼承等專業術語，和別人交流，無限蒙圈！根本不知作別人在說什麼！互聯網的技術更新的速度很是的快，隔三差五就發佈一個框架，一個庫，一個工具。雖然不是每個更新的技術都須要學習。可是若是隻顧着寫代碼，不瞭解新的技術。這樣很容易使本身中止不前，失去競爭力。

我的建議：在寫代碼之餘，要確保本身是否是瞭解代碼，對代碼有沒有一個認識。以及多點留意消息，看下有沒有什麼技術更新！若是以爲更新的技術很實用，或者本身有興趣，能夠多瞭解下！畢竟互聯網是一個作到老，學到老的一個領域，技術更新的很快，若是跟不上流行的趨勢，說不定本身會被淘汰呢！

4.太早接觸複雜項目

這個狀況，比較廣泛，不管是在學校或者是如今的培訓機構。不少學習前端的人，基礎沒打牢，就在那裏揚言要作一個大項目，我聽到的有的人想作知乎，有的人想作世紀佳緣等等一些偉大的目標！可是所有人都是連網站的業務流程和邏輯都沒弄清，最後越搞越亂，就放棄了！以前的偉大目標都成了爛尾樓，做用最多就是一個代碼練習的做用！花了大量的時間，作了一件沒很大的實際意義的事情！

我的建議：從簡單到複雜，複雜的網站，都是有不少簡單的模塊。不妨先從簡單的功能作起，作完了一個功能再往裏面加功能！如今所處的公司就是這樣，開發的後臺管理系統，開發幾個月了，從一個只有員工的登陸註冊的功能，而後再逐一加功能，到如今項目逐漸完善！

5.好高騖遠，急於求成

這個狀況就是多見於培訓機構出來的人。我不知道是否是全部城市都是這樣，可是廣州這邊，給個人感受就是這樣。就是目標不切實際，對本身也不夠認識！以前在羣聊的時候，在金三銀四那段時間，不少人找工做，聊天的時候也遇到過不少培訓機構的人。簡歷上是各類精通，剛畢業在培訓機構培訓幾個月，要麼就是自帶兩三年工做經驗，要麼就是說本身培訓了幾個月，技術水平和市面上兩三年的人差很少。總之就是把本身吹得無所不能！可是一出題，就十問九不知。問閉包是什麼，不知道；問原型是什麼，不知道。問繼承是什麼，仍是不知道。

上面所說的，只是一個表面的現象，更重要的就是，好高騖遠這個狀況，頗有可能會致使本身難以找到工做！由於一些企業認爲最高只能給你4000工資，可是你本身卻認爲本身有實力拿到9000以上的工資。這樣狀況，很難找到工做！給人的印象也很差！更重要的是，這可能會影響本身的職業選擇！

我的建議：從實際出發，評估本身。想下本身會什麼，能給企業帶來什麼！也能夠停下別人的建議，和對比下別人的技術水平和工資，或者是上網找一些面試題，看下本身能不能完成那些面試題！最後評估下本身，認爲本身處於什麼位置！一我的學習會有迷茫，動力不足。這裏推薦一下個人前端學習交流秋秋裙600610151，裏面都是學習前端的，若是你想製做酷炫的網頁，想學習編程。本身整理了一份2019最全面前端學習資料，從最基礎的HTML+CSS+JS【炫酷特效，遊戲，插件封裝，設計模式】到移動端HTML5的項目實戰的學習資料都有整理，送給每一位前端小夥伴，有想學習web前端的，或是轉行，或是大學生，還有工做中想提高本身能力的，正在學習的小夥伴歡迎加入學習。

6.看到難點就逃避

這一點，相信不少人都有感觸，就在開發上，遇到上一個或者幾個本身以爲沒辦法實現的需求或功能。想方設法地想着逃避，好比：這個功能不是很重要，不作能夠嗎？這個功能我歷來沒弄過，搞不定的。這個功能外包給別人作吧，咱們作不了！不少一些逃避話語。你們能夠想下，若是每次都是逃避，那麼時間一久，本身技術水平是否是還停留在基礎那個階段？之後要怎麼提高本身的技術水平。

我的建議：迎難而上。在web前端開發這塊，若是趕上了難題是正常的，若是沒遇到難題就是見了鬼！面對難題，咱們應該是挑戰難題，而不是逃避！你們都想提高本身的技術水平，挑戰難題不就是一個很好的提高技術水平的實戰機會嗎？若是完成了以前認爲不可能完成的難題，這樣就是一個技術水平提高的見證！不是嗎？我也以爲，天天就寫簡單的業務代碼，不探索新知識，不挑戰難題，這樣作開發也沒多少意思！

7.能用就行

不想優化這個也是一個很常見的狀況，不少人認爲寫的代碼能用就行，能實現需求就行！根本無論往後的優化。在開發項目或者開發插件上，雖然我也是提倡:先實現，再優化這個方式！可是並不表明我開發完了就完了，不會再想優化！若是不試着去優化本身的代碼，不探索寫代碼的更好方式，之後別說編寫高質量，簡潔的代碼了，由於本身把學習編寫高質量，簡潔的代碼的一個重要途徑給封鎖了。還有一個就是，項目上，有些問題多是潛在的，就是如今看着項目沒出現什麼問題，但並不表明之後不會出現問題。反而在項目開發完了以後，試着去優化本身的代碼，探索更好的實現方式，試着編寫出高質量，簡潔的代碼。這樣難道不是一個很好的學習過程嗎？至於優化代碼的方式，不少不少（好比常說的：代碼過於重複，是否引入設計模式？網站性能通常，能否進行優化？），優化這一塊，也不是說一步就優化到最好的，而是至少不會比之前差！關於優化，我以前也發過一些資源。很容易找到，網上的資源更是不少！你們挑着看即是！

8.不懂不問和不懂馬上問

不懂不問，這個你們都知道，就是遇到問題，從不問同事或者經過其餘方式諮詢別人。就是本身在那裏苦思冥想，嘗試各類解決方案。這樣的方式，最壞的結果就是最終仍是解決不了問題，讓同事來詢問開發狀況。最好的結果問題解決了，可是解決問題所花的時間會確定不少。

不懂馬上問，這個就是詞面的意思。遇到問題立刻問別人。本身沒怎麼思考或者根本不思考。這樣能解決問題，可是這樣會致使本身可能會頻繁的問同事，會搞得同事很不耐煩。若是把同事的耐心磨沒了，可能回答的語氣可能不會很好。這樣不只影響同事之間的關係，還會讓本身以後不敢再請教同事，有讓本身處於上面所說的不懂不問的風險。

我的建議：適時請教。遇到不懂的問題，先本身結合上下文思考下，想下之前有沒有遇到這個問題，解決不了去網上找解決方案，若是尚未解決問題，這個時候再問別人，問同事或者經過其它渠道問別人。這樣本身有了思考，解決問題的時候記憶也很深入，也不會頻繁的打擾同事！

9.不懂裝懂

這個次面上跟上面的差很少，但實際上不同！不懂裝懂就是去問別人的時候，實際上別人的講解並無徹底聽懂，多是礙於面子或者是由於很差意思打擾別人那麼久，或者擔憂打擾別人過久，因此裝做很懂。可是這樣可能忽悠得了一時，很快又會露出馬腳。這樣會搞得隔一會又要去問別人一樣的問題，這樣反而會搞得別人更加尷尬，更加爲難！本身也會打擾別人更多的時間！

我的建議：若是有問題去問別人，只要你問的人不是一個很是沒有耐心的人。他都會耐心的解答你的問題！因此，當問別人問題的時候，必定要確保本身是已經弄懂了問題的原因，同事一遍沒解釋清楚，本身直接回答不明白，相信不少人都會再詳細的解釋一遍。若是擔憂同事工做忙或者其它緣由，能夠挑一個合適的時間！我如今問同事就是，要麼不問，要問就切底弄懂！固然了，個人同事都頗有耐心，每次我有什麼問題，他們都會耐心解答，甚至是擴展開來說！

10.沒理清楚需求就寫代碼

不少人在接到需求以後，第一反應就是寫代碼，即便是在本身沒把需求理清楚以前也是照樣寫代碼。另外一種狀況就是，不少人是邊寫代碼，邊想需求。這個開發方式，萬一本身對需求理解有誤！可能會致使本身寫的代碼，很大一部分都要修改，甚至是所有刪除重寫。沒理清楚需求就寫代碼這個狀況，發生的機率應該挺大的，可是通常來講很難發現這個狀況，畢竟程序員對代碼的增刪改查是再正常不過了！我自己也不知道，就是在一次的技術分享中，老大提出來的，他的建議就是對於一些稍微複雜一點的需求，先理清楚需求，簡單畫個流程圖，而後在代碼裏面，先寫上一點註釋，再開始動手寫代碼！對於這一點，我如今就是在執行當中！除非需求真的很簡單，不然我都會在草稿本上簡單畫一下流程圖。好比下面這個，這個已是我畫的流程圖裏比較簡單的一個了。根據流程圖，寫好註釋，再寫代碼，這樣會比較有條理，代碼也清晰，往後的返工也可能會有，可是不會像之前那麼多！在開發時間上，效率上，都獲得了一個提高！

最後奉獻出最新學習資源，若有想要領取請關注公衆號加我微信備註領取資料！

結尾彩蛋

歡迎關注前端之階公衆號，獲取更多前端知識，加入前端大羣，與知名互聯網大佬作朋友，開啓共同窗習新篇章！