2019前端面試系列——HTTP、瀏覽器面試題

瀏覽器存儲的方式有哪些

特性 cookie localStorage sessionStorage indexedDB
數(shù)據(jù)生命周期 一般由服務(wù)器生成，可以設(shè)置過期時間 除非被清理，否則一直存在 頁面關(guān)閉就清理 除非被清理，否則一直存在
數(shù)據(jù)存儲大小 4K 5M 5M 無限
與服務(wù)端通信 每次都會攜帶在 header，中，對于請求性能影響 不參與 不參與 不參與
補充：cookie 原本并不是用來儲存的，而是用來與服務(wù)端通信的，需要存取請自行封裝 api。
而 localStorage 則自帶 getItem 和 setItem 方法，使用很方便。

localStorage 注意點：

* localStorage 只能存字符串，存取 JSON 數(shù)據(jù)需配合 JSON.stringify() 和 JSON.parse()
* 遇上禁用 setItem 的瀏覽器，需要使用 try...catch 捕獲異常
對前后端跨域可以說一下嗎？如何解決跨域的？

九種跨域方式實現(xiàn)原理 <https://juejin.im/post/5c23993de51d457b8c1f4ee1>
如何跨域我們已經(jīng)明白了，如果這樣問：瀏覽器沒有同源策略會有什么危險？是不是有點瞬間懵逼？
下面是摘選的事例，參考：AJAX跨域訪問被禁止的原因
<https://blog.csdn.net/hcrw01/article/details/84289109>

假設(shè)有一個黑客叫做小黑，他從網(wǎng)上抓取了一堆美女圖做了一個網(wǎng)站，每日訪問量爆表。
為了維護網(wǎng)站運行，小黑掛了一張收款碼，覺得網(wǎng)站不錯的可以適當資助一點，可是無奈伸手黨太多，小黑的網(wǎng)站入不敷出。

于是他非常生氣的在網(wǎng)頁中寫了一段js代碼，使用ajax向淘寶發(fā)起登陸請求，因為很多數(shù)人都訪問過淘寶，所以電腦中存有淘寶的cookie，不需要輸入賬號密碼直接就自動登錄了，然后小黑在ajax回調(diào)函數(shù)中解析了淘寶返回的數(shù)據(jù)，得到了很多人的隱私信息，轉(zhuǎn)手一賣，小黑的網(wǎng)站終于盈利了。
如果跨域也可以發(fā)送AJAX請求的話，小黑就真的獲取到了用戶的隱私并成功獲利了?。?！

瀏覽器 cookie 和 session 的認識。

session 是基于 cookie 實現(xiàn)的。cookie 保存在客戶端瀏覽器中，而 session 保存在服務(wù)器上。cookie
機制是通過檢查客戶身上的“通行證”來確定客戶身份的話，那么 session 機制就是通過檢查服務(wù)器上的“客戶明細表”來確認客戶身份。session
相當于程序在服務(wù)器上建立的一份客戶檔案，客戶來訪的時候只需要查詢客戶檔案表就可以了。

cookie 和 session 的區(qū)別：

* 存在的位置：
cookie 存在于客戶端，臨時文件夾中；session 存在于服務(wù)器的內(nèi)存中，一個 session 域?qū)ο鬄橐粋€用戶瀏覽器服務(wù)
* 安全性
cookie 是以明文的方式存放在客戶端的，安全性低，可以通過一個加密算法進行加密后存放；session 存放于服務(wù)器的內(nèi)存中，所以安全性好
* 生命周期(以 20 分鐘為例)
cookie 的生命周期是累計的，從創(chuàng)建時，就開始計時，20 分鐘后 cookie 生命周期結(jié)束；
session 的生命周期是間隔的，從創(chuàng)建時，開始計時如在 20 分鐘，沒有訪問 session，那么 session 生命周期被銷毀。但是，如果在 20
分鐘內(nèi)（如在第 19 分鐘時）訪問過 session，那么，將重新計算 session 的生命周期。關(guān)機會造成 session 生命周期的結(jié)束，但是對
cookie 沒有影響
* 訪問范圍
cookie 為多個用戶瀏覽器共享；session 為一個用戶瀏覽器獨享
輸入URL發(fā)生什么？

