整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
HTTP車是由蒂姆·伯納斯-李（ TimBerners—Lee ）于1989年在歐洲核子研究組織（ CERN ）所發(fā)起
其中最著名的是 1999 年 6 月公布的 RFC 2616 ，定義了 HTTP 協(xié)議中現(xiàn)今廣泛使用的一個(gè)版本—— HTTP 1.1
全稱：超文本傳輸協(xié)議（ HyperText Transfer Protocol ）
概念： HTTP 是一種能夠獲取像 HTML 、圖片等網(wǎng)絡(luò)資源的通訊協(xié)議（ protocol ）。它是在 web 上進(jìn)行數(shù)據(jù)交換的基礎(chǔ)，是一種 client-server 協(xié)議
HTTP ——因特網(wǎng)的多媒體信使 ——《HTTP權(quán)威指南》。 HTTP 在因特網(wǎng)的角色：充當(dāng)一個(gè)信使的角色，干的就是一個(gè)跑腿的活，在客戶端和服務(wù)端之間傳遞信息，但我們又不能缺少它。 HTTP 協(xié)議是應(yīng)用層的協(xié)議，是與前端開發(fā)最息息相關(guān)的協(xié)議。平時(shí)我們遇到的 HTTP 請求、 HTTP 緩存、 Cookies 、跨域等其實(shí)都跟 HTTP 息息相關(guān)
也就是說， HTTP 依賴于面向連接的 TCP 進(jìn)行消息傳遞，但連接并不是必須的。只需要它是可靠的，或不丟失消息的（至少返回錯(cuò)誤）。
HTTP/1.0 默認(rèn)為每一對 HTTP 請求/響應(yīng)都打開一個(gè)單獨(dú)的 TCP 連接。當(dāng)需要連續(xù)發(fā)起多個(gè)請求時(shí)，這種模式比多個(gè)請求共享同一個(gè) TCP 鏈接更低效。為此， HTTP 1.1 持久連接的概念，底層 TCP 連接可以通過 connection 頭部實(shí)現(xiàn)。但 HTTP 1.1 在連接上也是不完美的，后面我們會(huì)提到。
HTTP 的組件系統(tǒng)包括客戶端、 web 服務(wù)器和代理
瀏覽器，特殊比如是工程師使用的程序，以及 Web 開發(fā)人員調(diào)試應(yīng)用程序
由 Web Server 來服務(wù)并提供客戶端所請求的文檔。每一個(gè)發(fā)送到服務(wù)器的請求，都會(huì)被服務(wù)器處理并返回一個(gè)消息，也就是 response
在瀏覽器和服務(wù)器之間，有很多計(jì)算機(jī)和其他設(shè)備轉(zhuǎn)發(fā)了 HTTP 消息。它們可能出現(xiàn)在傳輸層、網(wǎng)絡(luò)層和物理層上，對于 HTTP 應(yīng)用層而言就是透明的
有如下的一些作用
HTTP 有兩種類型的消息：
HTTP 消息由采用 ASCII 編碼的多行文本構(gòu)成的。在 HTTP/1.1 以及更早的版本中，這些消息通過連接公開的發(fā)送。在 HTTP2.0 中，消息被分到了多個(gè) HTTP 幀中。通過配置文件（用于代理服務(wù)器或者服務(wù)器）， API （用于瀏覽器）或者其他接口提供 HTTP 消息
HTTP 請求和響應(yīng)都包括起始行（ start line ）、請求頭（ HTTP Headers ）、空行（ empty line ）以及 body 部分，如下圖所示：
下面詳細(xì)說下請求 Path ，請求路徑（ Path ）有以下幾種：
1）一個(gè)絕對路徑，末尾跟上一個(gè) ' ? ' 和查詢字符串。這是最常見的形式，稱為 原始形式 ( origin form )，被 GET ， POST ， HEAD 和 OPTIONS 方法所使用
POST / HTTP/1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0
復(fù)制代碼2）一個(gè)完整的 URL 。主要在使用 GET 方法連接到代理的時(shí)候使用
GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
復(fù)制代碼3）由域名和可選端口（以':'為前綴）組成的 URL 的 authority component ，稱為 authority form 。僅在使用 CONNECT 建立 HTTP 隧道時(shí)才使用
CONNECT developer.mozilla.org:80 HTTP/1.1
復(fù)制代碼4）星號(hào)形式 ( asterisk form )，一個(gè)簡單的星號(hào)('*')，配合 OPTIONS 方法使用，代表整個(gè)服務(wù)器。
OPTIONS * HTTP/1.1
復(fù)制代碼請求 Body 部分： 有些請求將數(shù)據(jù)發(fā)送到服務(wù)器以便更新數(shù)據(jù)：常見的的情況是 POST 請求（包含 HTML 表單數(shù)據(jù)）。請求報(bào)文的 Body 一般為兩類。一類是通過 Content-Type 和 Content-Length 定義的單文件 body 。另外一類是由多 Body 組成，通常是和 HTML Form 聯(lián)系在一起的。兩者的不同表現(xiàn)在于 Content-Type 的值。
1） Content-Type —— application/x-www-form-urlencoded 對于 application/x-www-form-urlencoded 格式的表單內(nèi)容，有以下特點(diǎn):
I.其中的數(shù)據(jù)會(huì)被編碼成以&分隔的鍵值對
II.字符以URL編碼方式編碼。
// 轉(zhuǎn)換過程: {a: 1, b: 2} -> a=1&b=2 -> 如下(最終形式)
"a%3D1%26b%3D2"
復(fù)制代碼2) Content-Type —— multipart/form-data
請求頭中的 Content-Type 字段會(huì)包含 boundary ，且 boundary 的值有瀏覽器默認(rèn)指定。例: Content-Type: multipart/form-data;boundary=----WebkitFormBoundaryRRJKeWfHPGrS4LKe 。
數(shù)據(jù)會(huì)分為多個(gè)部分，每兩個(gè)部分之間通過分隔符來分隔，每部分表述均有 HTTP 頭部描述子包體，如 Content-Type ，在最后的分隔符會(huì)加上--表示結(jié)束。
Content-Disposition: form-data;name="data1";
Content-Type: text/plain
data1
----WebkitFormBoundaryRRJKeWfHPGrS4LKe
Content-Disposition: form-data;name="data2";
Content-Type: text/plain
data2
----WebkitFormBoundaryRRJKeWfHPGrS4LKe--
復(fù)制代碼響應(yīng) Body 部分：
1）由已知長度的單個(gè)文件組成。該類型 body 有兩個(gè) header 定義： Content-Type 和 Content-Length
2）由未知長度的單個(gè)文件組成，通過將 Transfer-Encoding 設(shè)置為 chunked 來使用 chunks 編碼。
關(guān)于 Content-Length 在下面 HTTP 1.0 中會(huì)提到，這個(gè)是 HTTP 1.0 中新增的非常重要的頭部。
安全方法： HTTP 定義了一組被稱為安全方法的方法。 GET 方法和 HEAD 方法都被認(rèn)為是安全的，這意味著 GET 方法和 HEAD 方法都不會(huì)產(chǎn)生什么動(dòng)作 —— HTTP 請求不會(huì)再服務(wù)端產(chǎn)生什么結(jié)果，但這并不意味著什么動(dòng)作都沒發(fā)生，其實(shí)這更多的是 web 開發(fā)者決定的
首先要了解下副作用和冪等的概念，副作用指的是對服務(wù)器端資源做修改。冪等指發(fā)送 M 和 N 次請求（兩者不相同且都大于 1），服務(wù)器上資源的狀態(tài)一致。應(yīng)用場景上，get是無副作用的，冪等的。post 主要是有副作用的，不冪等的情況
技術(shù)上有以下的區(qū)分：
HTTP Headers
1.通用首部（ General headers ）同時(shí)適用于請求和響應(yīng)消息，但與最終消息主體中傳輸?shù)臄?shù)據(jù)無關(guān)的消息頭。如 Date
2.請求首部（ Request headers ）包含更多有關(guān)要獲取的資源或客戶端本身信息的消息頭。如 User-Agent
3.響應(yīng)首部（ Response headers ）包含有關(guān)響應(yīng)的補(bǔ)充信息
4.實(shí)體首部（ Entity headers ）含有關(guān)實(shí)體主體的更多信息，比如主體長( Content-Length )度或其 MIME 類型。如 Accept-Ranges
詳細(xì)的 Header 見 HTTP Headers 集合
HTTP（HyperText Transfer Protocol） 是萬維網(wǎng)（ World Wide Web ）的基礎(chǔ)協(xié)議。 Tim Berners-Lee 博士和他的團(tuán)隊(duì)在 1989-1991 年間創(chuàng)造出它。【HTTP、網(wǎng)絡(luò)瀏覽器、服務(wù)器】
在 1991 年發(fā)布了 HTTP 0.9 版，在 1996 年發(fā)布 1.0 版，1997 年是 1.1 版，1.1 版也是到今天為止傳輸最廣泛的版本。2015 年發(fā)布了 2.0 版，其極大的優(yōu)化了 HTTP/1.1 的性能和安全性，而 2018 年發(fā)布的 3.0 版，繼續(xù)優(yōu)化 HTTP/2 ，激進(jìn)地使用 UDP 取代 TCP 協(xié)議，目前， HTTP/3 在 2019 年 9 月 26 日 被 Chrome ， Firefox ，和 Cloudflare 支持
單行協(xié)議，請求由單行指令構(gòu)成。以唯一可用的方法 GET 開頭。后面跟的是目標(biāo)資源的路徑
GET /mypage.html
復(fù)制代碼響應(yīng)：只包括響應(yīng)文檔本身
<HTML>
這是一個(gè)非常簡單的HTML頁面
</HTML>
復(fù)制代碼HTML
RFC 1945 提出了 HTTP1.0 ， 構(gòu)建更好可拓展性
媒體類型是一種標(biāo)準(zhǔn)。用來表示文檔、文件或者字節(jié)流的性質(zhì)和格式。瀏覽器通常使用 MIME （ Multipurpose Internet Mail Extensions ）類型來確定如何處理 URL ，因此 Web 服務(wù)器在響應(yīng)頭中配置正確的 MIME 類型會(huì)非常的重要。如果配置不正確，可能會(huì)導(dǎo)致網(wǎng)站無法正常的工作。 MIME 的組成結(jié)構(gòu)非常簡單；由類型與子類型兩個(gè)字符串中間用'/'分隔而組成。
HTTP 從 MIME type 取了一部分來標(biāo)記報(bào)文 body 部分的數(shù)據(jù)類型，這些類型體現(xiàn)在 Content-Type 這個(gè)字段，當(dāng)然這是針對于發(fā)送端而言，接收端想要收到特定類型的數(shù)據(jù)，也可以用 Accept 字段。
這兩個(gè)字段的取值可以分為下面幾類:
- text： text/html, text/plain, text/css 等
- image: image/gif, image/jpeg, image/png 等
- audio/video: audio/mpeg, video/mp4 等
- application: application/json, application/javascript, application/pdf, application/octet-stream
復(fù)制代碼同時(shí)為了約定請求的數(shù)據(jù)和響應(yīng)數(shù)據(jù)的壓縮方式、支持語言、字符集等，還提出了以下的 Header
1.壓縮方式:發(fā)送端： Content-Encoding （服務(wù)端告知客戶端，服務(wù)器對實(shí)體的主體部分的編碼方式） 和 接收端： Accept-Encoding （用戶代理支持的編碼方式），值有 gzip: 當(dāng)今最流行的壓縮格式；deflate: 另外一種著名的壓縮格式；br: 一種專門為 HTTP 發(fā)明的壓縮算法
2.支持語言： Content-Language 和 Accept-Language （用戶代理支持的自然語言集）
3.字符集：發(fā)送端： Content-Type 中，以 charset 屬性指定。接收端： Accept-Charset （用戶代理支持的字符集）。
// 發(fā)送端
Content-Encoding: gzip
Content-Language: zh-CN, zh, en
Content-Type: text/html; charset=utf-8
// 接收端
Accept-Encoding: gzip
Accept-Language: zh-CN, zh, en
Accept-Charset: charset=utf-8
復(fù)制代碼雖然 HTTP1.0 在 HTTP 0.9 的基礎(chǔ)上改進(jìn)了很多，但還是存在這不少的缺點(diǎn)
HTTP/1.0 版的主要缺點(diǎn)是，每個(gè) TCP 連接只能發(fā)送一個(gè)請求。發(fā)送數(shù)據(jù)完畢，連接就關(guān)閉，如果還要請求其他資源，就必須再新建一個(gè)連接。 TCP 連接的新建成本很高，因?yàn)樾枰蛻舳撕头?wù)器三次握手，并且開始時(shí)發(fā)送速率較慢（ slow start ）。
HTTP 最早期的模型，也是 HTTP/1.0 的默認(rèn)模型，是短連接。每一個(gè) HTTP 請求都由它自己獨(dú)立的連接完成；這意味著發(fā)起每一個(gè) HTTP 請求之前都會(huì)有一次 TCP 握手，而且是連續(xù)不斷的。
HTTP/1.1 在1997年1月以 RFC 2068 文件發(fā)布。
HTTP 1.1 消除了大量歧義內(nèi)容并引入了多項(xiàng)技術(shù)
虛擬主機(jī)（ virtual hosting ）即共享主機(jī)（ shared web hosting ），可以利用虛擬技術(shù)把一臺(tái)完整的服務(wù)器分成若干個(gè)主機(jī)，因此可以在單一主機(jī)上運(yùn)行多個(gè)網(wǎng)站或服務(wù)。
舉個(gè)例子，有一臺(tái) ip 地址為 61.135.169.125 的服務(wù)器，在這臺(tái)服務(wù)器上部署著谷歌、百度、淘寶的網(wǎng)站。為什么我們訪問 https://www.google.com 時(shí)，看到的是 Google 的首頁而不是百度或者淘寶的首頁？原因就是 Host 請求頭決定著訪問哪個(gè)虛擬主機(jī)。
2015年， HTTP2.0 面世。 rfc7540
HTTP 2.0 中的幀將 HTTP/1.x 消息分成幀并嵌入到流 ( stream ) 中。數(shù)據(jù)幀和報(bào)頭幀分離，這將允許報(bào)頭壓縮。將多個(gè)流組合，這是一個(gè)被稱為多路復(fù)用 ( multiplexing ) 的過程，它允許更有效的底層 TCP 連接。
也就是說，流用來承載消息，消息又是有一個(gè)或多個(gè)幀組成。二進(jìn)制傳輸?shù)姆绞礁犹嵘藗鬏斝阅堋?每個(gè)數(shù)據(jù)流都以消息的形式發(fā)送，而消息又由一個(gè)或多個(gè)幀組成。 幀是流中的數(shù)據(jù)單位。
HTTP 幀現(xiàn)在對 Web 開發(fā)人員是透明的。在 HTTP/2 中，這是一個(gè)在 HTTP/1.1 和底層傳輸協(xié)議之間附加的步驟。 Web 開發(fā)人員不需要在其使用的 API 中做任何更改來利用 HTTP 幀；當(dāng)瀏覽器和服務(wù)器都可用時(shí)， HTTP/2 將被打開并使用。
之前我們提到，雖然 HTTP 1.1 有了長連接和管道化的技術(shù)，但是還是會(huì)存在 隊(duì)頭阻塞。而 HTTP 2.0 就解決了這個(gè)問題 HTTP/2 中新的二進(jìn)制分幀層突破了這些限制，實(shí)現(xiàn)了完整的請求和響應(yīng)復(fù)用：客戶端和服務(wù)器可以將 HTTP 消息分解為互不依賴的幀，然后交錯(cuò)發(fā)送，最后再在另一端把它們重新組裝起來。
如上圖所示，快照捕捉了同一個(gè)連接內(nèi)并行的多個(gè)數(shù)據(jù)流。 客戶端正在向服務(wù)器傳輸一個(gè) DATA 幀（數(shù)據(jù)流 5），與此同時(shí)，服務(wù)器正向客戶端交錯(cuò)發(fā)送數(shù)據(jù)流 1 和數(shù)據(jù)流 3 的一系列幀。因此，一個(gè)連接上同時(shí)有三個(gè)并行數(shù)據(jù)流。
將 HTTP 消息分解為獨(dú)立的幀，交錯(cuò)發(fā)送，然后在另一端重新組裝是 HTTP 2 最重要的一項(xiàng)增強(qiáng)。事實(shí)上，這個(gè)機(jī)制會(huì)在整個(gè)網(wǎng)絡(luò)技術(shù)棧中引發(fā)一系列連鎖反應(yīng)，從而帶來巨大的性能提升，讓我們可以： 1.并行交錯(cuò)地發(fā)送多個(gè)請求，請求之間互不影響。 2.并行交錯(cuò)地發(fā)送多個(gè)響應(yīng)，響應(yīng)之間互不干擾。 3.使用一個(gè)連接并行發(fā)送多個(gè)請求和響應(yīng)。 4.消除不必要的延遲和提高現(xiàn)有網(wǎng)絡(luò)容量的利用率，從而減少頁面加載時(shí)間。 5.不必再為繞過 HTTP/1.x 限制而做很多工作(比如精靈圖) ...
連接共享，即每一個(gè) request 都是是用作連接共享機(jī)制的。一個(gè) request 對應(yīng)一個(gè) id ，這樣一個(gè)連接上可以有多個(gè) request ，每個(gè)連接的 request 可以隨機(jī)的混雜在一起，接收方可以根據(jù) request 的 id 將 request 再歸屬到各自不同的服務(wù)端請求里面。
HTTP 1.1 和 HTTP 2.0 的對比，可以參考這個(gè) 網(wǎng)站 demo 演示
HTTP 1.1 演示如下：
HTTP2.0 演示如下：
使用 HTTP/1.1 和 HTTP/2 對于站點(diǎn)和應(yīng)用來說是透明的。擁有一個(gè)最新的服務(wù)器和新點(diǎn)的瀏覽器進(jìn)行交互就足夠了。只有一小部分群體需要做出改變，而且隨著陳舊的瀏覽器和服務(wù)器的更新，而不需 Web 開發(fā)者做什么，用的人自然就增加了
HTTPS 也是通過 HTTP 協(xié)議進(jìn)行傳輸信息，但是采用了 TLS 協(xié)議進(jìn)行了加密
對稱加密就是兩邊擁有相同的秘鑰，兩邊都知道如何將密文加密解密。但是因?yàn)閭鬏敂?shù)據(jù)都是走的網(wǎng)絡(luò)，如果將秘鑰通過網(wǎng)絡(luò)的方式傳遞的話，一旦秘鑰被截獲就沒有加密的意義的
非對稱加密
公鑰大家都知道，可以用公鑰加密數(shù)據(jù)。但解密數(shù)據(jù)必須使用私鑰，私鑰掌握在頒發(fā)公鑰的一方。首先服務(wù)端將公鑰發(fā)布出去，那么客戶端是知道公鑰的。然后客戶端創(chuàng)建一個(gè)秘鑰，并使用公鑰加密，發(fā)送給服務(wù)端。服務(wù)端接收到密文以后通過私鑰解密出正確的秘鑰
TLS 握手的過程采用的是非對稱加密
強(qiáng)緩存主要是由 Cache-control 和 Expires 兩個(gè) Header 決定的
Expires 的值和頭里面的 Date 屬性的值來判斷是否緩存還有效。 Expires 是 Web 服務(wù)器響應(yīng)消息頭字段，在響應(yīng) http 請求時(shí)告訴瀏覽器在過期時(shí)間前瀏覽器可以直接從瀏覽器緩存取數(shù)據(jù)，而無需再次請求。 Expires 的一個(gè)缺點(diǎn)就是，返回的到期時(shí)間是服務(wù)器端的時(shí)間，這是一個(gè)絕對的時(shí)間，這樣存在一個(gè)問題，如果客戶端的時(shí)間與服務(wù)器的時(shí)間相差很大（比如時(shí)鐘不同步，或者跨時(shí)區(qū)），那么誤差就很大。
Cache-Control 指明當(dāng)前資源的有效期，控制瀏覽器是否直接從瀏覽器緩存取數(shù)據(jù)還是重新發(fā)請求到服務(wù)器取數(shù)據(jù)。但是其設(shè)置的是一個(gè)相對時(shí)間。
指定過期時(shí)間： max-age 是距離請求發(fā)起的時(shí)間的秒數(shù)，比如下面指的是距離發(fā)起請求 31536000S 內(nèi)都可以命中強(qiáng)緩存
Cache-Control: max-age=31536000
復(fù)制代碼表示沒有緩存
Cache-Control: no-store
復(fù)制代碼有緩存但要重新驗(yàn)證
Cache-Control: no-cache
復(fù)制代碼私有和公共緩存
public 表示響應(yīng)可以被任何中間人（比如中間代理、 CDN 等緩存） 而 private 則表示該響應(yīng)是專用于某單個(gè)用戶的，中間人不能緩存此響應(yīng)，該響應(yīng)只能應(yīng)用于瀏覽器私有緩存中。
Cache-Control: private
Cache-Control: public
復(fù)制代碼驗(yàn)證方式：以下表示一旦資源過期（比如已經(jīng)超過 max-age ），在成功向原始服務(wù)器驗(yàn)證之前，緩存不能用該資源響應(yīng)后續(xù)請求
Cache-Control: must-revalidate
復(fù)制代碼Cache-control 優(yōu)先級(jí)比 Expires 優(yōu)先級(jí)高
以下是一個(gè) Cache-Control 強(qiáng)緩存的過程：
Last-Modified 表示本地文件最后修改日期，瀏覽器會(huì)在 request header 加上 If-Modified-Since （上次返回的 Last-Modified 的值），詢問服務(wù)器在該日期后資源是否有更新，有更新的話就會(huì)將新的資源發(fā)送回來
但是如果在本地打開緩存文件，就會(huì)造成 Last-Modified 被修改，所以在 HTTP / 1.1 出現(xiàn)了 ETag
Etag 就像一個(gè)指紋，資源變化都會(huì)導(dǎo)致 ETag 變化，跟最后修改時(shí)間沒有關(guān)系， ETag 可以保證每一個(gè)資源是唯一的。 If-None-Match 的 header 會(huì)將上次返回的 Etag 發(fā)送給服務(wù)器，詢問該資源的 Etag 是否有更新，有變動(dòng)就會(huì)發(fā)送新的資源回來
If-none-match 、 ETags 優(yōu)先級(jí)高于 If-Modified-Since、Last-Modified
第一次請求：
第二次請求相同網(wǎng)頁：
協(xié)商緩存，假如沒有改動(dòng)的話，返回 304 ，改動(dòng)了返回 200 資源
現(xiàn)在的200 (from cache) 已經(jīng)變成了 disk cache (磁盤緩存)和 memory cache (內(nèi)存緩存)兩種
上面提到 HTTP 緩存相關(guān)，但是很多有時(shí)候，我們希望上線之后需要更新線上資源。
web 開發(fā)者發(fā)明了一種被 Steve Souders 稱之為 revving 的技術(shù)。不頻繁更新的文件會(huì)使用特定的命名方式：在 URL 后面（通常是文件名后面）會(huì)加上版本號(hào)。
弊端：更新了版本號(hào)，所有引用這些的資源的地方的版本號(hào)都要改變
web 開發(fā)者們通常會(huì)采用自動(dòng)化構(gòu)建工具在實(shí)際工作中完成這些瑣碎的工作。當(dāng)?shù)皖l更新的資源（ js/css ）變動(dòng)了，只用在高頻變動(dòng)的資源文件（ html ）里做入口的改動(dòng)。
HTTP Cookie （也叫 Web Cookie 或?yàn)g覽器 Cookie ）是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)，它會(huì)在瀏覽器下次向同一服務(wù)器再發(fā)起請求時(shí)被攜帶并發(fā)送到服務(wù)器上。
Set-Cookie 響應(yīng)頭部和 Cookie 請求頭部
Set-Cookie: <cookie名>=<cookie值>
復(fù)制代碼會(huì)話期Cookie是最簡單的 Cookie ：瀏覽器關(guān)閉之后它會(huì)被自動(dòng)刪除，也就是說它僅在會(huì)話期內(nèi)有效。會(huì)話期 Cookie 不需要指定過期時(shí)間（ Expires ）或者有效期（ Max-Age ）。需要注意的是，有些瀏覽器提供了會(huì)話恢復(fù)功能，這種情況下即使關(guān)閉了瀏覽器，會(huì)話期 Cookie 也會(huì)被保留下來，就好像瀏覽器從來沒有關(guān)閉一樣
和關(guān)閉瀏覽器便失效的會(huì)話期 Cookie 不同，持久性 Cookie 可以指定一個(gè)特定的過期時(shí)間（ Expires ）或有效期（ Max-Age ）。
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
復(fù)制代碼標(biāo)記為 Secure 的 Cookie 只應(yīng)通過被 HTTPS 協(xié)議加密過的請求發(fā)送給服務(wù)端。
標(biāo)記為 Secure 的 Cookie 只應(yīng)通過被 HTTPS 協(xié)議加密過的請求發(fā)送給服務(wù)端。但即便設(shè)置了 Secure 標(biāo)記，敏感信息也不應(yīng)該通過 Cookie 傳輸，因?yàn)?Cookie 有其固有的不安全性， Secure 標(biāo)記也無法提供確實(shí)的安全保障
通過 JavaScript 的 Document.cookie API 是無法訪問帶有 HttpOnly 標(biāo)記的 cookie 。這么做是為了避免跨域腳本攻擊（ XSS ）
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
復(fù)制代碼Domain 和 Path 標(biāo)識(shí)定義了 Cookie 的作用域：即 Cookie 應(yīng)該發(fā)送給哪些 URL 。
Domain 標(biāo)識(shí)指定了哪些主機(jī)可以接受 Cookie 。如果不指定，默認(rèn)為當(dāng)前的主機(jī)（不包含子域名）。如果指定了 Domain ，則一般包含子域名。
例如，如果設(shè)置 Domain=mozilla.org ，則 Cookie 也包含在子域名中（如 developer.mozilla.org ）。
Path 標(biāo)識(shí)指定了主機(jī)下的哪些路徑可以接受 Cookie （該 URL 路徑必須存在于請求 URL 中）。以字符 %x2F ("/") 作為路徑分隔符，子路徑也會(huì)被匹配。
例如，設(shè)置 Path=/docs ，則以下地址都會(huì)匹配：
/docs
/docs/Web/
/docs/Web/HTTP
復(fù)制代碼SameSite Cookie 允許服務(wù)器要求某個(gè) cookie 在跨站請求時(shí)不會(huì)被發(fā)送，從而可以阻止跨站請求偽造攻擊
Set-Cookie: key=value; SameSite=Strict
復(fù)制代碼None Strict Lax
在新版本的瀏覽器（ Chrome 80 之后）中， SameSite 的默認(rèn)屬性是 SameSite=Lax 。換句話說，當(dāng) Cookie 沒有設(shè)置 SameSite 屬性時(shí)，將會(huì)視作 SameSite 屬性被設(shè)置為 Lax —— 這意味著 Cookies 將不會(huì)在當(dāng)前用戶使用時(shí)被自動(dòng)發(fā)送。如果想要指定 Cookies 在同站、跨站請求都被發(fā)送，那么需要明確指定 SameSite 為 None 。因?yàn)檫@一點(diǎn)，我們需要好好排查舊系統(tǒng)是否明確指定 SameSite ，以及推薦新系統(tǒng)明確指定 SameSite ，以兼容新舊版本 Chrome
更多 cookie 相關(guān)，可以查看我之前總結(jié)的一篇關(guān)于 cookie 的文章 前端須知的 Cookie 知識(shí)小結(jié)
跨域資源共享（ CORS ）是一種機(jī)制，它使用額外的 HTTP 頭告訴瀏覽器，讓運(yùn)行在一個(gè) origin ( domain ) 上的 web 應(yīng)用被準(zhǔn)許訪問來自不同源服務(wù)器上的指定的資源
跨域資源共享標(biāo)準(zhǔn)新增了一組 HTTP 首部字段，允許服務(wù)器聲明哪些源站通過瀏覽器有權(quán)限訪問哪些資源。
簡單請求（不會(huì)觸發(fā) CORS 的預(yù)檢請求）需要同時(shí)滿足以下三點(diǎn)：
以下為一個(gè)簡單請求的請求報(bào)文以及響應(yīng)報(bào)文
簡化以下：
請求首部字段 Origin 表明該請求來源于 http://foo.example
本例中，服務(wù)端返回的 Access-Control-Allow-Origin: * 表明，該資源可以被任意外域訪問。如果服務(wù)端僅允許來自 http://foo.example 的訪問，該首部字段的內(nèi)容如下：
Access-Control-Allow-Origin: http://foo.example
復(fù)制代碼Access-Control-Allow-Origin 應(yīng)當(dāng)為 * 或者包含由 Origin 首部字段所指明的域名。
規(guī)范要求，對那些可能對服務(wù)器數(shù)據(jù)產(chǎn)生副作用的 HTTP 請求方法。瀏覽器必須首先使用 OPTIONS 方法發(fā)起一個(gè)預(yù)檢請求（ preflight request ），從而獲知服務(wù)端是否允許該跨域請求。
服務(wù)器確認(rèn)允許之后，才發(fā)起實(shí)際的 HTTP 請求。在預(yù)檢請求的返回中，服務(wù)器端也可以通知客戶端，是否需要攜帶身份憑證（包括 Cookies 和 HTTP 認(rèn)證相關(guān)數(shù)據(jù)）
預(yù)檢請求中同時(shí)攜帶了下面兩個(gè)首部字段：
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
復(fù)制代碼首部字段 Access-Control-Request-Method 告知服務(wù)器，實(shí)際請求將使用 POST 方法。首部字段 Access-Control-Request-Headers 告知服務(wù)器，實(shí)際請求將攜帶兩個(gè)自定義請求首部字段： X-PINGOTHER 與 Content-Type 。服務(wù)器據(jù)此決定，該實(shí)際請求是否被允許。
預(yù)檢請求的響應(yīng)中，包括了以下幾個(gè)字段
Access-Control-Allow-Origin: http://foo.example
// 表明服務(wù)器允許客戶端使用 POST, GET 和 OPTIONS 方法發(fā)起請求
Access-Control-Allow-Methods: POST, GET, OPTIONS
// 表明服務(wù)器允許請求中攜帶字段 X-PINGOTHER 與 Content-Type
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
// 表明該響應(yīng)的有效時(shí)間為 86400 秒，也就是 24 小時(shí)。在有效時(shí)間內(nèi)，瀏覽器無須為同一請求再次發(fā)起預(yù)檢請求。
Access-Control-Max-Age: 86400
復(fù)制代碼一般而言，對于跨域 XMLHttpRequest 或 Fetch 請求，瀏覽器不會(huì)發(fā)送身份憑證信息。如果要發(fā)送憑證信息，需要設(shè)置 XMLHttpRequest 的某個(gè)特殊標(biāo)志位。比如說 XMLHttpRequest 的 withCredentials 標(biāo)志設(shè)置為 true ，則可以發(fā)送 cookie 到服務(wù)端。
對于附帶身份憑證的請求，服務(wù)器不得設(shè)置 Access-Control-Allow-Origin 的值為“*”。 這是因?yàn)檎埱蟮氖撞恐袛y帶了 Cookie 信息，如果 Access-Control-Allow-Origin 的值為“*”，請求將會(huì)失敗。而將 Access-Control-Allow-Origin 的值設(shè)置為 http://foo.example ，則請求將成功執(zhí)行。
CORS 涉及到的請求和響應(yīng)頭如下： HTTP 響應(yīng)首部字段
HTTP 請求首部字段
Origin
Access-Control-Request-Method
Access-Control-Request-Headers有感興趣的朋友可以關(guān)注一下我的公眾號(hào)：前端維他命，不定時(shí)更新優(yōu)秀文章。
項(xiàng)目上需要用到多語言，項(xiàng)目設(shè)計(jì)語言選擇是通過header傳遞的，如果直接用平時(shí)location.href下載并無法實(shí)現(xiàn)這個(gè)效果，然后在網(wǎng)上查閱了一些資料，可以通過流處理來實(shí)現(xiàn)下載，代碼如下
downloadFile(){
let timestamp = new Date().getTime(); //時(shí)間戳
let url =XXXXXXXXXXXX;
let xmlResquest = new XMLHttpRequest();
xmlResquest.open("GET", url, true);
xmlResquest.setRequestHeader("Authorization", "bearer" + this.token); //token驗(yàn)證
xmlResquest.responseType = "blob";
xmlResquest.onload = function(oEvent) { //接口響應(yīng)后的處理
var content = xmlResquest.response; // 組裝a標(biāo)簽
let elink = document.createElement("a");// 設(shè)置下載文件名
elink.download = "track-kml-" + timestamp + ".kml";
elink.style.display = "none";
let blob = new Blob([content]);
elink.href = URL.createObjectURL(blob);
document.body.appendChild(elink);
elink.click();
document.body.removeChild(elink);
URL.revokeObjectURL(blob); //釋放對象
};
xmlResquest.send();
}本著不懂就學(xué)的原則，查閱了部分不懂的方法，以下資料來源MDN
URL.createObjectURL() 靜態(tài)方法會(huì)創(chuàng)建一個(gè) DOMString，其中包含一個(gè)表示參數(shù)中給出的對象的URL。這個(gè) URL 的生命周期和創(chuàng)建它的窗口中的 document 綁定。這個(gè)新的URL 對象表示指定的 File 對象或 Blob 對象。
內(nèi)存管理
在每次調(diào)用 createObjectURL() 方法時(shí)，都會(huì)創(chuàng)建一個(gè)新的 URL 對象，即使你已經(jīng)用相同的對象作為參數(shù)創(chuàng)建過。當(dāng)不再需要這些 URL 對象時(shí)，每個(gè)對象必須通過調(diào)用 URL.revokeObjectURL() 方法來釋放。瀏覽器會(huì)在文檔退出的時(shí)候自動(dòng)釋放它們，但是為了獲得最佳性能和內(nèi)存使用狀況，你應(yīng)該在安全的時(shí)機(jī)主動(dòng)釋放掉它們。
XMLHttpRequest.responseType 屬性是一個(gè)枚舉類型的屬性，返回響應(yīng)數(shù)據(jù)的類型。它允許我們手動(dòng)的設(shè)置返回?cái)?shù)據(jù)的類型。如果我們將它設(shè)置為一個(gè)空字符串，它將使用默認(rèn)的"text"類型。
在工作環(huán)境(Work Environment)中將responseType的值設(shè)置為"document"通常會(huì)被忽略. 當(dāng)將responseType設(shè)置為一個(gè)特定的類型時(shí)，你需要確保服務(wù)器所返回的類型和你所設(shè)置的返回值類型是兼容的。那么如果兩者類型不兼容呢?恭喜你，你會(huì)發(fā)現(xiàn)服務(wù)器返回的數(shù)據(jù)變成了null，即使服務(wù)器返回了數(shù)據(jù)。還有一個(gè)要注意的是，給一個(gè)同步請求設(shè)置responseType會(huì)拋出一個(gè)InvalidAccessError 的異常。
responseType支持以下幾種值：
值 | 描述 |
"" | 將 responseType 設(shè)為空字符串與設(shè)置為"text"相同， 是默認(rèn)類型 （實(shí)際上是 DOMString）。 |
"arraybuffer" | response 是一個(gè)包含二進(jìn)制數(shù)據(jù)的 JavaScript ArrayBuffer 。 |
"blob" | response 是一個(gè)包含二進(jìn)制數(shù)據(jù)的 Blob 對象 。 |
"document" | response 是一個(gè) HTML Document 或 XML XMLDocument ，這取決于接收到的數(shù)據(jù)的 MIME 類型。請參閱 HTML in XMLHttpRequest 以了解使用 XHR 獲取 HTML 內(nèi)容的更多信息。 |
"json" | response 是一個(gè) JavaScript 對象。這個(gè)對象是通過將接收到的數(shù)據(jù)類型視為 JSON 解析得到的。 |
"text" | response 是包含在 DOMString 對象中的文本。 |
"moz-chunked-arraybuffer" | 與"arraybuffer"相似，但是數(shù)據(jù)會(huì)被接收到一個(gè)流中。使用此響應(yīng)類型時(shí)，響應(yīng)中的值僅在 progress 事件的處理程序中可用，并且只包含上一次響應(yīng) progress 事件以后收到的數(shù)據(jù)，而不是自請求發(fā)送以來收到的所有數(shù)據(jù)。 在 progress 事件處理時(shí)訪問 response 將返回到目前為止收到的數(shù)據(jù)。在 progress 事件處理程序之外訪問， response 的值會(huì)始終為 null 。 |
"ms-stream" | response 是下載流的一部分；此響應(yīng)類型僅允許下載請求，并且僅受Internet Explorer支持。 |
近又快到了金三銀四的好日子了，有一天，小龍找到我說，小輝哥，我想跳槽了。原來公司加薪無望，目前只有 7.5k，12 薪，也沒有年終獎(jiǎng)，想換個(gè)環(huán)境試試，但是好像今年疫情之下，招聘市場并沒有往年那么熱門，目前覺得自己還沒有辦法去大廠。
在自己努力無果之后，想讓我?guī)退僮饕幌拢易稍兞艘幌滦↓埬壳暗那闆r，然后幫他物色了5、6個(gè)崗位，然后讓他自己挑一個(gè)比較喜歡的：
小龍目前的情況：
1. 自考本科。
2. 24 歲。
3. 1 年多一點(diǎn)工作經(jīng)驗(yàn)（我改為了 1 年半）。
4. 目前薪資 7.5，加上年終和績效可以到 9.5。
5. 有 vue 一年多的使用經(jīng)驗(yàn)，全家桶基本會(huì)。
6. webpack 用過，但是不熟，都是別人幫弄好的。
7. 自我感覺良好，對于自己的學(xué)習(xí)能力覺得還算可以，js，css，es6基礎(chǔ)尚可。
8. nodejs 較弱，只停留在 CRUD 階段，玩過一下 express做 blog。
9. 平時(shí)使用 git ，不過公司使用 svn。
10. 對待 996 還算可以認(rèn)可，不過最好還是希望不要 996
這是他挑選的目標(biāo)公司職位的招聘 jd 如下：
月薪：12-20k·12薪
經(jīng)驗(yàn)要求：1-3年
學(xué)歷：本科
工作地區(qū)：廣州天河區(qū) XXXX
工作職責(zé)：
1、負(fù)責(zé)web服務(wù)端，內(nèi)部系統(tǒng)后端業(yè)務(wù)程序開發(fā)
2、負(fù)責(zé)web前端開發(fā)
3、參與現(xiàn)場調(diào)試
4、參與后端業(yè)務(wù)和底層模塊接口開發(fā)及調(diào)試
工作要求 1：
1、熟悉vue框架，熟悉elementUI界面控件庫
2、扎實(shí)的javascript語言，html，css基礎(chǔ)；
3、熟悉使用linux基本應(yīng)用和nodejs；
4、有前后端分離的項(xiàng)目實(shí)踐經(jīng)驗(yàn)，能使用上述技術(shù)搭建豐富交互的前端界面并和后端進(jìn)行http，tcp的通訊；
5、熟悉typescript優(yōu)先。
工作要求2：
1、做事認(rèn)真負(fù)責(zé)，有良好的編碼風(fēng)格；
2、良好的溝通與表達(dá)能力，有團(tuán)隊(duì)協(xié)作精神。
3、有良好的學(xué)習(xí)方法和較強(qiáng)的學(xué)習(xí)能力；
4、喜歡迎難而上，愛好挑戰(zhàn)困難；
5、有框架思維和多人合作編碼能力。
我跟小龍說，這個(gè) jd 對你目前來說會(huì)有點(diǎn)難度，不過如果你真的很想達(dá)到的話，也是可以的，花點(diǎn)心思，努努力就行了。 他說，沒問題，成了請你吃飯哈~
接下來我會(huì)用詳細(xì)說明一下小龍到底經(jīng)歷了什么。
第一步：先讓我們分析一下這個(gè)招聘要求jd
第二步：確定需要突破的求職目標(biāo)
第三步：快速提升自身技能滿足要求
第四步：快速準(zhǔn)備面試
第五步：如何高效投簡歷
第六步：如何優(yōu)秀通過面試
第七步：獲得 offer
招聘要求也叫jd，英文是 job description，翻譯為工作描述也可以
一個(gè) jd 其實(shí)不簡單：
一般一份工作是 1-3 年左右，所以說，你這是在選擇一份未來 1-3 年時(shí)間消費(fèi)，一份工作不僅要工資待遇適合你，工作節(jié)奏也要適合你，而且最好要跟你未來職業(yè)規(guī)劃沾邊才行，這樣你的時(shí)間才會(huì)更有意義，你就可以用 1-3 年時(shí)間就可以頂別人 3-5 年了。
月薪：12-20k·12薪，一般能在招聘要求里面寫這么清晰的公司，素質(zhì)都相對比較好，因?yàn)樘拐\是一家公司很重要的一個(gè)品質(zhì)。
漫天開價(jià)，落地還錢。我們拿一個(gè)最低的，再拿一個(gè)最高的，取一個(gè)平均值，（12+20）/2 =16，所以這個(gè)崗位的預(yù)期月薪工資一般都可以達(dá)到 16K，不過也要注意，他是 12 薪的，也就是說，一年只有 12 個(gè)月薪資，而有很多公司，一年可以發(fā) 13，14 甚至 16 個(gè)月，這里就是區(qū)別了。不過也可能對方?jīng)]寫出來，在現(xiàn)場面試的時(shí)候咨詢 hr 就行了。
總體來說也算不錯(cuò)。要知道小龍之前是 7.5K 的。
但不排除有些公司不按套路出牌~
有句老話說，工作經(jīng)驗(yàn)寫 3 年，上班一年半，加班一年半，就是這么硬核，哈哈哈~
所以這里 1-3 年其實(shí)無傷大雅。只要不要偏離太夸張即可，例如你是應(yīng)屆畢業(yè)生，寫工作 2 年，這樣很容易穿幫的，不建議。
小龍工作一年半了，寫 2 年也是非常合理的，如果準(zhǔn)備充分，寫個(gè) 3 年也問題不大。
一般中小公司是不卡學(xué)歷，除非比較特殊要求的， 例如國企，事業(yè)單位，或者特殊崗位，例如算法，人工智能AI類。
有些時(shí)候，公司急用人，也可以從本科下降到大專， 這個(gè)也是可以理解的。
不過如果是大公司就不行，大公司必要的招聘考核指標(biāo)就必須要本科，有些甚至是 985 以上的本科才行。
目前小龍雖然不是統(tǒng)招本科，但是好歹也是自考本科，也是國家承認(rèn)的。
一般人很少留意這個(gè)公司地點(diǎn)，有些朋友雖然找到一個(gè)公司，待遇還不錯(cuò)，但是離自己家十萬八千里遠(yuǎn)，每次上下班都像坐長途車一樣，一天至少浪費(fèi)了好幾個(gè)小時(shí)在通勤上，你以為你工資高了，就是賺錢了，但是其實(shí)不然，你只不過是犧牲了其他東西，例如時(shí)間，精力。
在《通往財(cái)富自由之路》里，李笑來老師提到一個(gè)概念，就是注意力>時(shí)間>金錢。錢，是價(jià)值相對較低的，如果能拿他換到時(shí)間(進(jìn)而換到你的注意力，讓你可以在你關(guān)注的領(lǐng)域里得到成長),那才是真正有價(jià)值的。
我的建議就是，在財(cái)力允許的條件下，盡可能的讓工作的地方離家近一點(diǎn)。
小龍?zhí)暨@個(gè)企業(yè)離他宿舍還不算遠(yuǎn)，另外我發(fā)現(xiàn)這個(gè)軟件園位于市中心，附近有比較多的不同大大小小的互聯(lián)網(wǎng)企業(yè)，我建議他如果可以的話，就搬到這個(gè)軟件園附近來住，一方面上班更近，一方面萬一以后跳槽， 也不用折騰搬家多次，搬家的辛苦誰干誰知道~
一個(gè)是看公司是不是朝陽行業(yè)，另外一個(gè)是看公司業(yè)務(wù)是否跟時(shí)代脫節(jié)。
例如煤炭行業(yè)就是夕陽行業(yè)，不是朝陽行業(yè)。
例如柯達(dá)膠卷業(yè)務(wù)被數(shù)碼相機(jī)取代，nokia非智能手機(jī)被蘋果智能手機(jī)取代，這個(gè)就是公司業(yè)務(wù)根本時(shí)代脫節(jié)了。
一般來說，可以多留意一下社會(huì)龍頭企業(yè)關(guān)注的東西，例如華為，騰訊，阿里，還有就是關(guān)注以下國家政策，發(fā)展芯片，發(fā)展 5G，人工智能等等。
小龍?zhí)舻倪@個(gè)企業(yè)做的是智能制造業(yè)和醫(yī)療器械相關(guān)的，屬于今年國家重點(diǎn)推廣領(lǐng)域，起碼目前來看還可以，這些內(nèi)容可以在企業(yè)官網(wǎng)找到。
一個(gè)公司的招聘 jd 的工作職責(zé)和工作要求寫的水平可以知道該公司的技術(shù)水平或者工作、職場氛圍不會(huì)太差，
例如工作要求就寫精通：
精通HTML5/CSS3/JS/TypeScript/Less/SVG/Canvas等前端技術(shù)
精通 Vue/Angular/React/BootStrap至少兩種前端框架就算是阿里 p7 也不敢寫精通，外行看熱鬧，內(nèi)行看門道。這種一看就是不懂技術(shù)的人寫湊數(shù)或者領(lǐng)導(dǎo)為了高大上而寫的。
而且如果職場政治氛圍（pmp）太壓抑，不利于新人成長。
再來看看小龍?zhí)舻倪@個(gè)公司，總體感覺還是比較實(shí)在，不會(huì)太過夸張，也沒有用精通的字樣：
工作職責(zé)：
1、負(fù)責(zé)web服務(wù)端，內(nèi)部系統(tǒng)后端業(yè)務(wù)程序開發(fā)
2、負(fù)責(zé)web前端開發(fā)
3、參與現(xiàn)場調(diào)試
4、參與后端業(yè)務(wù)和底層模塊接口開發(fā)及調(diào)試
工作要求 1：
1、熟悉vue框架，熟悉elementUI界面控件庫
2、扎實(shí)的javascript語言，html，css基礎(chǔ)；
3、熟悉使用linux基本應(yīng)用和nodejs；
4、有前后端分離的項(xiàng)目實(shí)踐經(jīng)驗(yàn)，能使用上述技術(shù)搭建豐富交互的前端界面并和后端進(jìn)行http，tcp的通訊；
5、熟悉typescript優(yōu)先。
工作要求2：
1、做事認(rèn)真負(fù)責(zé)，有良好的編碼風(fēng)格；
2、良好的溝通與表達(dá)能力，有團(tuán)隊(duì)協(xié)作精神。
3、有良好的學(xué)習(xí)方法和較強(qiáng)的學(xué)習(xí)能力；
4、喜歡迎難而上，愛好挑戰(zhàn)困難；
5、有框架思維和多人合作編碼能力。我們來分析一下：
經(jīng)過分析之后，我們可以確認(rèn)：
必須點(diǎn)滿足了是 12K，加分點(diǎn)滿足了是 16k。
這些就是我們需要短時(shí)間突破的目標(biāo)。
由于考慮的是短時(shí)間突破，沒有算加分題的內(nèi)容。
是不是突然有種，原來如此，不外如是的感覺，啊哈哈，戰(zhàn)略和戰(zhàn)術(shù)同樣重要的。
為了避免小龍擔(dān)心目標(biāo)太大而完成不了，所以我將大目標(biāo)拆分成小目標(biāo)，這個(gè)小目標(biāo)也是根據(jù)小龍自己覺得可以才定的，有些人 1 天可以看完一本書，有些人則需要 2 天，視乎每個(gè)人的情況。
這就是：拆分大目標(biāo)，直至到你覺得可以快速完成的小目標(biāo)級(jí)別為止
小目標(biāo)還有一個(gè)好處，每次完成一個(gè)小目標(biāo)，不會(huì)太難，可以給你形成正反饋，讓你可以漸進(jìn)式進(jìn)步，增強(qiáng)信心，從而堅(jiān)持下。
同時(shí)小目標(biāo)也是你的前進(jìn)之路的地圖，每個(gè)小目標(biāo)之間的聯(lián)系構(gòu)成了大目標(biāo)，只要沒有偏離小目標(biāo)目標(biāo)，大目標(biāo)就不會(huì)偏離。
我再次跟小龍確認(rèn)過，他目前的情況：
我?guī)退鸱至艘幌履繕?biāo)，當(dāng)時(shí)做了一個(gè)xmind，方便全局的看。
這里是需要看的材料：
在一開始是沒辦法知道這個(gè)大目標(biāo)需要多久能夠完成的，也不知道這個(gè)小目標(biāo)需要多久才能完成。只能通過跟自己約定每天，每周的完成程度。
雖然說小龍自我感知每天晚上會(huì)有 2 小時(shí)，每周六日有 8 小時(shí)是可以學(xué)習(xí)的，但是時(shí)間這個(gè)量化指標(biāo)不是很準(zhǔn)，有時(shí)候走神了，或者狀態(tài)不好，時(shí)間到了，但是工作沒做好。
這里我跟小龍加了一個(gè)儀式，讓他每次完成一個(gè)小目標(biāo)之前，發(fā)一個(gè)宣誓內(nèi)容給我，內(nèi)容如下：我是為了 XXX 而努力的，我會(huì)在 XXX 時(shí)間內(nèi)，完成 XXX的學(xué)習(xí)，并且整理好筆記，我不糊弄自己，務(wù)必認(rèn)真完成。
這是一種契約，跟自己的一個(gè)契約。契約的力量是很大的。
另外我需要他在日歷本上打鉤，記錄自己今天是否已經(jīng)完成了學(xué)習(xí)。 這是同樣是一種契約。
不要過分高估自己的自律性，要客觀評(píng)價(jià)自己的拖延癥！
好記性不如爛筆頭，大腦的記憶需要多次反復(fù)刺激才會(huì)印象深刻，看一次，讀一次，想一次，思考一次，寫一次，你的記憶比別人就相當(dāng)于高了 4 倍以上，因?yàn)橐话闳酥粫?huì)看一次而已。
筆記的內(nèi)容不是簡單寫，會(huì)將某個(gè)知識(shí)點(diǎn)的的原理和實(shí)際例子都寫一遍，并且會(huì)問一下自己，是不是真的懂了，邏輯是不是真的通了。
小龍同學(xué)有一個(gè)好處就是，每次總結(jié)都有很長的筆記，大概3000 字一篇，不過不好的地方就是有時(shí)候筆記花費(fèi)時(shí)間有點(diǎn)太長。
想想我自己以前上學(xué)，寫個(gè) 800 字文章都覺得天都塌了，偶買狗的！
筆記基本都是用 markdown 寫，自動(dòng)排版，方便寫，方便看。如果過分追求格式和樣子，反而失去了本來記筆記的意義。
這是他寫過的筆記之一：
實(shí)際記錄到一共用了 20+10+6+10+6+6+6=64 個(gè)小時(shí)，而且這個(gè)是計(jì)算純時(shí)間，實(shí)際消耗的時(shí)間其實(shí)是大于 64 個(gè)小時(shí)的，因?yàn)槿瞬荒苊馑祝袝r(shí)候計(jì)劃趕不上變化，按照公式，大概是80 個(gè)小時(shí)左右。
每天 2 小時(shí)，每個(gè)星期六和日是 8 小時(shí)，大概一個(gè)星期能花 26 個(gè)小時(shí)學(xué)習(xí)，當(dāng)時(shí)我朋友的朋友學(xué)完并且在我檢查確認(rèn)大體已經(jīng)掌握知識(shí)的結(jié)果后，最終大概用了4 個(gè)星期左右（有些時(shí)候有特殊時(shí)期中斷了一下）。
不過也是需要建立在我強(qiáng)而有力的監(jiān)督之下~啊哈哈哈。
毛時(shí)間vs純時(shí)間
毛時(shí)間：你所花在工作上的時(shí)間統(tǒng)稱為毛時(shí)間。
純時(shí)間：你真正專注于工作的時(shí)間稱為純時(shí)間。
一般來說，純時(shí)間=毛時(shí)間的 80%**
這是我補(bǔ)充之前的 xmind 圖的最終結(jié)果
至此，基本上小龍已經(jīng)能夠觸達(dá)這個(gè) offer 的門檻了，底氣不會(huì)那么虛了。
github 倉庫是一個(gè)優(yōu)秀程序員的名片。 --BY 魯X
github 倉庫可以存放你的代碼或者你的 blog 學(xué)習(xí)心得筆記，比起虛無縹緲的說，能看得到的東西會(huì)更加讓人產(chǎn)生信任感。
一個(gè)有內(nèi)涵的 github 倉庫或者 blog 可以讓你在面試官的第一印象里面加很多分的。
首因效應(yīng)由美國心理學(xué)家洛欽斯首先提出的，也叫首次效應(yīng)、優(yōu)先效應(yīng)或第一印象效應(yīng)，指交往雙方形成的第一次印象對今后交往關(guān)系的影響，也即是“先入為主”帶來的效果。
如果一個(gè)人在初次見面時(shí)給人留下良好的印象，那么人們就愿意和他接近，彼此也能較快地取得相互了解，并會(huì)影響人們對他以后一系列行為和表現(xiàn)的解釋。
反之，對于一個(gè)初次見面就引起對方反感的人，即使由于各種原因難以避免與之接觸，人們也會(huì)對之很冷淡，在極端的情況下，甚至?xí)谛睦砩虾蛯?shí)際行為中與之產(chǎn)生對抗?fàn)顟B(tài)。
這個(gè)倉庫不能只是一個(gè)單純的裝飾物，最好可以將一個(gè)你覺得有意思的項(xiàng)目代碼放進(jìn)去，然后在面試的過程中給面試官邊看邊講解，更加容易讓對方認(rèn)可你的能力。同理，blog 的文章也不能是全部轉(zhuǎn)載或者流水賬，要有體現(xiàn)出你認(rèn)真 coding 的內(nèi)味才行。
人靠衣裝，佛靠金裝。這個(gè)就是你的金裝之一。
可以看看阮老師早期的 github，都是寫了很多 demo 之類的。
網(wǎng)上有大量的面經(jīng)和面試題分享，我們要找熱門的，因?yàn)槊嬖嚬僖彩瞧胀ㄈ耍豢赡芴焯熳约涸祛}目，他也是參考網(wǎng)上的。
我們需要有題目和答案的是最好的，這樣方便我們對照。
刷題有一個(gè)技巧，就是不斷重復(fù) 3-5 遍，不斷加深印象。有時(shí)候刷題不一定要知道題目的前因后果，在有限的時(shí)間里面，盡最大可能的讓你大腦記憶多次才是王道。
另外我們這次先排除算法題，畢竟我們不是面向 1 線大廠，對算法要求不高，有選擇性放棄，集中戰(zhàn)斗力在其他更重要的地方。
刷題在面試前 2天來做即可。
最后我根據(jù)自己的經(jīng)驗(yàn)和小龍目前的情況，給他整理了適合他的題目，并且讓他至少刷 3 次，最后我通過抽查題目回答來確認(rèn)他短期刷題的記憶已經(jīng)足夠了。
一份優(yōu)秀的簡歷是為了讓別人快速了解你的。如果你的簡歷寫不好，即使你是天才也會(huì)蒙塵，社會(huì)的規(guī)則就是這樣，人們知道的是用“是金子總會(huì)發(fā)光”來安慰自己，但往往忽略了你起碼要讓你的光進(jìn)到別人的眼睛里面才行。
這是標(biāo)準(zhǔn)的簡歷格式：（記得不要搞亂順序）
例如這樣：
基本簡歷格式有了，但是不夠閃亮，那我們要怎么填充最主要的項(xiàng)目經(jīng)驗(yàn)內(nèi)容來讓你的簡歷閃閃發(fā)光呢？
項(xiàng)目經(jīng)驗(yàn)貴精不貴多，一般一個(gè)最核心的項(xiàng)目就夠了， 如果一個(gè)都不能讓面試官覺得你很優(yōu)秀，那么再來多一個(gè)也于事無補(bǔ)，這種時(shí)候不需要量變引起質(zhì)變，除非你的能力可以在 2 個(gè)項(xiàng)目里面都分別突出你的優(yōu)秀，不然寫一個(gè)就夠了。
阮一峰老師給出了一些指導(dǎo)意見：
我在這個(gè)基礎(chǔ)上補(bǔ)充了一下，結(jié)合鼎鼎大名的 STAR 方法來操作的。
STAR 法則其實(shí)是英文單詞的縮寫，完整的單詞應(yīng)該為situation、task、action和result。對應(yīng)的中文為情境、任務(wù)、行動(dòng)和結(jié)果。 STAR 法則通過故事的形式，表現(xiàn)出自己分析闡述問題的清晰性、條理性和邏輯性。
Situation: 事情是在什么情況下發(fā)生
Task: 你是如何明確你的任務(wù)
Action: 針對這樣的情況分析，你采用了什么行動(dòng)方式
Result: 結(jié)果怎樣，在這樣的情況下你學(xué)習(xí)到了什么
我們用這個(gè)大綱來寫：
一般人是這樣寫的：（平淡，索然無味，沒啥意思，千篇一律）
我負(fù)責(zé)的項(xiàng)目是一個(gè)xxx 電商平臺(tái)的后臺(tái)管理系統(tǒng)，使用的技術(shù)棧主vue框架全家桶系列和 egg 來做 bff 中間層，包括axios，router，vuex，element-ui框架開發(fā)，
大部分功能是基于element-ui進(jìn)行業(yè)務(wù)邏輯組件的二次封裝，主要有訂單管理，微信退款，權(quán)限角色登陸等，接口部分又 egg 作為中間層進(jìn)行代理處理。
這個(gè)項(xiàng)目前端和 nodejs方面由我負(fù)責(zé)，前端團(tuán)隊(duì)成員是 3 人。
這是改寫后的:
項(xiàng)目標(biāo)題：電商 xxx后臺(tái)管理系統(tǒng)前后端分離改造項(xiàng)目
項(xiàng)目簡介：
1. 這是一個(gè)負(fù)責(zé)年?duì)I業(yè)額五百萬的 xxx 業(yè)務(wù)的后臺(tái)管理系統(tǒng)。
2. 這個(gè)項(xiàng)目原來是純 jsp 的模式開發(fā)的后臺(tái)管理系統(tǒng)，隨著業(yè)務(wù)發(fā)展，系統(tǒng)變得越來越龐大，該系統(tǒng)開發(fā)周期長，上線后bug 很多，維護(hù)修復(fù)問題時(shí)間長，系統(tǒng)處理響應(yīng)速度很慢，導(dǎo)致業(yè)務(wù)受到了很大影響。
3. 該項(xiàng)目原來并沒有自動(dòng)化集成測試和自動(dòng)化部署，都是人工手動(dòng)測試和部署。
4. 在投入很多開發(fā)資源支持下，依然沒有辦法很好改善，與公司討論后決定將系統(tǒng)進(jìn)行前后端架構(gòu)分離，前端使用 vue 進(jìn)行 spa 單頁面開發(fā)，并且使用 nodejs 作為 bff 層，后端只負(fù)責(zé)提供接口并且實(shí)行自動(dòng)化集成開發(fā)，自動(dòng)化集成測試和自動(dòng)化部署模式。
項(xiàng)目成果：
1. 系統(tǒng)性能提高了：
a. 頁面響應(yīng)速度從原來等待 5-6秒完成頁面打開到現(xiàn)在3 秒內(nèi)完成。
b. 因?yàn)閱雾撁鎽?yīng)用，很多邏輯表單處理可以合并到前端交互處理，業(yè)務(wù)人員操作系統(tǒng)的時(shí)間大大減少，例如以前往往需要 2-3 個(gè)頁面跳轉(zhuǎn)完成處理，現(xiàn)在在一個(gè)頁面即可完成，系統(tǒng)的易用性也大幅度提高，得到了業(yè)務(wù)部的一致好評(píng)。
2. 系統(tǒng)更穩(wěn)定了：
a. 上線后 bug 的數(shù)量比之前減少了70%，原來單功能的 bug 數(shù)量在 10 -15 左右，現(xiàn)在單功能 bug 數(shù)量是 5 以下。
3. 開發(fā)資源的投入減少了，開發(fā)周期縮短了：
a. 原來后端開發(fā)人員 7 人，測試人員 3 人，現(xiàn)在只需要后端開發(fā)人員 2 個(gè)，測試人員 1 個(gè)，前端開發(fā)人員 2 個(gè)，nodejs 1 個(gè)。
b. 原來平均單功能上線周期是 10 天，現(xiàn)在為平均單功能上線周期是 3 天。
項(xiàng)目方案：
1. 采用vue 作為主要的 spa 單頁面架構(gòu)模式，將頁面的功能改為模塊和組件來維護(hù)，基于 elementsUI 做基礎(chǔ)樣式和功能的條件下，設(shè)計(jì)和開發(fā)自己業(yè)務(wù)的組件和模塊，進(jìn)行統(tǒng)一組件化，模塊化維護(hù)樣式和功能，避免重復(fù)開發(fā)。
2. 樣式使用 less 代替 stylus，less 在語法上更加標(biāo)準(zhǔn)，代碼結(jié)構(gòu)更加清晰，在多人協(xié)作和復(fù)雜樣式情況下提高可維護(hù)性。
3. 采用 egg 做為 bff 層，主要是因?yàn)楫?dāng)時(shí)后端的接口質(zhì)量相對較差，為了避免前端界面過多兼容接口邏輯處理而影響了性能和維護(hù)性的問題而加入的，另外在系統(tǒng)技術(shù)棧過渡的時(shí)候，采用局部業(yè)務(wù)邏輯分階段更新，保證系統(tǒng)平滑過渡而避免對業(yè)務(wù)造成影響。
4. 使用 jenkins +webpack 進(jìn)行前端和 nodejs 的代碼自動(dòng)化集成，自動(dòng)化測試和自動(dòng)化部署。
5. 改造時(shí)間歷時(shí) 3 個(gè)月，分 3 個(gè)階段完成：
a. 第一階段先建立自動(dòng)化處理基礎(chǔ)建設(shè)，并且對項(xiàng)目組人員進(jìn)行指導(dǎo)，首先讓團(tuán)隊(duì)達(dá)成一致的想法，并且建立相對應(yīng)的開發(fā)規(guī)范。
b. 第一階段先使用非重點(diǎn)業(yè)務(wù)功能來進(jìn)行改造，目的是試驗(yàn) nodejs 和 vue 的開發(fā)模式被開發(fā)人員熟練，并且提前將實(shí)際落地的遇到的問題解決掉，為下一步核心業(yè)務(wù)過渡做準(zhǔn)備。
c. 第二階段完成全平臺(tái)業(yè)務(wù)逐步過渡，每過渡一個(gè)業(yè)務(wù)都需要進(jìn)行全面測試確認(rèn)沒問題后，再開始進(jìn)行下一個(gè)業(yè)務(wù)過渡。
我的職責(zé)：
我負(fù)責(zé)這個(gè)項(xiàng)目的前端架構(gòu)設(shè)計(jì)，代碼的review，代碼和組件的規(guī)范設(shè)計(jì)，核心模塊的編寫，并且跟業(yè)務(wù)和產(chǎn)品進(jìn)行溝通，管理和協(xié)調(diào)安排開發(fā)資源，帶來團(tuán)隊(duì)成員有計(jì)劃進(jìn)行項(xiàng)目開發(fā)工作。
項(xiàng)目技術(shù)棧：
vue 2.5 版本，axios、vue-router、vuex、elements-UI、echart，Mocha、co-mocha、webpack、egg
工作經(jīng)歷其實(shí)就是項(xiàng)目經(jīng)歷的省略版，只要寫好項(xiàng)目經(jīng)歷，進(jìn)行縮短簡略就可以得到工作經(jīng)歷了。
專業(yè)技能，其實(shí)就是你項(xiàng)目經(jīng)歷用到的技術(shù)棧在增加或者減少就行了。
因?yàn)槲覀兪擎i定目標(biāo)的投簡歷，我們知道這家公司，所以不需要海投。
但是我們要知道他們公司的 hr 是怎么篩選簡歷的，從而思考我們的簡歷怎么可以脫穎而出。
這里需要我們做一下假設(shè)，假設(shè)你是 hr，你會(huì)怎么收集簡歷，怎么過濾簡歷，怎么閱讀簡歷？
一般 hr 收集簡歷的操作：
一般招聘渠道有以下幾個(gè)：
一般 hr 過濾簡歷的操作：
一般 hr 閱讀簡歷的操作：
有見及此，可以大大提高簡歷被閱讀，并且約談面試的機(jī)會(huì)的：
如果是在 boss 直聘的話，需要先上傳附件簡歷，然后再跟 hr 聊的時(shí)候可以發(fā)送過去
如果選擇的是自己發(fā)送郵件的方式的話，郵件主題要注明清楚：“三年開發(fā)經(jīng)驗(yàn)應(yīng)聘資深前端工程師_姓名”
郵件格式如下（注意對齊）：
張先生，
您好，我是XXX。我對貴公司的 XXX 職位很有興趣，附件里面是我的簡歷，
如果您對我的個(gè)人履歷感興趣，可以隨時(shí)與我聯(lián)系。謝謝。
感謝您的閱讀，謝謝。
應(yīng)聘者：XXX
2021 年 1 月 29 日
公司郵箱可以在對方官網(wǎng)里面找，例如這個(gè)：
那么，面試機(jī)會(huì)來了，你一般約面試要約 1 天之后，這樣讓你容易放松一些，避免一上來就約隔天面試，過度緊張導(dǎo)致影響發(fā)揮。
我讓小龍約面試是 2 天后。
一般來說，一個(gè)基本面試流程是這樣的：
大公司，例如人數(shù)往往超過 300 人以上的企業(yè)，流程基本一致，但是比較長。可能會(huì)有四面甚至五，六面的情況：
中小型公司，人數(shù)往往低于 300人的企業(yè)，流程就比較簡：
中小公司比較注重實(shí)際實(shí)際項(xiàng)目技能，主要看你是否可以馬上開始工作，對于一些基礎(chǔ)知識(shí)并不太關(guān)注（不代表啥都不會(huì)），而主要關(guān)注你的項(xiàng)目細(xì)節(jié)，大公司，本身內(nèi)部有比較完善培訓(xùn)流程和分工，所以對基礎(chǔ)知識(shí)，算法都比較在意，雖然也會(huì)重視你的項(xiàng)目細(xì)節(jié)，但是他們更關(guān)注你的基礎(chǔ)。
小龍這個(gè)公司我定義為中廠，屬于中小廠類，所以我們將面試的重點(diǎn)放在項(xiàng)目細(xì)節(jié)上。
軍事領(lǐng)域里面有一個(gè)東西叫沙盤模擬，戰(zhàn)爭沙盤模擬推演通過紅、藍(lán)兩軍在戰(zhàn)場上的對抗與較量，發(fā)現(xiàn)雙方戰(zhàn)略戰(zhàn)術(shù)上存在的問題，提高指揮員的作戰(zhàn)能力，模擬推演跨越了通過實(shí)兵軍演檢驗(yàn)與培養(yǎng)高級(jí)將領(lǐng)的巨大成本障礙和時(shí)空限制，受到世界各國的普遍運(yùn)用。
而我們安排模擬面試的原因就是因?yàn)槲覀円崆把菥殻崆爸揽赡馨l(fā)生的任何情況，以便達(dá)到在真正面試現(xiàn)場減少出錯(cuò)，達(dá)到成功獲得 offer 的終極目標(biāo)。
我們現(xiàn)在來幫小龍模擬整個(gè)面試流程：
大概整個(gè)流程是這樣的，可能還有一些細(xì)節(jié)每個(gè)人有點(diǎn)區(qū)別。
這個(gè)模擬面試?yán)锩嬗泻芏嗟胤叫枰⒁饣蛘咛崆皽?zhǔn)備，我這里挑一些比較重點(diǎn)的來說：
有些人會(huì)說，我們是跟面試官攀關(guān)系，要謙虛，要謙卑，要奉承對方，以此來換得對方的高興，從而增加通過的成功率。
我認(rèn)為，謙虛謙卑是對的，但是如果只是說只有這些，是不足夠的，首先你要充滿自信，讓別人覺得你是有把握的，不能做賊心虛。
良好的自信心，一方面需要靠自身本事，另外一方面是靠自己的心理建設(shè)，要時(shí)刻跟自己說，這只是一個(gè)面試，僅僅是一個(gè)面試。
相信自己可以的，信任自己過往的努力和不放棄。
世界不曾虧欠每一個(gè)努力的人。
因?yàn)槭滓蛐?yīng)，我們需要有一個(gè)優(yōu)秀的自我介紹去提升面試官對你的第一印象，而好的第一印象會(huì)貫穿你的整個(gè)面試過程，這是開門第一炮，必須打好。
這里每個(gè)人都不一樣，但是有些原則是要遵守的：
例如，這個(gè)自我介紹可能已經(jīng)比很多人的都要好了，但是沒辦法大幅度增加面試官的第一印象，我覺得是不足夠的：
我有過2年前端開發(fā)經(jīng)驗(yàn)經(jīng)驗(yàn)，開發(fā)過的項(xiàng)目有A、B、C，這幾個(gè)項(xiàng)目里面我最有印象的是 c，這是一個(gè) xxx 業(yè)務(wù)系統(tǒng)的子系統(tǒng)，承載了年?duì)I業(yè)額 500w 的系統(tǒng)，這里我用到技術(shù)棧是 vue，xxxx。
我稍微修改一下：
我有過2年前端開發(fā)經(jīng)驗(yàn)經(jīng)驗(yàn)，開發(fā)過的項(xiàng)目有A、B、C，這幾個(gè)項(xiàng)目里面我最有印象的是 c，這是一個(gè) xxx 業(yè)務(wù)系統(tǒng)的子系統(tǒng)，本來只是一個(gè)小系統(tǒng)，沒人想維護(hù)，最終分到了我的頭上。
剛開始我發(fā)現(xiàn)它代碼耦合很嚴(yán)重，很多代碼都是是粗獷式開發(fā)，改一個(gè)地方，很多地方莫名其妙出錯(cuò)了，一個(gè)小系統(tǒng)的維護(hù)居然花了我好幾天時(shí)間，然后我就生氣了。
我對代碼有些潔癖，通過幾天時(shí)間我梳理了這個(gè)系統(tǒng)的整個(gè)前端邏輯，然后通過封裝和模塊組合，分層和解耦強(qiáng)聯(lián)系業(yè)務(wù)邏輯，用一周時(shí)間，幾乎重寫了這個(gè)系統(tǒng)的前端，并且在重要的地方加入適量的注釋和文檔，整個(gè)系統(tǒng)的維護(hù)難度一下子就變得簡單了很多。
后來這個(gè)系統(tǒng)成長為了年?duì)I業(yè)額 500w 的主業(yè)務(wù)系統(tǒng)，得到了公司的重視，我順便還得了個(gè)xx年度最佳開發(fā)者獎(jiǎng)。
另外還有一個(gè)技巧，我們可以通過自我介紹產(chǎn)生的第一印象去引導(dǎo)面試官的問題方向，這樣就更容易在自己熟悉的方向上進(jìn)行問題回答，更容易增加面試成功的概率。
一般來說對方會(huì)根據(jù)你的面試題結(jié)果來咨詢你，然后會(huì)根據(jù)你簡歷上寫的項(xiàng)目信息來有選擇性發(fā)問。
在簡歷編寫期間，使用 STAR 方法可以更清楚的梳理你的價(jià)值。但是在實(shí)際面試的時(shí)候，你還要補(bǔ)充上 PDCA 方法來讓對方知道你的綜合價(jià)值。
面試官更希望知道你遇到這些問題時(shí)候是怎么思考和實(shí)踐的，因?yàn)檫@樣才能更全面的知道一個(gè)人是否可以獨(dú)立完成工作。
PDCA四個(gè)英文字母及其在PDCA循環(huán)中所代表的含義如下：
1、 P（Plan）--計(jì)劃，確定方針和目標(biāo)，確定活動(dòng)計(jì)劃；
2、 D（Do）--執(zhí)行，實(shí)地去做，實(shí)現(xiàn)計(jì)劃中的內(nèi)容；
3、 C（Check）--檢查，總結(jié)執(zhí)行計(jì)劃的結(jié)果，注意效果，找出問題；
4、 A（Action）--行動(dòng)，對總結(jié)檢查的結(jié)果進(jìn)行處理，成功的經(jīng)驗(yàn)加以肯定并適當(dāng)推廣、標(biāo)準(zhǔn)化；失敗的教訓(xùn)加以總結(jié)，以免重現(xiàn)，未解決的問題放到下一個(gè)PDCA循環(huán)。
每一件事情先做計(jì)劃，計(jì)劃完了以后去實(shí)施，實(shí)施的過程中進(jìn)行檢查，檢查結(jié)果以后，再把檢查的結(jié)果進(jìn)行改進(jìn)，進(jìn)行實(shí)施，進(jìn)行改善，這樣把沒有改善的問題又放到下一個(gè)循環(huán)里面去，就形成一個(gè)一個(gè)的PDCA循環(huán)。
例如：之前寫的xxx 電商平臺(tái)的后臺(tái)管理系統(tǒng)，對方根據(jù) pdca 的方法來問，你是怎么做這個(gè)計(jì)劃的，怎么做階段完成，你印象最深刻的是哪個(gè)技術(shù)難點(diǎn)，然后你是怎么解決的？
這些都要準(zhǔn)備好，才能百戰(zhàn)百勝。
有幾個(gè)原則可以參考一下：
領(lǐng)導(dǎo)面主要是看你這個(gè)人的工作態(tài)度，人品，還有就是是否能夠融入團(tuán)隊(duì)，可塑性（容易管理）是否足夠強(qiáng)。
一些比較經(jīng)典：
提前準(zhǔn)備好對應(yīng)的答案之余，還要準(zhǔn)備一些反問對方，因?yàn)閷Ψ绞穷I(lǐng)導(dǎo)，領(lǐng)導(dǎo)喜歡被別人請教，從而增加自己的虛榮感。
例如：
一些比較經(jīng)典的：
提前準(zhǔn)備好對應(yīng)的答案就好了，例如：
需要注意的是，基本過了技術(shù)面之后，hr 這關(guān)比較容易，回答不能冒進(jìn)，要中規(guī)中矩，不要以為過了技術(shù)面就穩(wěn)了。
如果技術(shù)很喜歡你，但是 hr 不喜歡你，一樣也是過不了。
因?yàn)檫@樣既可以讓你知道多一些對方公司的事，方便你做最后的決策，另外還可以讓你對方感受到了你的認(rèn)真態(tài)度，也可以讓對方更容易滿足（被人請教），從而提高獲得 offer 的概率。
第一次模擬面試，出錯(cuò)百出，這很正常，太久沒面試或者沒怎么留意面試的工作的人都會(huì)這樣。小龍的第一次模擬面試，我發(fā)現(xiàn)他連身份證都沒準(zhǔn)備~我給他一梭子之后他終于開始認(rèn)真了~
把模擬面試遇到的問題進(jìn)行復(fù)盤，記錄下來，然后再模擬多一次，一般模擬 3 次左右就效果最好了。
盡可能地減少失誤，如果遇到一個(gè)特別好的offer 的話，如果面試發(fā)揮失常是個(gè)人原因?qū)е碌模蔷秃軅辛恕?/span>
萬事俱備，去面試咯。
到了面試那天，小龍還是有點(diǎn)緊張，不過他說比之前好多了，之前是超級(jí)緊張，現(xiàn)在心里面多少有點(diǎn)譜了，（畢竟模擬面試了幾次，套路都知道）
不過結(jié)果還不錯(cuò)，成功斬獲了一個(gè)至少是 11k 的 offer，不過我覺得 12k 也很穩(wěn)的。
其實(shí)拿 offer 也是很簡單的嘛~~啊哈哈哈
看到這里，必須雙手奉上相關(guān)文中提到過的資料，大家見好就收吧~
希望可以幫到你，我是小輝哥。
因?yàn)樾r(shí)候不努力學(xué)編程，畢業(yè)去做了網(wǎng)管，以為跟互聯(lián)網(wǎng) IT 沾邊，后來發(fā)現(xiàn)其實(shí)做開發(fā)才是，所以又努力掰了回來，期間刷過盤子，修過電腦，寫過 php，玩過 java，舞過前端開發(fā)，練過項(xiàng)目經(jīng)理，弄過產(chǎn)品經(jīng)理，官職最強(qiáng)上至技術(shù)總監(jiān)，收入從月入 800 到50k，我發(fā)現(xiàn)，百萬年薪真的很難的，不過我畢竟也走到這里了，還不錯(cuò)。
我聽說很多年輕（中青年）人對現(xiàn)在的環(huán)境感到很浮躁、很焦慮、很擔(dān)憂，所以我就來看看能不能幫上忙~
*請認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
