前端面試複習計劃,準備衝刺2023!

語言: CN / TW / HK

想寫這篇文章已經很久了,作為一個技工,怎麼能免的了一直學習呢! 也換過兩份工作,所以深知每次面試就是一次大考。寫這篇文章的目的是對技術的回顧,也是對自己成長的記錄。(對於某些知識點如果我理解的不對,大家有更好的理解角度,也希望大家指出來,大家相互討論,學習吧!)。

WechatIMG193.jpeg

閒話休提,書歸正傳。面試就是用較短的時間做到雙方相互瞭解,所以我儘量用簡短語言來描述事物本質,至於對於某些重要知識點的深入理解,我會在後續逐步整理出文,請關注、點贊、收藏!

小編最近已經離職了,也在尋求新的機會,如果剛好你的公司在招聘,給我個機會,聊一下唄!😄😄😄

如果有看到標題號順序沒對上,不要奇怪,那是因為關於某些問題我認為還可以再優化,還在整理中,我這麼重視格式的人,不會忘記的,哈哈哈!!!這份特殊的【新年禮物】,你可要收好啊!


mermaid pie title 文章分為多個模組進行介紹 "http" : 11 "html" : 4 "css" : 5 "javascript" : 23 "react" : 9 "業務層面" : 1 "flutter" : 9 "其他" : 3


面試路上互助交流群

如果你也在找工作或者你準備換工作,那麼可以一起交流一下呀,也不介意潛水哈 😄,我只是希望面試的路上不是你我一個人獨立奮鬥,在大城市生活久了人都變的孤獨了許多,我不希望面試完想找人分享找不到。在群裡我們可以共享資源、一同避一下那些踩雷的公司、📣 吐槽生活、互相激勵等等,下面是群二維碼,歡迎加群交流呦!💪 加油 準備衝刺2023!

WechatIMG197.jpeg

一、http 相關

http 相關知識,前端必備網路相關知識。

1. 位址列輸入 URL 到頁面展現都經歷了哪些過程?

1. 構建請求
2. 查詢強快取
3. DNS解析
4. 建立TCP連線(3次握手)
5. 傳送HTTP請求(請求行/頭/體)
6. 伺服器處理收到的請求,將資料返回瀏覽器
7. 瀏覽器收到HTTP響應
8. 讀取內容,解析html,瀏覽器渲染,
9. 生成dom樹、解析css樣式、js互動

2. 三次握手的過程?

  1. 從最開始雙方都處於CLOSED狀態。

  2. 客戶端主動請求建立連線,傳送 SYN到服務端 , 自己變成了SYN-SENT狀態。

  3. 服務端接收到請求,針對客戶端的SYN的確認應答,返回SYNACK(對應客戶端發來的SYN),並請求建立連線,自己變成了SYN-REVD

  4. 客戶端收到服務端的請求,對服務端SYN的確認應答,併發送ACK給服務端,自己變成了ESTABLISHED狀態;

  5. 服務端收到ACK之後,也變成了ESTABLISHED狀態。

另外需要提醒你注意的是,SYN 是需要消耗一個序列號的,下次傳送對應的 ACK 序列號要加1,因為 凡是需要對端確認的,一定消耗TCP報文的序列號。


為什麼是三次不是四次

三次握手的目的是確認雙方傳送接收的能力,那四次握手可以嘛?

當然可以,100 次都可以。但為了解決問題,三次就足夠了,再多用處就不大了。


三次握手過程中可以攜帶資料麼?

首先說答案:第三次握手的時候,可以攜帶。前兩次握手不能攜帶資料。

如果前兩次握手能夠攜帶資料,那麼一旦有人想攻擊伺服器,那麼他只需要在第一次握手中的 SYN 報文中放大量資料,那麼伺服器勢必會消耗更多的時間和記憶體空間去處理這些資料,增大了伺服器被攻擊的風險。第三次握手的時候,客戶端已經處於ESTABLISHED狀態,並且已經能夠確認伺服器的接收、傳送能力正常,這個時候相對安全了,可以攜帶資料。


3. 網路分層是 5 層還是 7 層?

OSI 七層參考模型:

物理層 -> 資料鏈路層 -> 網路層(Ip)-> 傳輸層(TCP)- > 會話層-> 表現層- > 應用層(http)頂層

我們所知道的還有 TCP/IP 四層模型和 TCP/IP 五層模型。這又是怎麼出來的,其實所謂的 TCP/IP 四層模型和 TCP/IP 五層模型是以 OSI 七層優化而來,把某些層進行合併了(會話層,表現層,應用層合併成應用層),其實本質上還是相同的,。

網際網路 5層協議模型:

物理層 -> 資料鏈路層 -> 網路層(Ip)-> 傳輸層(TCP)->應用層(http)
  • 物理層:用物理手段將電腦連線起來,就像我們講到的計算機之間的物理連線。主要用來傳輸0、1訊號,所有我們用另一層用來規定不同0、1組合的意義是什麼。
  • 資料鏈路層:在資料鏈路層規定一套協議,專門的給0、1訊號進行分組,以及規定不同的組代表什麼意思,從而雙方計算機都能夠進行識別,這個協議就是"乙太網協議"
  • 網路層:網路層的由來是因為在資料鏈路層中我們說說兩臺計算機之間的通訊是分為同一子網路和不同子網路之間,那麼問題就來了,怎麼判斷兩臺計算機是否在同一子網路(區域網)中?這就是網路層要解決的問題。
  • 傳輸層:傳輸層的主要功能就是為了能夠實現"埠到埠"的通訊。計算機上執行的不同程式都會分配不同的埠,所以才能使得資料能夠正確的傳送給不同的應用程式。
  • 應用層:應用層的功能就是規定了應用程式的資料格式。我們經常用得到的電子郵件、HTTP協議、以及FTP資料的格式,就是在應用層定義的。

4. httpshttp有什麼區別?

https 不是 http 的對立面,兩者在本質上是相同的,都採用相同的“超文字傳輸協議”,使請求的資料能夠顯示在網站上。

安全性:

http協議以明文方式傳送內容,不提供任何方式的資料加密。http協議不適合傳輸一些敏感資訊,比如:信用卡號、密碼等支付資訊。https則是具有安全性的SSL / TLS加密傳輸協議,可防止通過 Internet 傳送的資料(使用者名稱,銀行卡密碼等)被第三方攔截和讀取。

連線方式:

httphttps使用的是完全不同的連線方式,http 連線建立相對簡單, TCP 三次握手之後便可進行 HTTP 的報文傳輸。而 httpsTCP 三次握手之後,還需進行 SSL/TLS 的握手過程,才可進入加密報文傳輸。用的埠也不一樣,前者是80,後者是443

權威認證:

https 協議需要向 CA(證書權威機構)申請數字證書,來保證伺服器的身份是可信的;http 則不需要。

總結:HTTPS相對複雜,擁有權威認證,也更安全,也是以後網站的普遍模式。HTTPS協議的主要作用可以分為兩種:一種是建立一個資訊保安通道,來保證資料傳輸的安全;另一種就是確認網站的真實性。


5. http中的Keep-Alive有了解嗎?

Keep-Alivehttp的一個頭部欄位Connection中的一個值,它是保證我們的http請求能建立一個持久連線。也就是說建立一次TCP連線即可進行多次請求和響應的互動。它的特點就是隻要有一方沒有明確提出斷開連線,則保持TCP連線狀態,減少TCP連線和斷開造成的額外開銷。

HTTP/1.0階段:

HTTP/1.0中所有的連線預設都是關閉的,如果客戶端瀏覽器支援Keep-Alive,那麼就在HTTP請求頭中新增一個欄位Connection: Keep-Alive,當伺服器收到附帶有Connection: Keep-Alive的請求時,它也會在響應頭中新增一個同樣的欄位來使用Keep-Alive。這樣一來,客戶端和伺服器之間的HTTP連線就會被保持,不會斷開(超過Keep-Alive規定的時間,意外斷電等情況除外),當客戶端傳送另外一個請求時,就使用這條已經建立的連線。

HTTP/1.1階段

HTTP/1.1中所有的連線預設都是持久連線的。除非在請求頭或響應頭中指明要關閉:Connection: Close,這也就是為什麼Connection: Keep-Alive欄位再沒有意義的原因。目前大部分瀏覽器都是用http1.1協議,也就是說預設都會發起Keep-Alive的連線請求了。


6. http1http2 的區別?

  • http2採用二進位制,而http1使用的是文字格式;
  • http2是多路複用的,而且無阻塞,只需一個連線即可實現並行;http1一個連線只能傳送一個請求;
  • http1header帶有大量資訊,而且每次都要重複傳送;http2使用encoder來減少需要傳輸的header大小,通訊雙方各自快取 一份header 資訊字典表,既避免重複傳輸,又提升了傳輸速度。

7. 什麼是websocket?

Websocketh5提供的一種在單個TCP連線上進行全雙工通訊的協議,只需要伺服器和瀏覽器通過HTTP協議進行握手之後,兩者之間就直接可以建立永續性的連線,可以雙向傳送或接收資訊,並且允許伺服器主動向客戶端推送資料,適合資料需要及時重新整理的場景。