* DNS 域名解析（域名解析成ip地址，走UTP協(xié)議，因此不會有握手過程）：瀏覽器將 URL 解析出相對應(yīng)的服務(wù)器的 IP 地址（1. 本地瀏覽器的
DNS 緩存中查找 2. 再向系統(tǒng)DNS緩存發(fā)送查詢請求 3. 再向路由器DNS緩存 4. 網(wǎng)絡(luò)運營商DNS緩存 5. 遞歸搜索），并從 url 中解析出端口號
* 瀏覽器與目標服務(wù)器建立一條 TCP 連接（三次握手）
* 瀏覽器向服務(wù)器發(fā)送一條 HTTP 請求報文
* 服務(wù)器返回給瀏覽器一條 HTTP 響應(yīng)報文
* 瀏覽器進行渲染
* 關(guān)閉 TCP 連接（四次揮手）
瀏覽器渲染的步驟

* HTML 解析出 DOM Tree
* CSS 解析出 Style Rules
* 兩者關(guān)聯(lián)生成 Render Tree
* Layout（布局）根據(jù) Render Tree 計算每個節(jié)點的信息
*
Painting 根據(jù)計算好的信息進行渲染整個頁面

瀏覽器解析文檔的過程中，如果遇到 script 標簽，會立即解析腳本，停止解析文檔（因為 JS 可能會改變 DOM 和 CSS,如果繼續(xù)解析會造成浪費）。
如果是外部 script, 會等待腳本下載完成之后在繼續(xù)解析文檔?，F(xiàn)在 script 標簽增加了 defer 和 async 屬性，腳本解析會將腳本中改變
DOM 和 css 的地方> 解析出來，追加到 DOM Tree 和 Style Rules 上

頁面渲染優(yōu)化

基于對渲染過程的了解，推薦一下優(yōu)化：

* HTML 文檔結(jié)構(gòu)層次盡量少，最好不深于 6 層
* 腳本盡量放后邊，避免組織頁面加載
* 少量首屏樣式可以放在便簽內(nèi)
* 樣式結(jié)構(gòu)層次盡量簡單
* 腳本減少 DOM 操作，減少回流，盡量緩存訪問 DOM 的樣式信息
* 盡量減少 JS 修改樣式，可以通過修改 class 名的方式解決
* 減少 DOM 查找，緩存 DOM 查找結(jié)果
* 動畫在屏幕外或頁面滾動時，盡量停止
強制緩存和協(xié)商緩存

*
強制緩存是我們在第一次請求資源時在 http 響應(yīng)頭設(shè)置一個過期時間，在時效內(nèi)都將直接從瀏覽器進行獲取，常見的 http 響應(yīng)頭字段如
Cache-Control 和 Expires

*
協(xié)商緩存是我們通過 http 響應(yīng)頭字段 etag 或者 Last-Modified 等判斷服務(wù)器上資源是否修改，如果修改則從服務(wù)器重新獲取，如果未修改則
304 指向瀏覽器緩存中進行獲取

GET 和 POST 請求的區(qū)別

* GET 參數(shù)通過 url 傳遞，POST 放在 body 中。（http 協(xié)議規(guī)定，url 在請求頭中，所以大小限制很?。?
* GET 請求在 url 中傳遞的參數(shù)是有長度限制的，而 POST 沒有。原因見上↑↑↑
* GET 在瀏覽器回退時是無害的，而 POST 會再次提交請求
* GET 請求會被瀏覽器主動 cache，而 POST 不會，除非手動設(shè)置
* GET 比 POST 更不安全，因為參數(shù)直接暴露在 url 中，所以不能用來傳遞敏感信息
* 對參數(shù)的數(shù)據(jù)類型，GET 只接受 ASCII字符，而 POST 沒有限制
* GET 請求只能進行 url(x-www-form-urlencoded)編碼，而 POST 支持多種編碼方式
* GET 產(chǎn)生一個 TCP 數(shù)據(jù)包；POST 產(chǎn)生兩個 TCP 數(shù)據(jù)包。對于 GET 方式的請求，瀏覽器會把 http 的 header 和 data
一并發(fā)送出去，服務(wù)器響應(yīng)200（返回數(shù)據(jù)）。而對于 POST，瀏覽器先發(fā)送 header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送
data，服務(wù)器響應(yīng)200 ok（返回數(shù)據(jù)）
HTTP1.0 / 1.1 / 2.0 及HTTPS

