# 面試衝刺錄音

###### tags:`面試`

## 目錄
[TOC]

## Day15 題目：對 React 的生命週期熟嗎？有哪一些生命週期

1. constrcutor，component 被建立
2. mount，component 被 render 到 DOM 上面去，又有 didMount 跟 willMount，就是正要被放上去還有已經放上去了
3. update，component 更新 state 或 props 的時候
4. unmount，component 從 DOM 被拿下來要消失的時候

> React 的生命週期可區分為三個執行階段，分別是Mounting、Updating 、Unmounting ，Mounting 會在元件被建立時被執行，Updating 則是在元件被重新渲染時執行，Unmounting 是在元件被移除時執行，在 Mounting 階段最先執行的是 constructor ，constructor() 會在其被 mount 之前被呼叫，是用來建構並初始化初始化 state 或綁定方法，接著會呼叫 render，當 render 被呼叫時，它將會檢視 this.props 和 this.state 中的變化，並回傳透過 JSX 建立的 React element，也就是說執行 setState、更新父層元件傳遞的 props，都會執行到 render()，當component 被加入 DOM tree 中後，componentDidMount() 會馬上被調用，我們可以在這個 function 中做額外的 side effect，再來進入Updating 階段，首先會執行的是 shouldComponentUpdate，我們可以在這個 Function 設定哪些元件在 state 改變時會重新渲染，或者不重新渲染，再來是 render 當 render 被呼叫時，它會檢視 this.props 和 this.state 中的變化，並回傳相關元素最後是 componentDidUpdate 會在更新後馬上被呼叫。這個方法並不會在初次 render 時被呼叫，接著進入Unmounting 階段， 這個 Function 會在 component 被 unmount 前呼叫 ，我們可以透過 這個 Function 清除一些綁定的資訊，那以上就是 react生命週期中的執行階段和function 類別

## Day14：請問 cookie, localStorage 與 sessionStorage 的差別是什麼？
1. cookie 是瀏覽器儲存資訊的地方，可以由 server 透過 Set-Cookie header 指定要存什麼，會隨著 request 一起被帶給 server
2. localStorage 也可以存資訊，只能存字串，不會隨著 request 被帶給 server
3. sessionStorage 與 localStorage 類似，差別在於分頁關掉之後儲存的資料就不見了，不會被一直保留住

> cookie 是讓我們在瀏覽器裡存儲資訊的小型文字檔，那運作過程是當瀏覽器發送一個 Request 給 Server的時候，Server 會回傳一個 set- Cookie 的 response header，瀏覽器接收到這個 header 之後就會把這些資料存在 Cookie 裡面，只要我們還在同一個 domain 下 而且 cookie 過期之前再次發送 req 的時候，瀏覽器就會自動帶上這些資訊 server 也就能辨別使用者身份了，而 localstroage 和 seesionStorage 這兩個 web api 則是能比 cookie 儲存更多資訊的方法，那比較不同的是，localstroage 和 seesionStorage 並不參與和伺服器的溝通，以生命週期來說，LocalStorage 除非手動刪除，否則不會自動清除， SessionStorage 則是在分頁或瀏覽器關掉後就會清除

## Day13：請問 CSS 怎麼做垂直水平置中？請提供至少兩個方法

1. flexbox 搭配 align-items: center + justify-content: center;
2. position absolute/fixed + top left 50% + transform: translate(-50%, -50%)
3. 其他請自行 google

> 第一種方式可以在元素上加上 position:absolute,再加上top :50% 和 left: 50%，該元素的左上角就會鎖定在畫面正中央，這時只要再加上 Transform:trnaslate( -50% , -50%)，就會依據元素的寬高將元素位移置畫面正中央，第二種方式則是可以在獄設定元素的父層加上 display:flex，並搭配 justify-content: center 和 align-items: center、就可以達到水平致中的效果

## Day12：從網址列輸入 google.com 按下 enter 到看到頁面，請問這中間發生了哪些事情？

可以講到的很多，講自己會的就好，像是：
1. DNS 查詢
2. request response 來回的過程
3. 瀏覽器的顯示

