整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
者 | 六小登登
責編 | 屠敏
從 2013 年專科畢業開始，一路跌跌撞撞走了很多彎路，做過餐廳服務員，進過工廠干過流水線，做過客服，干過電話銷售可以說經歷相當的“豐富”。
最后的機緣巧合下，走上了前端開發之路，作為一個非計算機專業且低學歷的人來說，自學編程其實不是件容易的事情，不過慶幸的是自己堅持下來了。
目前工作還算不錯，收入在目前所在的城市不算高，不算低，生活也還過得去，繼續加油努力，也希望自己在今后更上一層。
從 2016 年下半年開始，我真正接觸前端，到現在 2 年多的時間。開始之初，我沒有任何的語言基礎，完全從零的小白開始，就連「對象」我都弄不明白，更別說那些高深莫測的什么封裝、繼承、多態等。
當時自己也不知從何入手，怎么辦呢？于是每當自己遇到困難時，就厚著臉皮去請教前輩大牛，然后就是去查閱資料，很多時候自己也很覺得不好意思，現在才發現人很多時候都恥于相別人請教，怕自己丟面子。
但作為一個過來人，我要告訴你請教前輩大牛真的很重要，可以讓你少走很多的彎路，不要怕丟人，沒面子，面子值幾個錢？學到真本事才最重要。沒有技能才叫真的沒有面子。當然了我們在請教別人時，一定要掌握「度」，不要打擾到了別人的工作。
我現在非常感謝前輩們的賜教，也感謝那些在網上寫博客、文章分享的大牛們，給了我們這些自學的小白很多的資料，經驗，心得。從中受益很多。
向優秀的前輩們學習，我開始寫博客，希望也能幫到和我一樣，學渣、從零開始、喜歡技術的一群志同道合的人。
我深知自己的技術并不高，還處在繼續學習的路上，離大牛還差的很遠，我本身也非常敬畏技術，也知道自己的渺小，只希望這篇文章的「學習之路」對于那些「從零開始」學習前端的同學有一些指引作用，不像自己一開始那樣的那么盲目，哪怕對你有一點點的幫助，就足夠了。
說了這么多，下面我們直接進入正題，都是我平時學習和收集的一些資料希望能夠幫到你。
前言
工具篇
工欲善其事，必先利其器，所以在開始之前選擇一個合適好用的編輯器是很重要的，工具不再多，在于好用就行，除了編輯器，我們也要掌握其他的一些工具，才能夠讓我們在學習的道路上更加的順暢。
1. WebStorm
不必多說，前端最強大的編輯器，特別是那無敵的智能提示，但是它的缺點在于如果項目多于大時，出現的卡頓讓很多人苦惱。
2. Visual Studio Code
微軟開源免費產品，受到非常多技術人員的喜愛，基本上成為前端開發者的必備編輯器，強大的插件擴展，可以靈活的打造自己喜歡的風格。給你們送上常用插件列表拿走不謝。
3. atom
也是一款免費開源的編輯器，受到很多人的喜愛，但是我本人用的較少，所以插件方面就不推薦了，大家可以按照自己的愛好去尋找。
4. 科學上網
每個程序員都應該具備的工具和能力，否則很多事情都無法辦到，至于怎么做，你可以自己查閱資料，這里不就不在多說了。而且下面推薦的很多資源都是需要科學上網之后才能訪問，所以一定要學會。
5. Google
在使用「Google」之前必須學會科學上網，不然無法訪問，學會使用搜索可以幫助我們解決很多問題，一個人的知識是有限的，掌握了搜索的技巧才能以不變應萬變，很多時候百度出來的東西重復性很大，最重要的是垃圾信息很多，在百度找不到的答案，在這里很容易找到，Google 是我的必備搜索。
6. Github
全球最大的「同性」開源交流社區，沒有賬號的趕緊注冊，在這有很多優秀的資源項目，各種大神。觀摩優秀代碼是我們學習的很好路徑。另外在開發過程中，很多時候任務重、時間緊，應該避免重復造輪子，這里能夠找到你需要的工具或代碼。
7. Stack Overflow
國外著名的技術問答交流社區，開發時碰到的很多問題在這里都能找到答案。
8. SegmentFault
對應的國內版的技術問答交流社區，如果你英文不好，也可以在這里找找答案。
9. Markdown
Markdown 輕量級標記語言，簡潔的語法，讓作者專注內容而非復雜的格式要求，我認為人人都應該掌握，特別是經常寫博客的人。想想你在用 world 時的場景，每次寫完文章之后，不得不話費很多時間進行格式的排版，使用它你就可以避免這些煩惱。
HTML 篇
一些準備就緒之后，開始我們的學習之旅，首先我們先從 HTML 開始。
HTML名為「超文本標記語言」，是整個頁面的結構基礎，它承載了我們的頁面內容。
1. 基礎
2. 進階
CSS 篇
HTML 承載了頁面的內容，但是有時候會略顯單調與「丑陋」，CSS 的作用就是為這些內容加上樣式，就像一個美女也要有漂亮的外衣去修飾才會更加漂亮，「人靠衣裝馬靠鞍」，網頁的內容也是需要穿上一件漂亮的外衣去吸引用戶。而 CSS 則完成了這個裝飾。
1. 基礎
2. 進階
書籍：
《CSS揭秘》（https://book.douban.com/subject/26745943/）：非常推薦的一本 CSS 書籍，可以學到很多鮮為人知的技巧。
在線系列：
知識點：
JavaScript 篇
有了 HTML 與 CSS，網頁也就有了內容和樣式，但是會缺少與用戶的互動，所有的內容都靜靜的躺在那里死氣沉沉。就好比一個美女穿著漂亮的衣服在你面前一動不動好像也沒有什么吸引力，但如果又唱歌，又跳舞，還向你拋媚眼，那可真就把持不住了。JavaScript 就是給網頁添加這樣的「行為」。
Javascript 簡史（https://blog.csdn.net/qq_32135281/article/details/81667714）：可以簡單了解下，JavaScript 發展由來。
1. 基礎
書籍
在線系列
除了書籍之外，也有很多優秀的在線教程，可以幫助我們更好的學習。
2. 進階
TypeScript篇
ES6 的超集擴展，嚴格的數據類型，帶來更好的維護，適合大型項目的開發工作，有人說它是未來的發展趨勢，你說要不要了解？
Jquery篇
雖說現在已經是單頁面應用時代，有React，Vue 這種強大的框架可以使用，但也不缺乏一些老的項目需要維護，而且在學習之初，可以用它做兩個簡單的應用還是不錯的，可以相對了解下基本用法，它可以讓你更好，更方便的操作DOM。但不建議再深度學習。
Ajax篇
掌握了的HTML、CSS、JavaScript時，這時候可以嘗試自己做一些項目了，而項目中肯定會有數據的交互，這時候就是 Ajax 的用武之地了。
NodeJS與模塊化
NodeJs 的出現讓前端發展進入了一個新的領域，并且滋生出專業的 Node 工程師，不僅如此 Node 在前端模塊化，工程化起到很重要的作用，所以了解是必須的，如果感興趣的可以深入學習，可以向全棧工程師發展。
框架篇
隨著日益復雜的用戶需求，與系統的復雜度上升，傳統的開發模式日漸的很難滿足，此時的三大框架孕育而生，讓開發者更加高效，可復用，把關注點都放在數據層的操作，免去那些繁瑣而又重復的視圖操作。
現在框架的能力已經是前端開發人員必備的技能之一也是趨勢，三大框架的「最終目的」都是一致的，我認為開發者不必糾結于到底應該選擇哪一個學習，可以選擇其中的兩個是最好的。對于剛入門的人來說，建議選擇 Vue 入手，比較簡單，靈活。
1. Angular
2. Vue
3. React
React我了解不多，所以就沒什么好推薦的了，大家可自行學習。
圖形可視化
隨著日益增長的數據，如何利用高效的利用數據，是每個企業都考慮的問題，而人的眼睛看到的東西要勝過閱讀的問題，俗話說「一圖勝千言」就是這個道理，所以數據的可視化就會格外的重要，以下都是我常看的一些技術，書籍，和關注的可視化開源庫。
工程化與版本控制篇
1. Git
版本控制工具，很多新手往往把 git 與 github 傻傻分不清楚，二者是不同的東西，一定要去區分清楚。
2. Gulp
自動化構建工具，項目打包部署前的壓縮合并，節省時間，提高開發效率。
3. Webpack
Webpack 是當下最熱門的前端資源模塊化管理和打包工具。它可以將許多松散的模塊按照依賴和規則打包成符合生產環境部署的前端資源。
4. Babel
JavaScript代碼編譯器，可以讓ES6及以上語法轉換成瀏覽器支持的語法，一般會在框架的腳手架中自行配置。
5. 代碼質量
瀏覽器與HTTP
性能優化
SEO
博客系列
1. 個人
現在是一個信息爆炸的時代，網上有很多優秀的博客文章，每個人的精力都是有限的，不可能關注到所有的博客，每個人關注點可能不太一樣，所以關注的個人博客也會不同，這些推薦幾個我比較常看的幾個高質量博客。而且是持續更新的。
2. 團隊
項目資源
常用工具
最后
以上是我這兩年多一路走來收藏的一些資料，整理這份資料也花了我好幾天的時間，希望能夠在自學的道路上幫到你。
再次聲明，我并不是什么大神，我自認為技術也沒有到達這個層級，但是我會一直堅持學下去，另外一定不要誤會這里面的知識我全部都會，這些都是我學習的一些資料想整理出來，免去小白的一些不知道如何查閱資料。
這里的資源可能并不適合每一個人，你也不一定全部都需要，只需要挑選自己想要的部分就行，任何事情并不是越多越好。
作者：六小登登，個人公眾號：六小登登（ID：liuxiaodengdeng）。目前在某創業公司任職前端開發工作，近 3 年前端開發經驗，愛技術、愛寫作、愛分享。
聲明：本文為作者投稿，版權歸其個人所有。
一個非專業人士看3D圖紙有多難？比如打開一個30M的3D圖紙：
但是如果換做用網頁看三維，不管你手機多老舊，不論你電腦配置多平常，也不論你是否專業人員，一個鏈接或者一個超鏈接、二維碼就能解決這些問題。選擇SView 網頁端，讓3D圖紙躍然網上，以一個鏈接的形式，自由適配你的手機和電腦，會有這幾種形式：
鏈接
https://sview.sv3d.cn/model/preview/0a7e37de-1c33-4b32-aed8-72c36584799b
超鏈接
點擊圖片跳轉預覽
二維碼
長按識別二維碼
網站嵌入
<script src="https://lf6-cdn-tos.bytescm.com/obj/cdn-static-resource/tt_player/tt.player.js?v=20160723"></script>
為什么3D圖紙在SView網站上會這么流暢呢？
因為SView在生成3D圖紙的鏈接之前會先對3D圖紙做高性能輕量化轉換，讓圖紙的大小能夠適配手機，以H5的形式在網頁上瀏覽。這種形式擴大了圖紙的復用性以及應用范圍的廣度，出現了多樣化的應用場景。比如：
在電商平臺、產品官網，用產品的3D圖紙代替傳統的文字、圖片、視頻、動畫介紹講解。通過網頁嵌入或者超鏈接跳轉到產品的三維結構圖，讓瀏覽者更清晰更全面了解產品的特質、結構、屬性。用科技感十足的宣傳手段，提升客戶對企業實力的認可。
可以擺脫圖文表達在直觀性和互動性上的不足，銷售人員在拜訪客戶時直接打開手機或者網頁，就能立體生動的向客戶進行產品介紹，讓銷售工作事半功倍；介紹產品只提供二維碼、鏈接就可以讓客戶全面了解產品。
3D產品手冊，操作簡單，使用方便，360°全三維展示、不同視圖展示、結構爆炸圖展示、裝配樹展示、零部件拖拽和旋轉。
把傳統機械制圖教材中的平面三維教學內容，用SView展示出來。拿起移動設備掃一掃，在移動設備中呈現三維圖紙的3D立體化效果。學生可對設備中的3D模型做剖切、放大、縮小、爆炸、裝配等等自由操作，全方位立體化識得每一個模型結構和特質。
SView利用HTML5技術及三維大數模的輕量化技術，實現在網頁端的三維模型預覽，同時適配手機及網頁瀏覽，想了解更多SView三維產品知識或者想應用到更廣泛的場景中，請聯系我們。
更多SView產品體驗下載地址：
https://sview.sv3d.cn/tool
SView產品激活地址：
https://service.sv3d.cn/web/licence/applypage
使用由Angular，React，Vue等應用程序框架構建的客戶端應用程序時，您總是會處理HTML5客戶端路由，它將完全在瀏覽器中處理到頁面和組件的客戶端路由。幾乎完全在瀏覽器中...
HTML5客戶端路由在客戶端上工作的很好，但是當深入鏈接到一個站點或在瀏覽器中按刷新時，客戶端路由有一個惡習，變成服務器HTTP請求。請求可能未配置服務器的路由。
在這篇文章中，我將討論如何使ASP.NET Core（或間接ASP.NET應用程序）通過有效地將客戶端應用程序重新連接到其路由來處理這些“假”請求。
Html 5客戶端路由？
如果您不知道HTML5客戶端路由是什么，請快速回顧一下。
客戶端框架實現他們自己的客戶端路由機制，以便他們可以 - 就像服務器應用程序 - 在頁面或組件之間進行導航。
Angular支持幾種路由類型：
哈希路線（http：// localhost：4200 /＃！/ albums或http：// localhost：4200 /＃/ albums）
HTML 5路線（http：// localhost：4200 / albums）
#!/ 哈希邦德路線
前者是一種較早的方法，它直接與HTTP語義一起工作，指定任何具有a的URL #在客戶端被觸發并跳轉到頁面內的“本地”URL。框架可以攔截導航并檢查跟隨的URL內容#以確定路線。散列爆炸#!\用于區分應用程序URL和普通#錨鏈接。
散列爆炸路線的好處是，他們只是工作。沒有服務器端出血的路線，如果您書簽或刷新客戶端頁面，它只是如預期的那樣工作，因為散列邏輯是作為瀏覽器中本地URL解析的一部分執行的。很簡單，對吧？它只是工作。
但缺點是，如果您必須手動輸入網址，則這些網址非常難看且不直觀。對于散列爆炸路線來說，這并不是一個很好的論據，但是不管它們是否對HTML5路由不利。
哈希在Angular中的Bang路由
Angular使用默認的HTML5客戶端路由，但它是一個簡單的開關來啟用Hashbang路由，而不是HTML5路由::
// in app.module.tsproviders : [
..
// make sure you use this for Hash Urls rather than HTML 5 routing
{ provide: LocationStrategy, useClass: HashLocationStrategy },] 只要您routerLink在HTML模板中使用鏈接網址，并router.navigate()在代碼鏈接中使用，Angular交換機就會自動在兩種模式之間進行切換。
在HTML中使用<a routerLink="/albums" />鏈接
在代碼中使用： router.navigate(["/album",album.id])
HTML5路由
HTML5路由使用更復雜的方法 - 它使用HTML5的Pushstate API來控制客戶端的路由并管理地址欄顯示。
這種方法的優點是，使用HTML5 API相對容易操作，并且使用標準的無延伸路由約定，使用Web應用程序和API時，URL更加簡潔，易于控制。
但是HTML5路由需要服務器的明確支持來正確理解哪些路由是服務器路由，哪些是客戶路由。
沒有服務器處理的HTML5路由問題
問題在于HTML5客戶端路由與服務器路由無法區分。
http://localhost:4200/albums可以很容易地將客戶端URL作為服務器端URL。在完全在客戶端上導航時，HTML5路線工作正常 - 應用程序可以攔截導航并在激活特定路線時路由到相應的客戶端頁面。
如果您使用深層鏈接導航到客戶端驅動的應用程序，然后您將該頁面書簽為書簽，然后使用該URL導航回到該頁面，或者刷新當前活動頁面，則會彈出問題。在這兩種情況下，當瀏覽器請求路由時，客戶端應用程序不運行，因此瀏覽器向服務器請求路由URL。但是，默認情況下不設置處理說/albums路線，所以你會得到一個錯誤。
如果您在ASP.NET Core應用程序中沒有對HTML5路由設置進行任何特殊處理，您將在應用程序中打開錯誤頁面，或者從Kestrel中選擇此默認顯示：
圖1 - 未處理的客戶端路由產生服務器錯誤
修復服務器上的客戶端路由
那么你如何解決這個問題呢？
客戶端SPA應用程序通常有一個或幾個啟動應用程序的靜態頁面。對于一個典型的Angular應用程序，該頁面是index.html啟動應用程序并啟動客戶端路由。大多數框架都足夠聰明，可以在啟動時檢查當前路由，并移至首次訪問請求的路由。
如果客戶端路由從書簽，鏈接或完全刷新被觸發到服務器，則需要提供index.html并保持原始URL不變。
然后，客戶端應用程序將自行引導，并且內部路由啟動，以希望將您甩回書簽/刷新位置。
從服務器提供Index.html
為了這個工作，你需要確保服務器只提供服務器負責的內容。
有幾種方法可以做到這一點：
主機服務器URL重寫
處理ASP.NET Core應用程序中的客戶端路由
主機Web服務器上的URL重寫
如果您在主流Web服務器上運行ASP.NET Core（或ASP.NET）應用程序，最簡單且最有效的解決方案是重寫客戶端URL并為index.html給定的URL 提供內容。
在IIS上，您可以使用IIS重寫模塊來執行此操作。我最近在一篇博文中更詳細地介紹了這一點：
ASP.NET核心應用程序的IIS重寫規則
但是這里是相關的IIS重寫規則：
<rewrite>
<rules>
<!--
Make sure you have a <base href="/" /> tag to fix the root path
or all relative links will break on rewrite
-->
<rule name="AngularJS-Html5-Routes" stopProcessing="true">
<match url=".*" />
<conditions logicalGrouping="MatchAll">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
<add input="{REQUEST_URI}" pattern="api/" negate="true" />
</conditions>
<action type="Rewrite" url="wwwroot/index.html" />
</rule>
</rules></rewrite>您可以從以下任何位置安裝UrlRewrite模塊：
Microsoft下載網站
choco install urlrewrite
Web平臺安裝程序
如果你在Linux上運行Docker和nginX或者Apache，那么類似的Rewrite選項就可以在那里使用。
讓ASP.NET Core處理客戶端路由
如前所述，我通常使用像IIS或nginX這樣的前端Web服務器來處理重定向，但是通常在測試或內部應用程序時，只需要Kestrel直接為應用程序提供服務即可。如果您直接讓Kestrel處理HTTP流量，那么您需要在ASP.NET Core代碼中處理客戶端路由。
捕獲所有app.Run()處理程序
有很多方法可用，但是我發現了在Startup類的Configure()方法中使用一個非常簡單的后備處理程序來處理客戶端路由的最簡單的方法：
// set up whatever routes you use with UseMvc()// you may not need to set up any routes here// if you only use attribute routes!app.UseMvc(routes =>{
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");});//handle client side routesapp.Run( async (context) =>{
context.Response.ContentType = "text/html";
await context.Response.SendFileAsync(Path.Combine(env.WebRootPath,"index.html"));});關鍵是app.Run()位于路由后的管道末端的中間件處理程序。如果服務器端路由不能找到匹配的路由，這個通用處理程序就會啟動。
上面的代碼是你可以做的最簡單的事情，只是把內容發送index.html到客戶端。如果您有多個靜態頁面和SPA筒倉，您可以在其中添加額外的邏輯來嘗試確定需要加載哪個頁面。
請注意，內容不會重定向到，而是作為內嵌流發送到現有的URL請求，以便用戶請求的URL保持不變。這確保了當用戶請求http://localhost:4200/albums你回到那個客戶端頁面而不是index.html。
捕獲所有路由處理程序
另一種方法是在路由定義中使用最后定義的全部捕獲的 MVC路由處理程序。這基本上拿起你的MVC路由配置無法處理的任何URL，然后路由到你指定的路線。
使用catch-all處理程序設置您的MVC路線，將此代碼放在您的Startup類的Configure()方法中：
app.UseMvc(routes =>{
// default routes plus any other custom routes
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
// Catch all Route - catches anything not caught be other routes
routes.MapRoute(
name: "catch-all",
template: "{*url}",
defaults: new {controller = "AlbumViewerApi", action = "RedirectIndex"}
);});然后執行完全相同的事情中間件處理程序使用：index.html使用以下代碼將內容流式傳輸到客戶端：
// we need hosting environment for base pathpublic IHostingEnvironment HostingEnv { get; }public AlbumViewerApiController(IHostingEnvironment env){
HostingEnv = env;}[HttpGet]public IActionResult RedirectIndex(){
return new PhysicalFileResult(
Path.Combine(HostingEnv.WebRootPath,"index.html"),
new MediaTypeHeaderValue("text/html")
);}Catch-All Route不使用屬性路由
確保您為回退路線指定的路線不具有分配給它的屬性路線。當我昨天檢查出來的時候，我無法得到一條全面的路線，直到我
[Route("api/RedirectIndex")]從控制器的操作中移除 了這個全部工作。
SpaServices
SpaServices提供了另一個選項，routes.MapSpaFallbackRoute()盡管我自己也沒有嘗試過，但是如果您已經在ASP.NET Core應用程序中使用了Spa服務，那么這可能是一個簡單的方法來實現這個功能，包括潛在的支持服務器預渲染。
概要
HTML5路由為客戶端應用程序提供了干凈的URL，但它的價格必須有服務器支持才能使其工作。使用主機Web服務器中的重寫規則或直接在Kestrel的中間件管道或自定義路由處理程序中進行設置并不困難，但是您必須確保將此功能顯式添加到您創建的每個ASP.NET應用程序中。
盡管舊的Hash Bang路線看起來不那么干凈，但它們工作正常，不需要任何服務器端支持。對于需要支持古代瀏覽器的非公眾應用程序或應用程序，在沒有服務器支持的情況下，散列邦線路仍然是提供路由的可行方式。
最后，如果您正在使用完整的Web服務器，UrlRewriting是處理非ASP.NET內核后端直接處理的非API內容的最干凈和最有效的方式。
選擇是好的，你有幾個選擇提供方便，干凈的網址或簡單的只是把它放在功能。你的選擇...
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