你需要知道的HTTP常識 <https://juejin.im/post/59c1d946518825396f4f6343>
可能是全網(wǎng)最全的http面試答案 <https://juejin.im/post/5d032b77e51d45777a126183>
如何優(yōu)雅的談?wù)揌TTP／1.0／1.1／2.0 <https://www.jianshu.com/p/52d86558ca57>

HTTP1.1 是當前使用最為廣泛的HTTP協(xié)議

* HTTP1.0 和 HTTP1.1 相比
*
緩存處理：在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity
tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
*
帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用：HTTP1.0中，存在一些浪費帶寬的現(xiàn)象，例如客戶端只是需要某個對象的一部分，而服務(wù)器卻將整個對象送過來了，并且不支持斷點續(xù)傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial
Content），這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接。
*
錯誤通知的管理：在HTTP1.1中新增了24個錯誤狀態(tài)響應(yīng)碼，如409（Conflict）表示請求的資源與資源的當前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個資源被永久性的刪除。
*
Host頭處理：在HTTP1.0中認為每臺服務(wù)器都綁定一個唯一的IP地址，因此，請求消息中的URL并沒有傳遞主機名（hostname）。但隨著虛擬主機技術(shù)的發(fā)展，在一臺物理服務(wù)器上可以存在多個虛擬主機（Multi-homed
Web
Servers），并且它們共享一個IP地址。HTTP1.1的請求消息和響應(yīng)消息都應(yīng)支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400
Bad Request）。
* 長連接：HTTP
1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲，在HTTP1.1中默認開啟Connection：
keep-alive，一定程度上彌補了HTTP1.0每次請求都要創(chuàng)建連接的缺點。通過設(shè)置http的請求頭部和應(yīng)答頭部，保證本次數(shù)據(jù)請求結(jié)束之后，下一次請求仍可以重用這一通道，避免重新握手。
* HTTP2.0 和 HTTP1.X 相比
* 新的二進制格式（Binary
Format）：HTTP1.x的解析是基于文本?；谖谋緟f(xié)議的格式解析存在天然缺陷，文本的表現(xiàn)形式有多樣性，要做到健壯性考慮的場景必然很多，二進制則不同，只認0和1的組合?；谶@種考慮HTTP2.0的協(xié)議解析決定采用二進制格式，實現(xiàn)方便且健壯。
*
多路復(fù)用（MultiPlexing）：即連接共享，即每一個request都是是用作連接共享機制的。一個request對應(yīng)一個id，這樣一個連接上可以有多個request，每個連接的request可以隨機的混雜在一起，接收方可以根據(jù)request的
id將request再歸屬到各自不同的服務(wù)端請求里面。
* header壓縮：如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，而且每次都要重復(fù)發(fā)送，HTTP2.0使用了專門為首部壓縮而設(shè)計的
HPACK 算法，使用encoder來減少需要傳輸?shù)膆eader大小，通訊雙方各自cache一份header
fields表，既避免了重復(fù)header的傳輸，又減小了需要傳輸?shù)拇笮　?
* 服務(wù)端推送（server
push）：服務(wù)端推送能把客戶端所需要的資源伴隨著index.html一起發(fā)送到客戶端，省去了客戶端重復(fù)請求的步驟。正因為沒有發(fā)起請求，建立連接等操作，所以靜態(tài)資源通過服務(wù)端推送的方式可以極大地提升速度。例如我的網(wǎng)頁有一個sytle.css的請求，在客戶端收到sytle.css數(shù)據(jù)的同時，服務(wù)端會將sytle.js的文件推送給客戶端，當客戶端再次嘗試獲取sytle.js時就可以直接從緩存中獲取到，不用再發(fā)請求了。
* HTTPS 與 HTTP 相比
* HTTPS協(xié)議需要到CA申請證書，一般免費證書很少，需要交費。
* HTTP協(xié)議運行在TCP之上，所有傳輸?shù)膬?nèi)容都是明文，HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上，所有傳輸?shù)膬?nèi)容都經(jīng)過加密的。
* HTTP和HTTPS使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
* HTTPS可以有效的防止運營商劫持，解決了防劫持的一個大問題。
HTTPS
介紹：HTTPS在傳輸數(shù)據(jù)之前需要客戶端（瀏覽器）與服務(wù)端（網(wǎng)站）之間進行一次握手，在握手過程中將確立雙方加密傳輸數(shù)據(jù)的密碼信息。TLS/SSL協(xié)議不僅僅是一套加密傳輸?shù)膮f(xié)議，TLS/SSL中使用了非對稱加密，對稱加密以及HASH算法。