想回答更多就是針對每個細節再下去講，例如說：
1. DNS 查詢具體上是怎麼做的，是分成一層一層的來查詢
2. tcp 三次握手
3. 瀏覽器渲染畫面的流程細節，解析 html 產生 dom，解析 css 產生 cssom，結合產生 render tree 然後 flow，paint 之類的

> 瀏覽器會先檢查電腦中的 dns 快取，若沒有則會向 dns server 發送 google.com 這個 domain ，透過 dns server 的解析後，則會回傳給瀏覽器 google.com 的 ip 位址，當瀏覽器有了 ip ，瀏覽器就可以依照 ip 位置和 port，將要傳輸的資訊打包成封包，經由 TCP 連線開始傳輸，google 的 server 端就會依據 rquest 的 method，去執行存取資料庫的相關資料，最後再將結果回傳給瀏覽器，瀏覽器會根據 response 的文件，將 html 和 css 解析成樹狀結構模型，解析之後產生 render tree，最後在根據計算結果繪製到畫面上

## Day11：請問 XSS 是什麼？該如何防範
1. XSS 全名跨站式腳本攻擊，攻擊者可以在你的網站上執行 JS
2. 分成三種：Stored XSS, Reflected XSS 跟 DOM-based XSS
3. 在前端 render 而造成的 XSS 就是 DOM-based XSS
4. 從後端 render，然後資料是從資料庫來的就叫做 Stored XSS
5. 從後端 render，會直接反映使用者的輸入的就叫 Reflected XSS
6. 防範方式：過濾使用者的輸出，進行編碼，不要當成 JS 執行
7. 也可以用 CSP 阻止使用者執行 inline script
8. 如果一定要輸出 HTML，可以用 DOMPurify 之類的 library 來過濾

> xss 是由於網站未在使用者可自行輸入的位置經過驗證或過濾， 所以攻擊者就能透過輸入惡意程式碼，，在網頁顯示這段內容時，進而執行所預期的行為，藉此達成達成竊取資料和破壞資料的行為，xss 的攻擊型態大致可分為三種，第一種是 儲存型，最常見的就是網站留言板，因為使用者可以任意留言，所以會將惡意程式碼直接存進資料庫當中，再進而影響到進入這個網站的所有使用者，第二種是反射型，是把惡意程式藏在網址列裡，再誘導其他人點擊假連結進而執行攻擊，第三種是 dom 型 ，前端 js 沒有適當處理接收到的輸入資料，在動態產生DOM的過程中，因為輸入內容中被植入惡意代碼，導致程式與資料以非預期的方式執行，為了防止使用者輸入的內容被當成程式碼的一部份，我們可以透過 字元跳脫或轉譯的方式，讓使用者輸入的內容都被轉譯成純粹的文字，就沒辦法變成程式碼的一部，對於這種攻擊方式來說，大原則就是只要是使用者可以自行控制的輸入內容，都要確保內容無法被當作程式碼的一部份，才能防止發生這種非預期的事件

## Day10：請問在資料庫裡面什麼是一對多（one-to-many）關係，什麼是多對多關係（many-to-many），table 又該如何設計？請舉例子說明

1. 一對多關係就像是分類與文章，一個分類底下可以有多篇文章，然後每篇文章只會有一個分類，這是在資料庫裡面我們就會在文章的 table 裡存一個分類的 id，把這兩張表格關連起來
2. 多對多像是文章與 tag，一個 tag 底下可以有很多文章，一篇文章也可以有多個 tag，這時候我們就需要另一個專門存文章跟 tag 關聯的表格，內容是文章 id 跟 tag id，就可以藉由這張表格知道關聯

距離來說：
post_id tag_id
1 10
1 12
就代表 id 是 1 的 post 有 id 是 10 12 這兩個 tag

<br>