websocket特性:

  1. 效能高,http 是基於文字,websocket 是二進位制
  2. 雙向通訊
  3. 在建立連線時還需要http 來通訊,
  4. 天生支援跨域
  5. 天然支援加密,安全
  6. 如果斷開會自動重連
websocket 封裝庫 socket.io

我們知道原生的websocket寫起來是非常費腦細胞的,所以推薦一個庫,socket.io,使用起來較為方便,並且它支援ie5,而且是跨域自動解析資料,非常非常推薦!!!!


8. websockethttp有什麼區別?

相同點:

  1. 都是一樣基於TCP的,都是可靠性傳輸協議。
  2. 都是應用層協議。

區別:

  1. WebSocket是雙向通訊協議,可以雙向傳送或接收資訊;而HTTP是單向的,只能由客戶端發起請求到服務端去請求資料,服務端只能作為被動方;
  2. http 是短連線,請求之後都會關閉連線,下次請求需要重新開啟連線;websocket 是長連線,只需要通過一次請求來初始化連線,後面就可以進行雙向資料通訊

WebSocket連線的過程:

  1. 客戶端發起http請求,經過3次握手後,建立起TCP連線;
  2. http請求裡存放WebSocket支援的版本號等資訊,如:Upgrade、Connection、WebSocket-Version等;
  3. 伺服器收到客戶端的握手請求後,同樣採用http協議回饋資料;
  4. 客戶端收到連線成功的訊息後,開始藉助於TCP傳輸通道進行全雙工通訊。

9. 什麼是http快取?

http快取指的是: 當客戶端向伺服器請求資源時,會先抵達瀏覽器快取,如果瀏覽器有要請求資源的副本,就可以直接從瀏覽器快取中提取而不是從原始伺服器中提取這個資源。

常見的http快取只能快取get請求響應的資源,對於其他型別的響應則無能為力,所以後續說的請求快取都是指get請求

分類:

  • 根據是否需要再請求:可分為強制快取和協商快取,強制快取如果生效,不需要再和伺服器發生互動,而協商快取不管是否生效,都需要與服務端發生互動;
  • 根據是否可以被單個或者多個使用者使用來分類,可分為私有快取和共享快取

配置:在請求的headers中新增

cache-control: max-age=30 pragma:no-cache

如不想被快取,則配置:

cache-control: no-store

10. 為什麼要使用 http 快取?

  • 減少了冗餘的資料傳輸,節省了網費。
  • 緩解了伺服器的壓力, 大大提高了網站的效能
  • 加快了客戶端載入網頁的速度

11. 都有哪些本地儲存的方案?

前端快取一般使用較多的有:localStorage、 sessionStorage、 cookie、indexdb

區別: - localStorage: HTML5新特性,只要在相同的協議、相同的主機名、相同的埠下,就能讀取/修改同一份localStorage資料,是永久儲存,除非手動刪除,大小5M左右,IE8以上,不能被爬蟲抓取到 - sessionStorage: HTML5新特性,比localStorage更嚴苛一點,除了協議、主機名、埠外,還要求在同一視窗,也就是瀏覽器的標籤,僅僅是會話級別的儲存,這些資料只有在同一個會話中的頁面才能訪問並且當會話結束後資料也隨之銷燬。 - cookie: 儲存使用者登入狀態的資料會在每一次傳送http請求的時候,同時傳送給伺服器,而localStoagesessionStorage不會,最小,最大4KB可設定過期時間,預設當瀏覽器關閉程序的時候自動銷燬。 - indexdb: iE10以上,比較適合鍵值對較多的資料,如果資料結構比較複雜,同時對瀏覽器相容性沒什麼要求,儲存量最大50M


二、HTML 相關

1. 淺談前端工程化介紹:模組化、元件化、規範化、自動化

前端工程化:指使用軟體工程的技術與方法對前端開發的技術、工具、流程、經驗、方案等指標標準化,它具備模組化元件化規範化自動化四大特性,主要目的是降低成本增加效率

截圖2022-12-16 20.36.38.png

  • 模組化:是指在檔案層面上對程式碼與資源實現拆分與組裝,將一個大檔案拆分為互相依賴的小檔案,再統一拼裝與載入。各個模組功能獨立,分模組來維護,組合方式更靈活,多人協作也互不干擾。例如:介面模組、資源模組、路由模組等。

  • 元件化:是指在功能開發場景中,將具備通用功能的互動設計劃分為模板、樣式和邏輯組成的功能單元,是具體某個功能的封裝,實現了程式碼更高層次的複用性,提升開發效率。元件的封裝也是物件的封裝,同樣要做到高內聚低耦合,例如分頁器、table表格、form表單等。

  • 規範化:將一系列預設規範接入工程各個階段,通過各項指標標準化開發者的工作流程,為每個開發者指明一個方向,引領著成員往該方向走。例如:eslint、stylelint、pre-commit等,拉齊程式碼標準,形成規範底線,方便不同人員等交叉維護。

  • 自動化:指將一系列繁瑣重複的工作流程交由程式根據預設指令碼自動處理,常見自動化場景包括但不限於自動化構建自動化測試自動化打包自動化釋出自動化部署等。在保證效率的同時,又解放了雙手。