握手過程的簡單描述如下：

1.瀏覽器將自己支持的一套加密規(guī)則發(fā)送給網(wǎng)站。
2.網(wǎng)站從中選出一組加密算法與HASH算法，并將自己的身份信息以證書的形式發(fā)回給瀏覽器。證書里面包含了網(wǎng)站地址，加密公鑰，以及證書的頒發(fā)機構(gòu)等信息。
3.獲得網(wǎng)站證書之后瀏覽器要做以下工作：
??????a.
驗證證書的合法性（頒發(fā)證書的機構(gòu)是否合法，證書中包含的網(wǎng)站地址是否與正在訪問的地址一致等），如果證書受信任，則瀏覽器欄里面會顯示一個小鎖頭，否則會給出證書不受信的提示。
??????b. 如果證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數(shù)的密碼，并用證書中提供的公鑰加密。
??????c. 使用約定好的HASH計算握手消息，并使用生成的隨機數(shù)對消息進行加密，最后將之前生成的所有信息發(fā)送給網(wǎng)站。
4.網(wǎng)站接收瀏覽器發(fā)來的數(shù)據(jù)之后要做以下的操作：
??????a. 使用自己的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發(fā)來的握手消息，并驗證HASH是否與瀏覽器發(fā)來的一致。
??????b. 使用密碼加密一段握手消息，發(fā)送給瀏覽器。

5.瀏覽器解密并計算握手消息的HASH，如果與服務(wù)端發(fā)來的HASH一致，此時握手過程結(jié)束，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機密碼并利用對稱加密算法進行加密。


這里瀏覽器與網(wǎng)站互相發(fā)送加密的握手消息并驗證，目的是為了保證雙方都獲得了一致的密碼，并且可以正常的加密解密數(shù)據(jù)。其中非對稱加密算法用于在握手過程中加密生成的密碼，對稱加密算法用于對真正傳輸?shù)臄?shù)據(jù)進行加密，而HASH算法用于驗證數(shù)據(jù)的完整性。由于瀏覽器生成的密碼是整個數(shù)據(jù)加密的關(guān)鍵，因此在傳輸?shù)臅r候使用了非對稱加密算法對其加密。非對稱加密算法會生成公鑰和私鑰，公鑰只能用于加密數(shù)據(jù)，因此可以隨意傳輸，而網(wǎng)站的私鑰用于對數(shù)據(jù)進行解密，所以網(wǎng)站都會非常小心的保管自己的私鑰，防止泄漏。TLS握手過程中如果有任何錯誤，都會使加密連接斷開，從而阻止了隱私信息的傳輸。正是由于HTTPS非常的安全，攻擊者無法從中找到下手的地方，于是更多的是采用了假證書的手法來欺騙客戶端，從而獲取明文的信息。

介紹下304過程

a. 瀏覽器請求資源時首先命中資源的Expires 和 Cache-Control，Expires
受限于本地時間，如果修改了本地時間，可能會造成緩存失效，可以通過Cache-control:
max-age指定最大生命周期，狀態(tài)仍然返回200，但不會請求數(shù)據(jù)，在瀏覽器中能明顯看到from cache字樣。