> 在設計資料庫的時候，我們會將不同類型的資料儲存在不同的資料表，再透過特定欄位來關聯其他資料表，而這個欄位通常都會拿來存取 Foreign Key 外鍵，外鍵其實就是其他資料表的 Primary key 主鍵，而主鍵會有幾個特性，像是唯一性，不可重複性，不可為空，這就像是一個人只會有一組唯一身分字號，那在資料庫中最常見的主鍵就是 id，我們可以利用主見和外鍵建立 3 種資料關聯的關係，分別是一對一，一對多，多對多，一對一就好比電商網站中，一個會員只會擁有一個購物車，而每個購物車也只會對應到一個會員，所以資料表的形勢就會像是在 cart table 存放 user table 的id，納因為是一對一的關係，所以也可以反過來在 user table 中存放 cart table 的 id，一對多則是向一個商品分類會對應到多個商品，而一個商品則指會對應一個 分類，所以資料表的形勢就會是在 product table 中存放 category table 的 id，多對多則像是部落格的文章一樣，一篇文章可以擁有多個標籤，而一個標籤也可以對應到多個文章，像這種多對多的關係，我們則是會另外設置一個 table 來存放 post table 的 id 和 tag table 的 id ，透過這種將多對多的拆分成兩個一對多的方式來實現兩個 table 之間的多對多關係

## Day 9：在 JS 裡面想要宣告變數有三個關鍵字可以用，var let 跟 const，請問這三種的差異為何？
Day9 題目重點：

1. 其實除了這三個以外，還有一種方式是都不加關鍵字的，這種的會把變數變成全域變數，例如說 a = 3
2. var 的 scope 是 function，可以重新賦值，需注意 hoisting
3. let 的 scope 是 block，可以重新賦值，有 hoisting + TDZ
4. const 的 scope 是 block，不能重新賦值但可以更改內容，宣告時就要給初始值，有 hoisting + TDZ
<br>

> 在 es6 以前，我們只有 var 這個宣告變數的方法，而在 es6 後則新增兩個宣告變數的方法，一個是 let 一個是 const ，const 指的就是常數，如果我們使用 const 宣告變數，就必須要在宣告當下就要賦值，沒辦法事後再賦值，而且在復職後也無法在重新賦值，，那 let 和 var 最大的區別就是作用域的範圍，var 是 function scope，let 和 const 則是 block scope，在 es6 以後，為了不讓區域變數覆蓋到全域變數，都會盡量以 let 和 const 的方式宣告便變數，這樣可以使的程式碼更穩定也可以增加可讀性

## Day 8：什麼是 SQL Injection？該如何防範？

1. SQL Injection 就是攻擊者可以刻意操弄部分 query 內容，跟原本的合在一起而產生具有新的意義的 query，進而達成攻擊
2. 防範方式是跳脫字串或是用 Prepared statement
3. 也可以提到詳細的攻擊方法，例如說利用 union 來拿資料或者是 blind SQL injection 是什麼
<br>

> SQL Injection 就是攻擊者透過輸入非預期的字串，而這些字串會進而執行 SQL 的指令，攻擊者就能藉由修改 sql 語法的方式，來達成達成竊取資料和破壞資料的行為，為了防止使用者輸入的內容被當成程式碼的一部份，我們可以透過 prepare statement 這種預處理的方式，使這些內容跳脫字元，讓使用者輸入的內容都被轉譯成字串，就沒辦法變成程式碼的一部，對於這種攻擊方式來說，大原則就是只要是使用者可以自行控制的輸入內容，都要確保內容無法被當作程式碼的一部份，才能防止發生非預期的事件

## Day 7：請問什麼是 CORS issue? 會造成這問題的原因是什麼，又該如何解決

1. CORS 跟 same origin policy 有關，是為了安全性所以瀏覽器禁止跨來源的存取
2. server 加上正確的 header 是唯一正解
附上兩篇半成品的部落格文章，希望能快點寫完QQ
https://github.com/aszx87410/huli-blog/blob/master/source/_drafts/cors-guide-1.md
https://github.com/aszx87410/huli-blog/blob/master/source/_drafts/cors-guide-2.md
<br>

> 瀏覽器基於安全性考量，制定了一個同源政策，意思是說只要你 現在這個網站跟你要呼叫 api 的網站不同源的時候，瀏覽器依舊會幫你發送 request ，但會把 response 擋下來，所以 js 也就拿不到回傳結果了，但我們總是需要串聯別人的 API，這時就要透過 cors 跨來源政策這項規範，如果想要跨來源火取資源就必須在 response header 加上 Access-Control-Allow-Origin，當瀏覽器收到 response 後，會先檢查 Access-Control-Allow-Origin 內的內容，如果裡面有包含發起這個 request 的 origin 的話，才會讓我們接收這個 response，除了Access-Control-Allow-Origin之外，其實還可以自定義接收那些 method、header，那其實上訴所提到的 「跨來源資源共享」、「同源政策」，都是瀏覽器上的規範，也就是說在交換資料的過程中，如果當中有瀏覽器參與才會有這些問題，那沒有瀏覽器參與，自然就沒有所謂跨網域的問題了

