『壹』 前端登陸實現
四種方式
Cookie 出現的原因： HTTP 協議是無狀態的，每次請求都會建立一個新的鏈接，請求結束就會斷開鏈接，優點就是可以節省鏈接資源，缺點就是無法保存用戶狀態。Cookie 的出現就是為了解決這個問題。
Cookie 是存儲在瀏覽器中的，可以通過 Js 和 set-cookie 這個響應欄位來進行設置。
cookie 的限制：
有了 cookie 之後，服務端就可以從客戶端獲取到信息，如果需要對信息進行驗證，那麼還需要 session
服務端在收到客戶端的請求之後，會在伺服器中開辟一片內存空間來存放 session
第一次登陸之後，下次再訪問的時候就會攜帶這個 cookie，服務端就可以根據 sessionId 進行驗證用戶是否登陸（判斷這個 sessionId 和服務端保存的 sessionId 是否一致，是否有這個 sessionId 的記錄或者記錄是否有效）
客戶端瀏覽器訪問伺服器的時候，伺服器把客戶端信息以某種形式記錄在伺服器上。這就是 Session。客戶端瀏覽器再次訪問時只需要從該 Session 中查找該客戶的狀態就可以了。
Token 是 伺服器 生成的一個字元串，作為客戶端請求的一個令牌。第一次登陸之後，伺服器會生成一個 Token 返回給客戶端，客戶端後續訪問的時候，只需帶上這個 Token 進行身份認證
缺點
JWT（Json Web Token）
服務端不需要存儲 Token 那麼服務端是怎麼驗證客戶端傳遞過來的 Token 是否有效的呢？
答案：
Token 並不是雜亂無章的字元串，而是通過多種演算法拼接而成的字元串
header 部分指定了這個 Token 所使用的簽名演算法
payload 部分表明了這個 JWT 的意圖
signature 部分為 JWT 的簽名，主要是為了讓 JWT 不被隨意的篡改
簽名的部分有兩個步驟
一：
二:
最後的 Token 計算如下：
單點登陸指的是公司會搭建一個公共的認證中心，公司里的所有產品的認證都可以在這個認證中心中完成，一個產品在認證中心認證之後，再去訪問其他產品時就不需要再次認證
這個時候，由於 a.com 存在已登錄的 Cookie 信息，所以伺服器端直接認證成功。
這個時候由於認證中心存在之前登陸過的 cookie，所以不需要再輸入賬號密碼，直接從第四步開始執行
目前我們已經完成了單點登錄，在同一套認證中心的管理下，多個產品可以共享登錄態。現在我們需要考慮退出了，即：在一個產品中退出了登錄，怎麼讓其他的產品也都退出登錄？
原理也不難，其實就是在攜帶 ticket 去請求認證中心的時候，再去請求一下認證中心的退出登陸的 api 即可
當某個產品 c.com 退出登陸時
sso 就是一個集中地驗證系統。你項目內請求時，向 sso 發一個請求，他給你個 token 你扔到游覽器緩存里，請求的時候放在請求頭里帶著。和其他驗證介面一樣。 他好就好在，一個賬號在不同系統里都可以登錄，因為不同項目可以共用這個 token。並且通過 sso 集中管理一些用戶信息，你可以方便的拿用戶信息。
以微信為例子
『貳』 什麼是前端
前端又稱Web前端。前端即網站前台部分，運行在PC端，移動端等瀏覽器上展現給用戶瀏覽的網頁。前端是網頁給訪問網站的人看的內容和頁面。是為了網頁或者網頁應用，使用HTML，CSS以及JS代碼，用戶能夠看到並且和這些頁面進行交流。
前端官方的定義是前端就是網站前台部分，運行在PC端，移動端等瀏覽器上展現給用戶瀏覽的網頁。也就是前端是網頁給訪問網站的人看的內容和頁面。那前端開發顧名思義就是這些內容和頁面中代碼的實現。
前端開發的工作職責：
1、使用Div+css並結合Javascript負責產品的前端開發和頁面製作。
2、熟悉W3C標准和各主流瀏覽器在前端開發中的差異，能熟練運用DIV+CSS，提供針對不同瀏覽器的前端頁面解決方案。移動HTML5的性能和其他優化，為用戶呈現最好的界面交互體驗和最好的性能。
3、負責相關產品的需求以及前端程序的實現，提供合理的前端架構。改進和優化開發工具、開發流程、和開發框架。
4、與產品、後台開發人員保持良好溝通，能快速理解、消化各方需求，並落實為具體的開發工作；能獨立完成功能頁面的設計與代碼編寫，配合產品團隊完成功能頁面的需求調研和分析。
5、了解伺服器端的相關工作，在交互體驗、產品設計等方面有自己的見解。
『叄』 web前端實現不了頁面效果
路徑錯誤。由於web前端保存路徑錯誤，導致其沒有效果。Web前端是計算機科學開發的核心和領域，主要針對編碼和構建可見的東西，也就是用戶進行交互的界面，集中在Web應用程序或網站中。
『肆』 不懂前後端分離這篇就夠
前後端分離前我們的開發協作模式一般是這樣的：
前端寫好靜態的HTML頁面賀扮交付給後端開發。靜態頁面可以本地開發，也無需考慮業務邏輯只需要實現View即可。
後端使用模板引擎去套模板，同時內嵌一些後端提供的模板變數和一些邏輯操作。
然後前後端集成對接，遇到問題，前台返工，後台返工。
然後在集成，直至集成成功。
這種模式的問題
在前端調試的時候要安裝完整的一套後端開發工具，要把後端程序完全啟動起來。遇到問題需要後端開發來幫忙調試。我們發現前後端嚴重耦合，還要要求後端人員會一些HTML，JS等前端語言。前端頁面里還嵌入了很多後端的代碼。一旦後端換了一種語言開發，簡直就要重做。
像這種增加了大量的溝通成本，調試成本等，而且前後端的開發進度相互影響，從而大大降低了開發效率。
前後端分離並不只是開發模式，而是web應用的一種架構模式。在開發階段，前後端工程師約定好數據交互介面，實現並行開發和測試；在運行階段前後端分離模式需要對web應用進行分離部署，前後端之前使用HTTP或者其他協議進行交互請求。
1. 客戶端和服務端採用RESTFul API的交互方式進行交互
2. 前後端代碼庫分離
在傳統架構模式中，前後端代碼存放於同一個代碼庫中，甚至是同一工程目錄下。頁面中還夾雜著後端代碼。前後端工程師進行開發時，都必須把整個項目導入到開發工具中。
前後端代碼庫分離，前端代碼中有可以消蘆進行Mock測試(通過構造虛擬測試對 象以簡化測試環境的方法)的偽後端，能支持前端的獨立開發和測試。而後端代碼中除了功能實現外，還有著詳細的測試用例，以保證API的可用性，降低集成風險。
3. 並行開發
在開發期間前後端共同商定好數據介面的交互形式和數據格式。然後實現前後端的並行開發，其中前端工程師在開發完成之後可以獨自進行mock測試，而後端也可以使用Postman等介面測試軟體進行介面自測，然後前後端一起進行功能聯調並校驗格式，最終進行自動化測試。
分離後，開發模式是這樣的
為優質產品打造精益團隊
通過將開發團隊前後端分離化，讓前後端工程師只需要專注於前端或後端的開發工作，是的前後端工程師實現自治，培養其獨特的技術特性，然後構建出一個全棧式的精益開發團隊。
提升開發效率
前後端分離以後，可以實現前後端代碼的解耦，只要前後端溝通約定好應用所需介面以及介面參數，便可以開始並行開發，無需等待對方的開發工作結束。與此同時，即使需求發生變更，只要介面與數據格式不變，後端開發人員就不需要修改代碼，只要前端進行變動即可。如此一來整個應用的開發效率必然會有質的提升。
完美應對復雜多變的前端需求
如果開發團隊能完成前後端分離的轉型，打造優秀的前後端團隊，開發獨立化，讓開發人員做到專注專精，開發能力必然會有所提升，能夠完美應對各種復雜多變的前端需求。
增強代碼可維護性
前後端分離後，應用的代碼不再是前後端混合，只有在運行期才會有調用依賴關系。應用代碼將會變得整潔清晰，不論是代碼閱讀還是代碼維護都會比以前輕松。
使用了前後端分離架構後，除了開發模式的變更，我們在開發的過程中還會遇到哪些問題呢？我們接著往下看。
我們先來看看傳統開發，我們是如何進行用戶認證的
前端登錄，後端根據用戶信息生成一個jsessionid，並保存這個 jsessionid 和對應的用戶id到Session中，接著把 jsessionid 傳給用戶，存入瀏覽器 cookie，之後瀏覽器請求帶上這個cookie，後端根據這個cookie值來查詢用戶，驗證是否過期。
HTTP有一個特性：無狀態的，就是前後兩個HTTP事務它們並不知道對方的信息。而為了維護會話信息或用戶信息，一般可用Cookie和Session技術緩存信息。
- Cookie是存儲在客戶端的
- Session是存儲在服務端的
但這樣做問題就很多，拿拍帶如果我們的頁面出現了 XSS 漏洞，由於 cookie 可以被 JavaScript 讀取，XSS 漏洞會導致用戶 token 泄露，而作為後端識別用戶的標識，cookie 的泄露意味著用戶信息不再安全。盡管我們通過轉義輸出內容，使用 CDN 等可以盡量避免 XSS 注入，但誰也不能保證在大型的項目中不會出現這個問題。
在設置 cookie 的時候，其實你還可以設置 httpOnly 以及 secure 項。設置 httpOnly 後 cookie 將不能被 JS 讀取，瀏覽器會自動的把它加在請求的 header 當中，設置 secure 的話，cookie 就只允許通過 HTTPS 傳輸。secure 選項可以過濾掉一些使用 HTTP 協議的 XSS 注入，但並不能完全阻止。
httpOnly 選項使得 JS 不能讀取到 cookie，那麼 XSS 注入的問題也基本不用擔心了。但設置 httpOnly 就帶來了另一個問題，就是很容易的被 XSRF，即跨站請求偽造。當你瀏覽器開著這個頁面的時候，另一個頁面可以很容易的跨站請求這個頁面的內容。因為 cookie 默認被發了出去。
解決方案
JWT（Json Web Token）
JWT 是一個開放標准(RFC 7519)，它定義了一種用於簡潔，自包含的用於通信雙方之間以 JSON 對象的形式安全傳遞信息的方法。該信息可以被驗證和信任，因為它是數字簽名的。JWTS可以使用秘密（使用HMAC演算法）或公鑰/私鑰對使用RSA或ECDSA來簽名。
- 簡潔(Compact)：可以通過URL, POST 參數或者在 HTTP header 發送，因為數據量小，傳輸速度快。
- 自包含(Self-contained)：負載中包含了所有用戶所需要的信息，避免了多次查詢資料庫。
JWT 組成
JWT由3個子字元串組成，分別為Header，Payload以及Signature，結合JWT的格式即：Header.Payload.Signature。（Claim是描述Json的信息的一個Json，將Claim轉碼之後生成Payload）。
Header
Header是由下面這個格式的Json通過Base64編碼（編碼不是加密，是可以通過反編碼的方式獲取到這個原來的Json，所以JWT中存放的一般是不敏感的信息）生成的字元串，Header中存放的內容是說明編碼對象是一個JWT以及使用「SHA-256」的演算法進行加密（加密用於生成Signature）
- 頭部包含了兩部分，token 類型和採用的加密演算法
- Base64是一種編碼，也就是說，它是可以被翻譯回原來的樣子來的。它並不是一種加密過程。
Payload
Payload是通過Claim進行Base64轉碼之後生成的一串字元串，Claim是一個Json，Claim中存放的內容是JWT自身的標准屬性，所有的標准屬性都是可選的，可以自行添加，比如：JWT的簽發者、JWT的接收者、JWT的持續時間等；同時Claim中也可以存放一些自定義的屬性，這個自定義的屬性就是在用戶認證中用於標明用戶身份的一個屬性，比如用戶存放在資料庫中的id，為了安全起見，一般不會將用戶名及密碼這類敏感的信息存放在Claim中。將Claim通過Base64轉碼之後生成的一串字元串稱作 Payload 。
Signature
Signature是由Header和Payload組合而成，將Header和Claim這兩個Json分別使用Base64方式進行編碼，生成字元串Header和Payload，然後將Header和Payload以Header.Payload的格式組合在一起形成一個字元串，然後使用上面定義好的加密演算法和一個密匙（這個密匙存放在伺服器上，用於進行驗證）對這個字元串進行加密，形成一個新的字元串，這個字元串就是 Signature 。
簽名的目的： 最後一步簽名的過程，實際上是對頭部以及負載內容進行簽名，防止內容被竄改。如果有人對頭部以及負載的內容解碼之後進行修改，再進行編碼，最後加上之前的簽名組合形成新的JWT的話，那麼伺服器端會判斷出新的頭部和負載形成的簽名和JWT附帶上的簽名是不一樣的。如果要對新的頭部和負載進行簽名，在不知道伺服器加密時用的密鑰的話，得出來的簽名也是不一樣的。
三個部分通過.連接在一起就是我們的 JWT 了：
JWT認證
伺服器在生成一個JWT之後會將這個token發送到客戶端機器，在客戶端再次訪問受到JWT保護的資源URL鏈接的時候，伺服器會獲取到這個token信息，首先將Header進行反編碼獲取到加密的演算法，在通過存放在伺服器上的密匙對Header.Payload 這個字元串進行加密，比對token中的Signature和實際加密出來的結果是否一致，如果一致那麼說明該token是合法有效的，認證成功，否則認證失敗。
JWT使用總結
1. 首先，前端通過Web表單將自己的用戶名和密碼發送到後端的介面。這一過程一般是一個HTTP POST請求。建議的方式是通過SSL加密的傳輸（https協議），從而避免敏感信息被嗅探。
2. 後端核對用戶名和密碼成功後，將用戶的id等其他信息作為JWT Payload（負載），將其與頭部分別進行Base64編碼拼接後簽名，形成一個JWT。形成的JWT就是一個形同lll.zzz.xxx的字元串。
3. 後端將JWT字元串作為登錄成功的返回結果返回給前端。前端可以將返回的結果保存在Cookie或localStorage或sessionStorage上，退出登錄時前端刪除保存的JWT即可。
4. 前端在每次請求時將JWT放入HTTP Header中的Authorization位。(解決XSS和XSRF問題)
5. 後端檢查是否存在，如存在驗證JWT的有效性。例如，檢查簽名是否正確；檢查Token是否過期；檢查Token的接收方是否是自己（可選）。
6. 驗證通過後後端使用JWT中包含的用戶信息進行其他邏輯操作，返回相應結果。
JWT和Session方式存儲id的差異
Session方式存儲用戶id的最大弊病在於Session是存儲在伺服器端的，所以需要佔用大量伺服器內存，對於較大型應用而言可能還要保存許多的狀態。一般而言，大型應用還需要藉助一些KV資料庫和一系列緩存機制來實現Session的存儲。
而JWT方式將用戶狀態分散到了客戶端中，可以明顯減輕服務端的內存壓力。除了用戶id之外，還可以存儲其他的和用戶相關的信息，例如該用戶是否是管理員、用戶所在的分組等。雖說JWT方式讓伺服器有一些計算壓力（例如加密、編碼和解碼），但是這些壓力相比磁碟存儲而言可能就不算什麼了。
單點登錄
Session方式來存儲用戶id，一開始用戶的Session只會存儲在一台伺服器上。對於有多個子域名的站點，每個子域名至少會對應一台不同的伺服器，例如：
www.taobao.com，nv.taobao.com，nz.taobao.com，login.taobao.com。所以如果要實現在login.taobao.com登錄後，在其他的子域名下依然可以取到Session，這要求我們在多台伺服器上同步Session。使用JWT的方式則沒有這個問題的存在，因為用戶的狀態已經被傳送到了客戶端。
當客戶端和服務端分開部署到不同伺服器的時候，就會遇到跨域訪問的問題，是由瀏覽器同源策略限制的一類請求場景。
跨域解決方案有很多種，下面使用Nginx反向代理的方案
反向代理
代理訪問其實在實際應用中有很多場景，在跨域中應用的原理做法為：通過反向代理伺服器監聽同埠，同域名的訪問，不同路徑映射到不同的地址，比如，在nginx伺服器中，監聽同一個域名和埠，不同路徑轉發到客戶端和伺服器，把不同埠和域名的限制通過反向代理，來解決跨域的問題：
『伍』 前端只寫靜態頁面的工作可以做嗎
不建議！靜態頁面隨便人都可以寫 ，只畫頁面的前端是一個沒有靈魂的前端。並且，很少有公司招只寫靜態頁面的前端，現在大部分工公司都招全棧型的前端。
『陸』 網站內容後台更新，前端不顯示
有些後台，發布了文章還需要點擊【發布頁面】，網站才會顯示的。比如以下這家公司做網站就需要。
『柒』 前端全（無）埋點之頁面停留時長統計
當前頁面關閉統計方案解的思路就是阻塞頁面關閉，先發數據統計請求，然後再關閉頁面
XMLHttpRequest::open方法的第三個參數，如果設置為false就是同步載入
這樣可以阻塞頁面關閉，當然可以在readState為2的時候就abort請求，因為我們不關心響應的內容，只要請求發出去就行了。
原理跟上面類似，只不過是使用一個空的死循環阻塞頁面關閉
大部分瀏覽器都會等待圖片的載入，趁這個機會把統計數據發送出去
以上提到的幾個方案都是一個原理，讓瀏覽器繼續保持阻塞狀態，等數據發送出去後再跳轉，這里存在的問題是：
參考： 前端全（無）埋點之頁面停留時長統計
『捌』 前端開發，頁面優化，性能優化有哪些方面
感覺前端的性能確實是很重要的，我談談我在實際項目中的應用。前端的應用主要從以下幾個方面進行優化：
1．減少http請求
HTTP協議是無狀態的應用層協議，意味著每次HTTP請求都需要建立通信鏈路、進行數據傳輸，而在伺服器端，每個HTTP都需要啟動獨立的線程去處理。這些通信和服務的開銷都很昂貴，減少HTTP請求的數目可有效提高訪問性能。減少HTTP的主要手段是合並CSS、合並JavaScript、合並圖片。將瀏覽器一次訪問需要的JavaScript、CSS合並成一個文件，這樣瀏覽器就只需要一次請求。圖片也可以合並，多張圖片合並成一張，如果每張圖片都有不同的超鏈接，可通過CSS偏移響應滑鼠點擊操作，構造不同的URL。
2．使用瀏覽器緩存
對一個網站而言，CSS、JavaScript、Logo、圖標這些靜態資源文件更新的頻率都比較低，而這些文件又幾乎是每次HTTP請求都需要的，如果將這些文件緩存在瀏覽器中，可以極好地改善性能。通過設置HTTP頭中Cache-Control和Expires的屬性，可設定瀏覽器緩存，緩存時間可以是數天，甚至是幾個月。在某些時候，靜態資源文件變化需要及時應用到客戶端瀏覽器，這種情況，可通過改變文件名實現，即更新JavaScript文件並不是更新JavaScript文件內容，而是生成一個新的JS文件並更新HTML文件中的引用。使用瀏覽器緩存策略的網站在更新靜態資源時，應採用批量更新的方法，比如需要更新10個圖標文件，不宜把10個文件一次全部更新，而是應一個文件一個文件逐步更新，並有一定的間隔時間，以免用戶瀏覽器突然大量緩存失效，集中更新緩存，造成伺服器負載驟增、網路堵塞的情況。
3．啟用壓縮
在伺服器端對文件進行壓縮，在瀏覽器端對文件解壓縮，可有效減少通信傳輸的數據量。文本文件的壓縮效率可達80%以上，因此HTML、CSS、JavaScript文件啟用GZip壓縮可達到較好的效果宴襪。但是壓縮對伺服器和瀏覽器產生一定的壓力，在通信帶寬良好，而伺服器資源不足的情況下要權衡考慮。
4．CSS放在頁面最上面、JavaScript放在頁面最下面
瀏覽器會在下載完全部CSS之後才對整個頁面進行渲染，因此最好的做法是將CSS放在頁面最上面，讓瀏覽器盡快下載CSS。JavaScript則相反，瀏覽器在載入JavaScript後立即執行，有可能會阻塞整個頁面，造成頁面顯示緩慢，因此JavaScript最好放在頁面最下面。但如果頁面解析時就需要用到JavaScript，這時放在底閉祥坦部就不合適了。
5．減少Cookie傳輸
Cookie在每次響應請求中，如果太大勢必會影響性能，所以沒必要網cookie放的就不放，針對性的選擇放入cookie的數據。
總之，優化轎桐的方法還很多，我感觸最深的是第4項，有些js文件大引用如果放到最前面對性能損耗很大。
『玖』 為什麼我在主機管理平台里設置了404頁面後，前端還是不顯示我設置過的頁面，顯示的還是瀏覽器自帶頁面
你開啟 404這個功能 。另外，要把文件傳上去。。然後隨便輸了一個錯誤的地址，看看是否能出現你的界面。