b.
強緩存失效，進入?yún)f(xié)商緩存階段，首先驗證ETagETag可以保證每一個資源是唯一的，資源變化都會導(dǎo)致ETag變化。服務(wù)器根據(jù)客戶端上送的If-None-Match值來判斷是否命中緩存。

c.
協(xié)商緩存Last-Modify/If-Modify-Since階段，客戶端第一次請求資源時，服務(wù)服返回的header中會加上Last-Modify，Last-modify是一個時間標識該資源的最后修改時間。再次請求該資源時，request的請求頭中會包含If-Modify-Since，該值為緩存之前返回的Last-Modify。服務(wù)器收到If-Modify-Since后，根據(jù)資源的最后修改時間判斷是否命中緩存。



HTTP 狀態(tài)碼

* 1xx（臨時響應(yīng)）表示臨時響應(yīng)并需要請求者繼續(xù)執(zhí)行操作的狀態(tài)碼
* 100 - 繼續(xù) 請求者應(yīng)當繼續(xù)提出請求。服務(wù)器返回此代碼表示已收到請求的第一部分，正在等待其余部分
* 101 - 切換協(xié)議 請求者已要求服務(wù)器切換協(xié)議，服務(wù)器已確認并準備切換
* 2xx（成功）表示成功處理了請求的狀態(tài)碼
* 200 - 成功 服務(wù)器已經(jīng)成功處理了請求。通常，這表示服務(wù)器提供了請求的網(wǎng)頁
* 201 - 已創(chuàng)建 請求成功并且服務(wù)器創(chuàng)建了新的資源
* 202 - 已接受 服務(wù)器已接受請求，但尚未處理
* 203 - 非授權(quán)信息 服務(wù)器已經(jīng)成功處理了請求，但返回的信息可能來自另一來源
* 204 - 無內(nèi)容 服務(wù)器成功處理了請求，但沒有返回任何內(nèi)容
* 205 - 重置內(nèi)容 服務(wù)器成功處理了請求，但沒有返回任何內(nèi)容
* 206 - 部分內(nèi)容 服務(wù)器成功處理了部分GET請求
* 3xx（重定向）表示要完成請求，需要進一步操作；通常，這些狀態(tài)代碼用來重定向
* 300 - 多種選擇 針對請求，服務(wù)器可執(zhí)行多種操作。服務(wù)器可根據(jù)請求者（user agent）選擇一項操作，或提供操作列表供請求者選擇
* 301 - 永久移動 請求的網(wǎng)頁已永久移動到新位置。服務(wù)器返回此響應(yīng)（對GET或HEAD請求的響應(yīng)）時，會自動將請求者轉(zhuǎn)到新位置
* 302 - 臨時移動 服務(wù)器目前從不同位置的網(wǎng)頁響應(yīng)請求，但請求者應(yīng)繼續(xù)使用原有位置來進行以后的請求
* 303 - 查看其它位置 請求者應(yīng)當對不同的位置使用單獨的GET請求來檢索響應(yīng)時，服務(wù)器返回此代碼
* 304 - 未修改 自上次請求后，請求的網(wǎng)頁未修改過。服務(wù)器返回此響應(yīng)，不會返回網(wǎng)頁的內(nèi)容
* 305 - 使用代理 請求者只能使用代理訪問請求的網(wǎng)頁。如果服務(wù)器返回此響應(yīng)，還表示請求者應(yīng)使用代理
* 307 - 臨時性重定向 服務(wù)器目前從不同位置的網(wǎng)頁響應(yīng)請求，但請求者應(yīng)繼續(xù)使用原有的位置來進行以后的請求
* 4xx（請求錯誤）這些狀態(tài)碼表示請求可能出錯，妨礙了服務(wù)器的處理
* 400 - 錯誤請求 服務(wù)器不理解請求的語法
* 401 - 未授權(quán) 請求要求身份驗證。對于需要登錄的網(wǎng)頁，服務(wù)器可能返回此響應(yīng)
* 403 - 禁止 服務(wù)器拒絕請求
* 404 - 未找到 服務(wù)器找不到請求的網(wǎng)頁
* 405 - 方法禁用 禁用請求中指定的方法
* 406 - 不接受 無法使用請求的內(nèi)容特性響應(yīng)請求的網(wǎng)頁
* 407 - 需要代理授權(quán) 此狀態(tài)碼與401（未授權(quán)）類似，但指定請求者應(yīng)當授權(quán)使用代理
* 408 - 請求超時 服務(wù)器等候請求時發(fā)生超時
* 409 - 沖突 服務(wù)器在完成請求時發(fā)生沖突。服務(wù)器必須在響應(yīng)中包含有關(guān)沖突的信息
* 410 - 已刪除 如果請求的資源已永久刪除，服務(wù)器就會返回此響應(yīng)
* 411 - 需要有效長度 服務(wù)器不接受不含有效內(nèi)容長度標頭字段的請求
* 412 - 未滿足前提條件 服務(wù)器未滿足請求者在請求者設(shè)置的其中一個前提條件
* 413 - 請求實體過大 服務(wù)器無法處理請求，因為請求實體過大，超出了服務(wù)器的處理能力
* 414 - 請求的URI過長 請求的URI（通常為網(wǎng)址）過長，服務(wù)器無法處理
* 415 - 不支持媒體類型 請求的格式不受請求頁面的支持
* 416 - 請求范圍不符合要求 如果頁面無法提供請求的范圍，則服務(wù)器會返回此狀態(tài)碼
* 417 - 未滿足期望值 服務(wù)器未滿足“期望”請求標頭字段的要求