## Day 6：請問 process 跟 thread 的差別是什麼？

Day6 重點提醒：

可以再次複習這篇好文：https://developers.google.com/web/updates/2018/09/inside-browser-part1

1. 基本上一個應用程式在執行的時候就會產生一個程序（Process）
2. 一個程序底下可以有多個執行緒（Thread）
3. Process 之間基本上資料是不共享的，而同個 Process 底下的 thread 們則共享資料
4. 一個 CPU 同時間只能執行一個任務，但又不能一直執行同一個 process 的任務，所以會來回在不同 process 之間切換，這就叫做 context switch
5. 以瀏覽器為例，Chrome 是一個 process，然後還會幫每一個 tab 都產生一個 process，因此一個分頁掛掉不會影響到其他的
6. tab 的 process 底下又會有不同 thread 來做事，例如說負責渲染的 UI thread，負責網路的 network thread 等等
<br>

> 程序是作業系統進行資源分配和排程的一個獨立單位，每個程序都有自己的獨立記憶體空間也是執行續的容器，每個程序中至少都會存在一個執行續，如果硬體支援，也能同時並行多個執行續，以多任務的實現方面來說，Process 的優點就是穩定度相當高，，如果其中一個 Process 掛掉了，不會影響到其他的 Process。而對於 Thread 來說，因為所有的 Thread 都共享同一個 Process 的資源，如果某一個 Thread 掛了，那這個 Process 幾乎就崩溃了。在性能方面hread 和 Process 相比更加輕量一些，而且 在同個 process 之間 Thread 是可以互相共享資源的，所以不同 Thread 之間的交互就比較容易實現。而 Process 之間的溝通，則需透過共享記憶體或是其他更複雜的方式才可實現

## Day 5：請介紹一下 BOM 與 DOM
1. BOM 是 Browser Object Model，查了一下看似只是個沒有詳細定義的名詞，就是瀏覽器提供給 JS 的各種東西，透過 window 來存取，例如說什麼 location, navigator 之類的
2. DOM 是 Document Object Model，在 JS 裡面透過 document 可以取得，是可以讓你透過程式去改變 document 的一個 API

這邊我也不是很熟，查了一下發現 BOM 跟我們以前提過的 Web APIs 看起來差不多，都是瀏覽器提供給 js 的東西

https://javascript.info/browser-environment

https://frontendmasters.com/books/front-end-handbook/2017/learning/dom.html

https://stackoverflow.com/questions/2213594/whats-the-difference-between-the-browser-object-model-and-the-document-object-m
<br>

> bom 的全名是瀏覽器物件模型，我們可以使用 js 來與瀏覽器溝通就是因為瀏覽器提供了 bom 這個介面，而瀏覽器物件模型有著階層性的架構，最上層就是 window，也就是瀏覽器本身，底下接著的則是 document、history、loaction、navigator、screen，而 dom 就是指 document 這個分支，dom 則是我們用來控制網頁內容節點的介面，依照目前瀏覽器載入的文件，文件中的所有元素都將被解析為一個 object ，並分別對應到 html 文件內的的結構關係，也因為結構圖的全貌像是樹狀圖一樣，所以也有人稱之為 dom tree，我們也是依照這份 dom tree 來使用 JS 存取 html 內的屬性及樣式甚至還能監聽事件，在符合特定條件下，觸發我們所給予的行為

## Day 4：情境時事題，關於 HackMD
事情是這樣的，有人在臉書社團裡貼了一篇用 hackmd 整理出來的資源：https://www.facebook.com/groups/f2e.tw/permalink/3485648974805776/
底下有個回應是這樣的（可以直接看上面貼文的留言或是點這連結）：https://www.facebook.com/photo/?fbid=2809570192592284&set=p.2809570192592284
請問這留言整串看完之後，如果你是原 po，你會怎麼回應？這個留言串有哪些觀念是錯誤的，哪些是正確的？