總結:前端工程化不是某個具體的工具,而是對專案的整體架構與整體規劃,使開發者能在未來可判斷時間內動態規劃發展走向,以提升整個專案對使用者的服務週期。最終的目的是從手動處理流程全部替換為自動處理流程,以解放團隊雙手,讓其他成員更專注於自身業務需求

參考掘金小冊:《從 0 到 1 落地前端工程化》

關於git程式碼提交規範

關於程式碼提交規範,我認為是有必要去統一的,在日常開發中經常遇到一些千奇百怪的提交說明,例如中英文混合使用、各種不規範的英文單詞等。這讓Review程式碼的人會經常搞不清它們到底是幹嘛的,導致後續程式碼維護成本巨大。

我們不能只注重編碼而不考慮程式碼質量與提交質量。Angular團隊制定的提交規範是目前市面上公認為最合理、最系統、最流行的提交規範

Angular提交規範的格式包括HeaderBodyFooter三個內容。Header為必填項,BodyFooter為可預設項,這些內容通過以下結構組成一個完整的提交格式。

``` ():

空一行

# 空一行
``` ##### Header 該部分僅書寫一行,包括三個欄位,分別是`type`、`scope`和`subject`。 - **type**:用於說明`commit`的提交型別,`必選` - **scope**:用於說明`commit`的影響範圍,可選 - **subject**:用於說明`commit`的細節描述,可選 `type`用於說明`commit`的提交型別,包括以下選項,相信這些選項已滿足日常`95%`的應用場景。當然這些選項無需刻意記憶,我會引入命令自動完成這些提交工作。 型別 | 功能 | 描述 | | :----------: | -- | ----------------- | | **feat** | 功能 | 新增功能,迭代專案需求 | | **fix** | 修復 | 修復缺陷,修復上一版本存在問題 | | **docs** | 文件 | 更新文件,僅修改文件不修改程式碼 | | **style** | 樣式 | 變動格式,不影響程式碼邏輯 | | **refactor** | 重構 | 重構程式碼,非新增功能也非修復缺陷 | | **perf** | 效能 | 優化效能,提高程式碼執行效能 | | **test** | 測試 | 新增測試,追加測試用例驗證程式碼 | | **build** | 構建 | 更新構建,改動構建工具或外部依賴 | | **ci** | 指令碼 | 更新指令碼,改動CI或執行指令碼配置 | | **chore** | 事務 | 變動事務,改動其他不影響程式碼的事務 | | **revert** | 回滾 | 回滾版本,撤銷某次程式碼提交 | | **merge** | 合併 | 合併分支,合併分支程式碼到其他分支 | | **sync** | 同步 | 同步分支,同步分支程式碼到其他分支 | | **impr** | 改進 | 改進功能,升級當前功能模組 `scope`用於說明`commit`的影響範圍。簡要說明本次改動的影響範圍,例如根據功能可劃分為`資料層`、`檢視層`和`控制層`,根據互動可劃分為`元件`、`佈局`、`流程`、`檢視`和`頁面`。從`Angular`以往的提交說明來看,還是建議你在提交時對`scope`補全。 `subject`用於說明`commit`的細節描述。文字一定要精簡精煉,無需太多備註,因為`Body`部分可備註更多細節,同時儘量遵循以下規則。 - 以動詞開頭 - 使用第一人稱現在時 - 首個字母不能大寫 - 結尾不能存在句號(`.`) ##### Body 該部分可書寫多行,對`subject`做更詳盡的描述,內容應包括`改動動機`與`改動前後對比`。 ##### Footer 該部分只適用兩種情況,分別是`不相容變動`與`問題關閉`。 - **不相容變動**:當前程式碼與上一版本不相容,則以`BREAKING CHANGE`開頭,關聯`變動描述`、`變動理由`和`遷移方法` - **問題關閉**:當前程式碼已修復某些`Issue`,則以`Closes`開頭,關聯目標`Issue` 示例一個常規提交: ``` // 型別:修復問題,影響範圍:qa 環境,處理細節:全域性切換主題開關無效 關聯bug: #87697 fix(qa):invalid global theme color switch (#87679) ``` [參考掘金小冊:《從 0 到 1 落地前端工程化》 ](https://juejin.cn/book/7034689774719860739?enter_from=course_center) --- #### 2. `html5` 的新特性 語義化標籤: `