* 5xx（服務(wù)器錯誤）這些狀態(tài)碼表示服務(wù)器在嘗試處理請求時發(fā)生內(nèi)部錯誤。這些錯誤可能是服務(wù)器本身的錯誤，而不是請求出錯
* 500 - 服務(wù)器內(nèi)部錯誤 服務(wù)器遇到錯誤，無法完成請求
* 501 - 尚未實施 服務(wù)器不具備完成請求的功能。例如，服務(wù)器無法識別請求方法時可能會返回此代碼
* 502 - 錯誤網(wǎng)關(guān) 服務(wù)器作為網(wǎng)關(guān)或代理，從上游服務(wù)器無法收到無效響應(yīng)
* 503 - 服務(wù)器不可用 服務(wù)器目前無法使用（由于超載或者停機維護）。通常，這只是暫時狀態(tài)
* 504 - 網(wǎng)關(guān)超時 服務(wù)器作為網(wǎng)關(guān)代理，但是沒有及時從上游服務(wù)器收到請求
* 505 - HTTP版本不受支持 服務(wù)器不支持請求中所用的HTTP協(xié)議版本
Web性能優(yōu)化

嗨，送你一張Web性能優(yōu)化地圖
<https://mp.weixin.qq.com/s?__biz=MzUxMTcwOTM4Mg==&mid=2247483962&idx=1&sn=f9337ad983c6303811eb43d07d9f23d5&chksm=f96edb93ce195285943211e645cc683989826abdaaa8ab0b073a20761369ed04843c835c50b7#rd>


2019前端面試系列——CSS面試題 <https://www.cnblogs.com/chenwenhao/p/11217590.html>
2019前端面試系列——JS面試題 <https://www.cnblogs.com/chenwenhao/p/11253403.html>
2019前端面試系列——JS高頻手寫代碼題 <https://www.cnblogs.com/chenwenhao/p/11294541.html>
2019前端面試系列——Vue面試題 <https://www.cnblogs.com/chenwenhao/p/11258895.html>
2019前端面試系列——HTTP、瀏覽器面試題 <https://www.cnblogs.com/chenwenhao/p/11267238.html>

• ? 上一篇：微信小程序項目總結(jié)-記賬小程序（包括后端）
• ? 下一篇：爬取微博用戶公開信息，分析為周杰倫打榜的夕陽紅老年團，告訴你他們真實年齡！