Day4 題目重點：
1. 原 po 只是貼 hackMD 的筆記上面，並不是 hackMD 的開發者，所以跟他反映也沒用
2. 只要是放在前端的東西都是「完全沒辦法隱藏」的，你頂多只能加強被找到的難度，仔細想想就知道了，因為你要的東西一定都要先下載下來，所以一定在你的電腦裡，就一定找得到
3. 那截圖中那些 key 是不是敏感資訊呢？答案是不是，那些就像第八週的 twitch api header 裡放的那些東西，是要去打 twitch api 的必要資訊
4. 而 dotenv 或是環境變數都在 week17, 18 稍微提過，這些是後端拿來隱藏敏感資訊用的，前端用不了。用環境變數是為了不要把這些資料（例如說資料庫帳密）寫到程式碼裡面。
5. 綜合以上，原本貼的討論串就是有點搞錯狀況，前後端分不太清楚，是不是敏感資訊也搞錯，通常有看到 secret 這個字眼的才是，例如說 api_secret 跟 api_key，前者是敏感資訊後者不是
<br>

## Day 3：什麼是 cookie？什麼是 session？
Day3 題目重點提醒：
1. 要提到 HTTP 是無狀態的（stateless）
2. cookie 是瀏覽器儲存資料的一個地方，可以從 server 透過 Set-Cookie 設定，在發 request 時會透過 Cookie header 帶回去 server
3. session 就是有狀態的一段關係，最簡單的方式就是透過 cookie 來幫忙帶資料，就可以讓 request 之間建立關聯
4. 敏感資料可以存在 server，叫做 session data，利用 session id 存在 cookie 裡面來做關聯
5. 也可以把 session data 直接寫在 cookie 裡面，叫做 cookie-based session，這樣的 cookie 內容就會是加密過的，因為有敏感資訊
其他請複習 session 與 cookie 三部曲
<br>

> 在講解 cookie 和 session 的差別之前我們可以先來談談 http協定 的無狀態特性，，無狀態的意思是說，每次發送的 request 都是獨立的，所以如果後續需要前面的資訊就必須重傳，而且步驟越多就需要越多資料，這種情形下的使用者體驗是相當不好的，在操作上也是非常不便的
>
> 為了解決以上問題，我們需要一個機制來讓 server 來記錄我們的狀態，那這個讓 req 保有狀態的機制就稱為 session ， cookie 則是讓我們在瀏覽器裡存儲資訊的小型文字檔，運作過程是當瀏覽器發送一個 Request 給 Server的時候，Server 會回傳一個 set- Cookie 的 res header，瀏覽器接收到 res header 之後把這些資料存在 Cookie 裡面，只要我們還在同一個 domain 下 而且 cookie 過期之前再次發送 req 的時候就會自動帶上這些資訊 server 也就能辨別身分了
>
> 需要特別注意的是，在 client 端是能更改 cookie 的內容的，那麼也就有機會能夠偷走或串改別人的資訊，所以通常都會先將內容加密再存入 cookie，這樣就能保護個人資訊了，但其實應該盡量避免在 cookie 內存放敏感資訊 而且由於cookie 能儲存的容量也不多，所以有另一種更常見的用法其實是server 只會在 cookie 中存入一組加密後的 sessionID，其他狀態都存在 server 端，所以只要之後再進入網頁時，就會比對 cookie 中 的 sessionID 來識別身分，特別需要注意的一點是 SessionID 基本上是種認證不認人的方式 SessionID 被偷走，別人就可以偽造你的身份來登入了

## Day 2：請問 HTTP Method 中 GET 與 POST 的差別為何？
Day2 重點
今天的題目可以回答的深淺上下限滿大的，一般基本的回答就是比較偏「實際使用上的回答」：
1. GET 通常是拿東西，POST 是做一些操作
2. GET 的參數帶在 url query string，POST 帶在 request body
3. 承上，GET 因為帶在網址上所以比 POST 不安全
4. 承第二點，GET 因為帶在網址上所以有長度限制
想要回答得更猛就是直接看 RFC：https://tools.ietf.org/html/rfc7231#section-4
這邊所講的就會是這兩個在「規格上的差異」
可以提到：
1. Safe Method 是什麼
2. Idempotent Method 是什麼
3. GET 其實也能帶 request body 但可能會被伺服器擋掉
4. GET 比較適合做快取
5. GET 東西放網址上之所以比較不安全，還有一個原因是可能會透過 Referral header 流出去
但我也沒有很建議你回答規格上的差異，因為面試官不夠專業會聽不懂XD
所以可以自己斟酌一下，或許可以帶到一點試試水溫
<br>

> 在講解HTTP method 的 get post 的差別之前，我們可以先來講解遺下HTTP HTTP全名是 超文本傳輸協定 HTTP的底層是TCP（傳輸控制協定）和IP（網際網路協定）。所以GET和POST的底層也是TCP/IP，也就是說，GET/POST都是TCP連結。GET和POST能做的事情是一樣一樣的 所以如果你想在 發送 get 時帶上 request bod ，或是 發送POST 的req 時在url引數，但就會顯得很不合與一
>
>
> 雖然理論上我們可以在url 上加入無限的參數 但瀏覽器或是福氣在解析往解時也需要時間和資源解析參數，所以為了減少的負擔，伺服器和瀏覽器大多數都會限制url長度
>
> 納在安全方面 post 這ˋ種將資料放入 request body 方式雖然 相對 get 直接將參數待在 url 上會更安全，但其實如果是基於 http 的方式全書，封包其實都還是以明文在傳遞的，所以如果有心想攔截封包，是可以直接查看內容的，最安全的方式騎士使用 https 的來傳遞資料，https 雖然還是基於 http 協定傳遞資料，不過會額外加密封包，來增加資料的安全性

## Day 1：請解釋一下什麼是盒模型 box model，有哪些需要注意的地方？
1. 要能講出由內到外：content padding border margin
2. 要能講出 box-sizing: content-box 跟 border-box 的差別
3. 在實務上常會看到 * { box-sizing: border-box }
4. 要不要順便帶到 display 那幾種我覺得都可以啦
5. 要不要順便提 margin collapse 我也覺得都行
<br>

> box modal是 html 用於空間定位的模型從內到外的區塊分別為content padding border margin，我們可以透過 css 來控制這些區塊的範圍，在排版的時候可以發現，當我們設定玩 Contetn 的大小之後，在設定 Padding 或 border 後，整個元素的大小會超過設定的寬饕，如果周圍還有，也會進而影響其他周圍元素，為了固定原本 元素的範圍，我們可以使用 box modal 提供的 box-sizing 這個元素，box sizing 主要分為兩個模式，一個是

## Day 0：請問什麼是 CSRF? 該如何防範？
順便提醒一下昨天 csrf 那題要講到的幾個重點

1. csrf 可以作用最大的原因是你從第三方去對某網域做操作的時候，瀏覽器會幫你把這個網域的 cookie 一起帶上去，從伺服器看來就等於是使用者本人在操作，而防禦方式都是圍繞在怎麼解決這個狀況
2. 有一種方法是如果不是用 cookie 做身份驗證，例如說22周作業用 local storage 裡的東西做驗證，那就不會有 csrf 的問題
3. 或是 otp，常見的簡訊驗證碼，多了第二道手續
4. 不登入也是一種，不是登入狀態就不會怎樣
5. samesite cookie 則是靠瀏覽器幫你防禦，只有在同個 site 的時候會帶 cookie
6. csrf token 也是多一道手續，攻擊者沒辦法拿到這東西所以沒辦法在 header 裡面放值

幾個要修正的點：

1. Cookie 跟 session 要分清楚
2. Samesite 是不是 google 發明的不重要，重點是 chrome 會預設 samesite 屬性，這才是重點
3. 不要舉什麼用 get 刪除資料的例子，那個只是方便講解而已，但技術上本來就不該這樣做，舉 post 改資料的會比較好
4. CSRF 通常都是改資料，做某些操作，而不是取得資料或是偷資料

###### tags: `面試衝刺群，每日題目及講解`, `程式導師實驗計畫第四期`

## 更多參考
1. [做了一份前端面试复习计划](https://juejin.cn/post/7061588533214969892#heading-78)