整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
輯導語：在上下滾動頁面時，除了出現吸頂，還會出現吸底、錨點等情況，那么這些都是在滾動頁面時需要注意的控件。本文作者結合最近工作中的實際項目，對于滑動時的吸頂、錨點規則方式的總結心得，一起來學習下吧。
上下滾動頁面時，除了出現吸頂，還會出現吸底、錨點等情況，這些都是在滾動頁面時需要注意的控件。
結合最近工作中的實際項目，Cassie將滑動用到的場景進行了提煉，總結出這份控件設計規范，一起來學習吸底、錨點是如何在APP以及PC端應用的吧～
PC端及移動端的底部有一些操作欄，比如表單的填寫操作或者支付按鈕的放置，移動端底部還會有全局的導航欄，這些會占用一定的空間，可以根據使用場景靈活選擇吸底方式。
需要注意吸底的是具有操作價值的內容，吸底元素包括操作按鈕、 引導操作、移動端的導航欄…
PC端在表單內容較多、查看內容文章、需要引導用戶操作比如支付等場景下，當用戶需滑動查看更多內容，可將操作類按鈕吸底，需要吸底的內容可以根據布局調整顯示。
在左圖PC端釘釘郵箱中，屬于編輯表單類的，將發送操作按鈕固定吸底，用戶只需要修改部分字段，更利于快速完成編輯；在PC端簡書中，屬于內容展示類的，出于增強互動的目的，將評論、點贊等操作固定在底部增加其操作便捷性。
考試星PC端采用左中右布局，將提交考試放在右側底部，可以不占用考試內容高度空間；百度學術PC端采用左右布局，右側是一些介紹內容，所以操作按鈕固定在和之有直接關系的左側內容底部。
移動端底部常會有一些吸底的控件，比如底部導航欄、主操作按鈕、需要引導或便捷用戶操作的控件等。
一級頁面導航固定在底部，當該頁面有主按鈕，比如結算等則將該欄放到導航欄上面，如果還有引導類或便捷操作類控件則再放到主操作欄上面。
移動端，特別是購物車場景存在多條吸底內容。
具有引導性的操作，為了配合主操作而出現，也是固定在底部，但位于底部操作上面，在特定場景下出現。
比如閑魚提供了一些常用問題，可以跟賣家交流更便捷；考拉海購購物車的優惠引導也是固定在底部，類似的還有京東、淘寶等購物車。
當PC端展示內容分多段，且其中有需要引導用戶操作的按鈕，建議在滾動到該段時將該操作按鈕吸底，滾動到另外一段內容后再取消吸底。
考拉海購PC端的購物車頁面，如果購物車內容比較多，支付欄是吸底的，向上滾動到購物車商品內容結束后，支付欄不吸底，下面展示推薦商品。
京東官網的購物車也是這種方式，但移動端主流購物車的支付都是固定在底部的。
吸底內容可以根據具體情況顯示或隱藏，這種非固定的方式常用于移動端閱讀及查看話題評論時。
在微信讀書的閱讀狀態時，為了給讀者提供沉浸式體驗，隱藏操作欄，上滑時再顯示；在知乎熱榜瀏覽主題內容時，主操作欄跟在內容下面，當頁面滑動后主操作欄改變布局樣式吸底展示。
錨點以回到頂部也屬于頁面滾動時需要的控件，配合滾動條用于跳轉到頁面指定位置。
PC端和移動端都可以在內容過多時使用回到頂部控件，PC端的錨點定位類似導航一樣可以放到頁面左側或者右側，但其實只是頁面的內容定位。
移動端可以利用滾動條做時間軸類型的定位或者分頁定位。
當PC端頁面內容區域比較長時比如瀑布流的使用，用戶需要頻繁返回頂部查看相關內容時，可以滾動后出現回到頂部控件。
花瓣PC端頁面滾動后，右下角有一些功能操作，滾動后出現回到頂部控件。
當頁面內容區域比較長時；當用戶需要頻繁返回頂部查看相關內容時，可以使用回到頂端返回頁面頂部。
如果當前頁面是主頁，可以滾動后主頁按鈕便成回到頂部按鈕，這樣可以避免遮擋內容，優化閱讀體驗。
京東購物車頁面除了展示添加到購物車的商品外，底部還有推薦上面，滾動后出現回到頂部控件；每日優鮮APP頁面滾動后，導航的主頁按鈕變成回到頂部按鈕，優化體驗，類似的還有淘寶、餓了么、考拉等主頁有瀑布流的內容。
當PC端有多條組合內容時，可以左側做一個錨點定位配合滾動條快速定位到頁面需要查看的內容。
當PC端使用上下布局時，且內容區域居中固定時，錨點懸浮在左側顯示，當屏幕小于一定尺寸時，錨點縮小懸浮于頁面左側，鼠標移入時再顯示。
在優設的網址導航中，由于導航分為多個類型，所以將具體類型名稱放到左側展示，能快速定位到需要的內容。
當PC端左側有導航，錨點定位可以放到右側，常用于閱讀文章等場景。
在Ant design的組件頁，由于左側有二級導航，所以將頁面的錨點定位放在右側，類似的還有語雀文章閱讀。
當有時間類型的內容比如瀏覽照片時，可以采取時間軸定位的方式快速滑動到需要查看的內容。
內容過多的情況下也可以采取分頁的形式，滾動后將分頁及回到頂部固定在底部右下角位置。
例如寶寶樹APP采用時間軸的方式快速定位，默認狀態定位控件縮小固定在右側，滑動時控件變大顯示具體時間，方便用戶按時間快速查找照片，類似的還有百度網盤里的照片瀏覽。
豆瓣APP在電影的討論模塊，選擇一個討論查看詳情滾動后底部顯示回復的定位錨點，控件放在操作欄上面吸底展示。
作者： Cassie
原文鏈接：www.zcool.com.cn/article/ZMTM0ODkzMg==.html
本文由 @ Cassie 授權發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
窗的類型有非常多種，所以在使用時很容易被濫用，這樣不僅會對用戶帶來困擾，也會讓我們的設計中出現細枝末節的問題。本篇文章分析和總結了不同彈窗的使用場景及工作中的實際應用，知道這些后，以后再也不會“濫用”彈窗啦！
我們口中常說的彈窗其實是個廣義的范圍，包括了對話框，動作菜單，浮出層，toast，snackbar等，這么多類型的彈窗在使用中很容易混亂或者說濫用，反而得不償失，給用戶帶來更多困擾。故本篇文章主要分析和總結不同彈窗的使用場景及工作中的實際應用。
官方的設計樣式會提到，但是細節不展開，有需要的可以參閱MD官方文檔和蘋果HIG官方文檔，文檔里介紹的都很細致。
除了官方文檔，本文還參閱了很多前輩的總結分析，參考鏈接已置于文末。（配圖主要來自體驗過程中的app截圖，安卓部分截圖主要來自MD規范）
在App使用中，彈窗出現的頻率越來越高，運營活動，系統通知，信息反饋，任務引導等。濫用的彈窗會漸漸導致用戶認知疲勞和視覺失調，甚至會出現“習慣性取消”等行為。
彈窗最主要的功能就是服務于當前主任務之外的支線任務，包括信息傳遞，操作反饋等。
對話框，警告框，toast……都屬于彈窗，但是使用場景都不一樣。
在合適的業務場景選擇合適的彈窗組件，能夠保證最基礎的用戶體驗。因為像強干擾類彈窗的使用，對用戶而言，更是一種強加的任務，很容易導致用戶喪失耐心而流失。
彈窗可以按照是否強制打斷用戶操作來分成兩種，模態彈窗和非模態彈窗（也可以叫做阻斷式彈窗和非阻斷式彈窗）。
模態彈窗：模態提供了一個專注聚焦的環境，用戶只有完成或者關閉當前任務，才能進行其他任務。
特點：打斷用戶當前的操作流程，屬于強勢的干擾行為，故運用彈窗需要慎重考慮。
常用組件：dialog（對話框）/alert(警告框)、popover（浮出層）、action sheet（動作菜單）、activity views（活動視圖）、modal bottom sheet（模態底部菜單）。
非模態彈窗：常用于輕量級的操作反饋和信息傳遞，不需要獲取屏幕焦點，用戶可以同時操作屏幕中的其他內容。
特點：屬于輕量級的反饋，不會對用戶流程產生干擾，但同時又給了用戶反饋和信息。
常用組件：Toast（吐司），snackbar，Hud（透明指示層）。
dialog和alert分別是MD和ios的官方彈出框，是最常見的彈窗，兩者功能一樣，在使用上以及樣式上略有區別（下文分析統一稱為彈出框）。
彈出框通常用來傳達和app及設備相關的重要信息，并且要求用戶操作或反饋，且其出現在屏幕中央，對內容遮擋嚴重，會中斷用戶正常操作。用戶只有完成或者關閉當前任務，才能進行其他任務。
其官方樣式如下：
4.1.1 使用場景
通知用戶app或設備相關的問題：
通過強干擾通知用戶設備相關問題如備份，低電量等問題；這些潛在問題可能會對用戶造成一定負面的影響。
再比如app的版本更新，消息通知，首飾引導等都關系到用戶的利益，所以也會用強干擾的方式讓用戶明確知道并選擇。
輔助用戶完成任務，如系統權限：
用戶在進行任務的過程中，受到阻攔，必須通過其他輔助操作幫助他完成任務。
如完成一些任務必須要開啟相應的系統權限：上傳照片要開啟相冊權限；拍小視頻要麥克風權限；出行外賣等產品要開啟定位權限；新建相冊必須要為相冊命名；下載app要登錄itunes賬號。
用戶主動中斷任務，破壞性操作等：
用戶中斷當前任務，對之前的操作有一定的影響，或者一些無法挽回的破壞性操作，故需強干擾的彈窗通知，避免用戶因為失誤有了不可挽回的損失。如退出賬號；刪除訂單，活動消息等；放棄編輯。
操作反饋：
當操作后的反饋比較重要，會影響用戶接下來的操作或會影響當下的任務，那就需要用強干擾讓用戶明確知道，要完成此操作需要什么，或者接下來會發生什么。
例如西瓜視頻的結算通過強干擾通知到用戶想要結算應該怎么做。
運營活動：
現在用彈出框來傳遞運營活動已經成為一個約定俗成的用法了，雖然ios規范中建議盡量少用彈出框，但公司還是要盈利的，所以基本上所有app都會以這種強干擾的形式來通知用戶“這里有優惠活動”等運營活動。
這種場景下，彈出框會根據產品以及業務的運營需求及產品的調性做豐富的運營設計，來吸引用戶參加運營活動，需要注意的一點，需要用戶參加的buttom一定要加強，突出。
功能引導：
功能引導和運營活動一樣，是產品出于業務角度考慮，用強干擾的方式吸引用戶使用某功能，達到一定的業務目標，如用戶活躍度。
例如完成訂單后（外賣或商品）引導用戶評價，并給予一定獎勵。如將流量引流到新業務，從而達到新業務推廣目的。
浮出層是ios的組件，是用戶點擊屏幕上的某個控件或區域出現在屏幕上方的臨時視圖，它最典型的是包含一個指向它出現位置的箭頭，且浮出層一般在入口下方，整個浮出層應該位于整個屏幕的中上方。
浮出層最開始主要用于大屏幕的ipad，但由于手機屏幕越來越大，目前也被較多地運用到手機界面中。
4.2.1 使用場景
多個常用操作的快捷入口：
多個常用操作通過popover折疊起來，視覺上更清爽簡潔，同時使用起來也方便，缺點是用戶不能直觀看到，需要一定的學習才能掌握，所以適合于有學習能力用戶群的產品
呈現頁面中一些折疊的信息：
屬于浮出層的衍生應用，和上個場景一樣，節約屏幕空間，顯露出一部分，并將剩余信息折疊起來，不影響用戶理解功能，又解決了屏幕空間，若用戶有需求，即可展開探索更多的信息，同樣也會用箭頭等指向出處
對于新用戶的功能引導或者新功能的引導：
此類場景也屬于浮出層的衍生應用，主要通過帶指向箭頭的浮層引導用戶學習某個功能，一般需要學習的功能是高亮的，且箭頭指向它。
actionsheet是ios系統中特定的警告框，用來響應動作或控件，或者呈現和當前內容相關的兩個及更多的選項。一般在屏幕底部。官方不建議在動作菜單中應用滾動條，所以動作菜單中的選項不能過多。
4.3.1 使用場景
當前對象的多個操作或者完成任務的多個選擇：
對當前對象的的多個操作，如qq中對圖片長按，出現多個對該圖片可進行的操作，幫助完成任務。除了文字列表外，還可以用圖標+宮格式的展示方式，例如分享功能的多個選項。
執行潛在的破壞性操作前的二次確認：
當執行潛在的破壞性操作前需再做提醒，避免產生不可挽回的失誤。需注意的是破壞性操作的按鈕需重點突出，一般用紅色，起到警示，危險的提醒作用
和alert的區別：
alert主要適用于兩個選項，而actionsheet可以有多個功能選項，且展示形式更多樣。前文講過，alert也有破壞性操作提醒的場景使用。
兩者相比，alert出現在屏幕中央，actionsheet出現在屏幕底部。視覺角度上alert相較于actionsheet更有阻斷感，對用戶而言干擾性更大。
另一方面底部的actionsheet從手勢操作的角度上來看，操作更方便，更容易對此作出選擇或關閉。所以alert更加適用于嚴重后果的破壞性操作提醒。
活動視圖是ios組件，是針對當前頁面提供的一系列任務和服務，例如復制，收藏，查找等。系統提供了許多內置活動，包括打印，信息和AirPlay。
這些任務始終首先出現在活動視圖中，無法重新排序。無需創建執行這些內置任務的自定義活動。活動視圖還顯示來自其他應用的共享和操作擴展。
Bottom sheet是MD的組件，MD中底部菜單有兩種，一種是Standard bottom sheet（標準底部菜單），另一種是Modal bottom sheet（模態底部菜單）。
MD的模態底部菜單和iOS的action sheet類似，它阻止用戶與屏幕其他地方交互，通過聚焦的底部菜單提供了更多的選項和功能。它可以是內聯菜單和簡單對話框的替代方案，為內容，圖標和動作提供了額外的空間。
規范建議，模態底部淡淡的初始垂直位置的上限為屏幕高度的50％。內容超過屏幕高度50％的模態菜單可以在整個屏幕上拉動，在內部滾動以訪問其余項目。同樣他的展現方式有列表式，也可有宮格式
snackbar是android專有控件，是出現在屏幕底部的提供有關app相關的簡短信息提醒，它屬于輕量級的信息提醒，一般出現幾秒后就會自動消失，不會中斷用戶操作。
snackbar往往由一條文案+一個引導性按鈕（可選，按鈕可以引導用戶進一步操作）組成，帶有一定的交互性。因為它自動會消失，所以它一定沒有取消或者不要等否定性按鈕。
4.6.1 使用場景
傳達輕量級的信息和操作反饋，可以引導用戶操作：
傳達輕量級的信息或反饋，并且可以引導用戶進行下一步行為，但并不強制用戶操作。比如chrome添加書簽時，可以進一步對新加的書簽進行編輯；刪除書簽時防止用戶后悔，提供一個撤銷按鈕。
Toast是android專有的控件，原先的MD規范中，toast是和snackbar放在一起講的，翻閱了最新的MD規范，snackbar里找不到關于toast的相關介紹（有小伙伴找到的望提醒一下）。
Toast應該包含在snackbar里了，當snackbar沒有按鈕其實就是toast了，不過這邊還是把Toast單獨拿出來分析
4.7.1 使用場景
傳達輕量級的信息和操作反饋，且不需要用戶操作：
適用于通知用戶不重要的信息和操作反饋，且不會對用戶當前的任務有影響，因為不能交互，且幾秒后消失，所以用戶很可能忽略，所以該類信息相對而言沒那么重要。
雖然toast是android專有樣式，但現在很多ios版本的系統中都使用了改良版的“toast”，因為輕反饋，不打斷用戶操作，同時又能通知信息和操作反饋，對用戶而言及其友好，但是不易傳達過多的文字，因為用戶很有可能會忽略。
ios文檔中的feedback中有建議：反饋可以幫助人們了解應用正在做什么，發現他們下一步可以做什么，并了解行動的結果。所以實際應用中，既要不打擾用戶，又要能引起用戶注意，還要和產品設計相協調。
比如結合了文字和icon的樣式，再比如用較為突出的背景色，位置的話在中央，頂部，底部，都會出現，會根據具體的業務來選擇合適的位置。一般出現的位置會和操作內容在一起，這樣用戶才能清晰有效地得到即時反饋。
下方例舉的toast案例因為選用了比內容更為突出的背景色，相比較上方案例的toast更易被用戶發現和察覺，達到通知用戶的目的。
Hud透明指示層，ios專用控件，典型的就是音量調節的彈窗樣式。部分改良的toast，在樣式上有借鑒學習Hud。
Dialog/Alert：
當信息或操作非常重要，并且必須要由用戶做決定或者操作才能繼續，一般用alert，更適用于用戶判斷選擇。
Modal bottom sheet/Action sheet：
稍弱于dialog/alert，更著重于提供更多的功能和選項時使用。
Activity view：
是針對當前頁面提供的一系列額外的任務和服務。
Popover：
使用更側重于指向性，更適用于信息或功能折疊。
Toast：
不太重要的信息提醒和操作反饋，更適用于不需用戶響應或反饋的場景。
snackbar：
不太重要的信息提醒和操作反饋，可以交互，但并不強制，更適用于可以引導用戶進行下一步或者一些撤銷上一步的場景。
Hud：
音量調節。
了解了每個彈窗組件的用法，下次就可以根據實際業務設計合適的彈窗了，不過官方規范或者文章的建議也都只是參考，實際工作中還是要靈活變通，設計的目標是幫助用戶更好更快的解決問題。
以上就是我對彈窗相關知識的總結，總結的過程中也對官方規范彈窗部分的內容再次熟悉了好幾遍，因為看的英文，所以理解上可能稍微有些不足，有不對的地方，還希望大家批評指正。（推薦大家多看看官方設計規范，就像一本非常實用的設計工具書，對于實際工作還是非常有幫助的）
再次感謝前輩的經驗分享！
這個控件叫什么系列之toast的曾經，現在，與未來 https://www.uisdc.com/ui-element-toast
如何設計App中的提示控件（toast） https://zhuanlan.zhihu.com/p/22405748
iOS和Android規范解析——底部浮層（上）https://www.jianshu.com/p/8bdfbc0a9339
iOS和Android規范解析——提示框（Toast）對比 https://www.jianshu.com/p/e1beeacbea32
不要濫用對話框！細說 iOS Alert View 與 Action Sheet https://zhuanlan.zhihu.com/p/20189186
App設計中，6組常見組件的區別和用法 http://www.woshipm.com/pd/873075.html
APP提示框架詳解：Toast提示、Snackers和Alert http://www.woshipm.com/pmd/296674.html
本文由 @麥子_Maizi 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
最近收到很多同行的抱怨，前端開發高級還行，對初中級最難過的不是面試過不去，而是“已讀不回”，來自某聘的梗，確實是，初中級因為坑位較少，很多HR在專心招聘的時候都未必能讓所有投簡歷都去面試，更別說還有刷業績現象，還是那幾個點：
1.學歷要注意，在外的個人名片，企業對比哈工和清華這即使不看面試也對清華有好感了吧！
2.項目經歷，強調很多遍了，簡介的形容你在項目中的作用，負責，以及運行，突出重點，
3.簡歷的簡潔，要學會用最短的語句體現最大的價值，沒用的寫上寫上也用處不大，
4.工作經歷，跳的多自己掂量，跳的少，空窗期少，包裝，這些要注意
5.面試經過，八股面試題，刷就完了，盡量做到說話不急也不慢，吐字清晰，磕磕絆絆毫無條理，再來個不確定，你是在被面試，不是提問面試官的
6.衣著，不要緊張，如果緊張可以多約幾個，把重要的排在最后，
大多情況下，簡歷方面的問題居多，對標大廠的話項目經歷，工作經驗、還有學歷要求居多，對簡歷和面試題可以【點擊此處】，解決還是很簡單的！
第 1 題：寫 React / Vue 項目時為什么要在列表組件中寫 key， 其作用是什么？
key 是給每一個 vnode 的唯一 id,可以依靠 key,更準確,更快的拿到 oldVnode 中對 應的 vnode 節點
第 2 題：['1', '2', '3'].map(parseInt) what & why ?
第一眼看到這個題目的時候，腦海跳出的答案是 [1, 2, 3]，但是真正的答案是[1, NaN, NaN]。
首先讓我們回顧一下，map 函數的第一個參數 callback。這個 callback 一共可以接收三個參數，其中第一個參數代表當前被處理的元素，而第二個參數代表該元素的索引。
arr.map(callback: (value: T, index: number, array: T[])=> U, thisArg?: any);
而 parseInt 則是用來解析字符串的，使字符串成為指定基數的整數。接收兩個參數，第一個表示被處理的值（字符串），第二個表示為解析時的基數。
parseInt(string, radix)
了解這兩個函數后，我們可以模擬一下運行情況
parseInt('1', 0) //radix 為 0 時，且 string 參數不以“0x”和“0”開頭時， 按照 10 為基數處理。這個時候返回 1parseInt('2', 1) //基數為 1（1 進制）表示的數中，最大值小于 2，所以無法解析，返回 NaNparseInt('3', 2) //基數為 2（2 進制）表示的數中，最大值小于 3，所以無法解析，返回 NaN
第 3 題：什么是防抖和節流？有什么區別？如何實現？
防抖——觸發高頻事件后 n 秒后函數只會執行一次，如果 n 秒內高頻事件再 次被觸發，則重新計算時間；
function debounce(fn) {
let timeout=null
// 創建一個標記用來存放定時器的返回值
return function() {
clearTimeout(timeout)
// 每當用戶輸入的時候把前一個 setTimeout clear 掉
timeout=setTimeout(()=> {
// 然后又創建一個新的 setTimeout, 這樣就能保證輸入字符后的 interval 間隔內如果還有字符輸入的話，就不會執行 fn 函數
fn.apply(this, arguments)
}, 500)
}}function sayHi() {
console.log('防抖成功')}var inp=
document.getElementById('inp')inp.addEventListener('input',
debounce(sayHi)) // 防抖
節流——高頻事件觸發，但在 n 秒內只會執行一次，所以節流會稀釋函數的執行頻率。
function throttle(fn) {
let canRun=true // 通過閉包保存一個標記
return function() {
if (!canRun) return
// 在函數開頭判斷標記是否為 true，不為 true 則 return
canRun=false // 立即設置為 false
setTimeout(()=> {
// 將外部傳入的函數的執行放在 setTimeout 中
fn.apply(this, arguments)
// 最后在 setTimeout 執行完畢后再把標記設置為 true(關鍵) 表示可以執行下一次循環了。當定時器沒有執行的時候標記永遠是 false，在開頭被 return 掉
canRun=true
}, 500)
}}function sayHi(e) {
console.log(e.target.innerWidth,
e.target.innerHeight)}window.addEventListener('resize',
throttle(sayHi))
第 4 題：介紹下 Set、Map、WeakSet 和 WeakMap 的區別？
Set——對象允許你存儲任何類型的唯一值，無論是原始值或者是對象引用 WeakSet——成員都是對象；成員都是弱引用，可以被垃圾回收機制回收，可以用來保存 DOM 節點，不容易造成內存泄漏；
Map——本質上是鍵值對的集合，類似集合；可以遍歷，方法很多，可以跟各種數據格式轉換。
WeakMap——只接受對象最為鍵名（null 除外），不接受其他類型的值作為鍵名；鍵名是弱引用，鍵值可以是任意的，鍵名所指向的對象可以被垃圾回收，此時鍵名是無效的；不能遍歷，方法有 get、set、has、delete。
第 7 題：ES5/ES6 的繼承除了寫法以外還有什么區別？
let
-1)}let isTypeOf
map[type]
}
=1.
ES5 的繼承實質上是先創建子類的實例對象，然后再將父類的方法添加到 this 上（Parent.apply(this)）.
2. ES6 的繼承機制完全不同，實質上是先創建父類的實例對象 this（所以必須先調用父類的 super()方法），然后再用子類的構造函數修改 this。
3. ES5 的繼承時通過原型或構造函數機制來實現。
4. ES6 通過 class 關鍵字定義類，里面有構造方法，類之間通過 extends 關鍵字實現繼承。
5. 子類必須在 constructor 方法中調用 super 方法，否則新建實例報錯。因為子類沒有自己的 this 對象，而是繼承了父類的 this 對象，然后對其進行加工。
如果不調用 super 方法，子類得不到 this 對象。
6. 注意 super 關鍵字指代父類的實例，即父類的 this 對象。
7. 注意：在子類構造函數中，調用 super 后，才可使用 this 關鍵字，否則報錯。
第 11 題：算法手寫題
已知如下數組，編寫一個程序將數組扁平化去并除其中重復部分數據，最終得到一個升序且不重復的數組
var arr=[ [1, 2, 2], [3, 4, 5, 5], [6, 7, 8, 9, [11, 12, [12, 13, [14] ] ] ], 10];
答：使用 Set 方法去重，flat(Infinity)扁平化
Array.from(new Set(arr.flat(Infinity))).sort((a,b)=>{ return a-b})//[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14]
第 12 題：JS 異步解決方案的發展歷程以及優缺點。
1、回調函數（callback）
優點：解決了同步的問題（只要有一個任務耗時很長，后面的任務都必須排隊等著，會拖延整個程序的執行。）
缺點：回調地獄，不能用 try catch 捕獲錯誤，不能 return
2、Promise
優點：解決了回調地獄的問題
缺點：無法取消 Promise ，錯誤需要通過回調函數來捕獲
3、Generator
特點：可以控制函數的執行，可以配合 co 函數庫使用
4、Async/await
優點：代碼清晰，不用像 Promise 寫一大堆 then 鏈，處理了回調地獄的問題
缺點：await 將異步代碼改造成同步代碼，如果多個異步操作沒有依賴性而使用 await 會導致性能上的降低。
第 13 題：Promise 構造函數是同步執行還是異步執行，那么 then 方法呢？
const promise=new Promise((resolve, reject)=> {
console.log(1)
resolve()
console.log(2)})promise.then(()=> {
console.log(3)})console.log(4)
執行結果是：1243，promise 構造函數是同步執行的，then 方法是異步執行的
第 15 題：簡單講解一下 http2 的多路復用
HTTP2 采用二進制格式傳輸，取代了 HTTP1.x 的文本格式，二進制格式解析更高效。
多路復用代替了 HTTP1.x 的序列和阻塞機制，所有的相同域名請求都通過同一個 TCP 連接并發完成。
在 HTTP1.x 中，并發多個請求需要多個 TCP 連接，瀏覽器為了控制資源會有 6-8個 TCP 連接都限制。HTTP2 中
同域名下所有通信都在單個連接上完成，消除了因多個 TCP 連接而帶來的延時和內存消耗。
單個連接上可以并行交錯的請求和響應，之間互不干擾
第 17 題：A、B 機器正常連接后，B 機器突然重啟，問 A 此時處于 TCP 什么狀態
如果 A 與 B 建立了正常連接后，從未相互發過數據，這個時候 B 突然機器重啟，問 A 此時處于 TCP 什么狀態？如何消除服務器程序中的這個狀態？（超綱題，了解即可）
因為 B 會在重啟之后進入 tcp 狀態機的 listen 狀態，只要當 a 重新發送一個數據包（無論是 syn 包或者是應用數據），b 端應該會主動發送一個帶 rst 位的重置包來進行連接重置，所以 a 應該在 syn_sent 狀態
第 18 題：React 中 setState 什么時候是同步的，什么時候是異步的？
1、由 React 控制的事件處理程序，以及生命周期函數調用 setState 不會同步更新 state 。
2、React 控制之外的事件中調用 setState 是同步更新的。比如原生 js 綁定的事件，setTimeout/setInterval 等。
第 48 題：call 和 apply 的區別是什么，哪個性能更好一些
1. Function.prototype.apply 和 Function.prototype.call 的作用是一樣的，區 別在于傳入參數的不同；
2. 第一個參數都是，指定函數體內 this 的指向；
3. 第二個參數開始不同，apply 是傳入帶下標的集合，數組或者類數組， apply 把它傳給函數作為參數，call 從第二個開始傳入的參數是不固定的，都會傳給函數作為參數。
4. call 比 apply 的性能要好，平常可以多用 call, call 傳入參數的格式正是內部所需要的格式
第 49 題：為什么通常在發送數據埋點請求的時候使用的是 1x1 像素的透明 gif 圖片？
1. 沒有跨域問題，一般這種上報數據，代碼要寫通用的；（排除 ajax）
2. 不會阻塞頁面加載，影響用戶的體驗，只要 new Image 對象就好了；（排 除 JS/CSS 文件資源方式上報）
3. 在所有圖片中，體積最小；（比較 PNG/JPG）
第 51 題：Vue 的響應式原理中 Object.defineProperty 有什么缺陷？
為什么在 Vue3.0 采用了 Proxy，拋棄了 Object.defineProperty？
? Object.defineProperty 無法監控到數組下標的變化，導致通過數組下標添加元素，不能實時響應；
? Object.defineProperty 只能劫持對象的屬性，從而需要對每個對象，每個屬性進行遍歷，如果，屬性值是對象，還需要深度遍歷。Proxy 可以劫持整個對象，并返回一個新的對象。
? Proxy 不僅可以代理對象，還可以代理數組。還可以代理動態增加的屬性。
第 53 題：輸出以下代碼的執行結果并解釋為什么
var a={n: 1};
var b=a;a.x=a={n: 2};
console.log(a.x)
console.log(b.x)
結果:undefined{n:2}
首先，a 和 b 同時引用了{n:2}對象，接著執行到 a.x=a={n：2}語句，盡管賦值 是從右到左的沒錯，但是.的優先級比=要高，所以這里首先執行 a.x，相當于為 a（或者 b）所指向的{n:1}對象新增了一個屬性 x，即此時對象將變為 {n:1;x:undefined}。之后按正常情況，從右到左進行賦值，此時執行 a={n:2}的時 候，a 的引用改變，指向了新對象{n：2},而 b 依然指向的是舊對象。之后執行 a.x={n：2}的時候，并不會重新解析一遍 a，而是沿用最初解析 a.x 時候的 a， 也即舊對象，故此時舊對象的 x 的值為{n：2}，舊對象為 {n:1;x:{n：2}}，它被 b引用著。后面輸出 a.x 的時候，又要解析 a 了，此時的 a 是指向新對象的 a，而這個新對象是沒有 x 屬性的，故訪問時輸出 undefined；而訪問 b.x 的時候，將輸出舊對象的 x 的值，即{n:2}。
第 73 題： 介紹下 BFC、IFC、GFC 和 FFC
BFC（Block formatting contexts）：
塊級格式上下文頁面上的一個隔離的渲染區域，那么他是如何產生的呢？可以 觸發 BFC 的元素有 float、position、overflow、display：table-cell/ inline-block/table-caption ；BFC 有什么作用呢？比如說實現多欄布局’
IFC（Inline formatting contexts）：
內聯格式上下文 IFC 的 line box（線框）高度由其包含行內元素中最高的實際高度計算而來（不受到豎直方向的 padding/margin 影響)IFC 中的 line box 一般左右都貼緊整個 IFC，但是會因為 float 元素而擾亂。
float 元素會位于 IFC 與與 line box之間，使得 line box 寬度縮短。 同個 ifc 下的多個 line box 高度會不同 IFC 中時不可能有塊級元素的，當插入塊級元素時（如 p 中插入 div）會產生兩個匿名塊 與 div 分隔開，即產生兩個 IFC，每個 IFC 對外表現為塊級元素，與 div 垂直排列。那么 IFC 一般有什么用呢？水平居中：當一個塊要在環境中水平居中時， 設置其為 inline-block 則會在外層產生 IFC，通過 text-align 則可以使其水平居中。
垂直居中：創建一個 IFC，用其中一個元素撐開父元素的高度，然后設置其 vertical-align:middle，其他行內元素則可以在此父元素下垂直居中。
GFC（GrideLayout formatting contexts）：
網格布局格式化上下文當為一個元素設置 display 值為 grid 的時候，此元素將會 獲得一個獨立的渲染區域，我們可以通過在網格容器（grid container）上定義 網格定義行（grid definition rows）和網格定義列（grid definition columns）屬性 各在網格項目（grid item）上定義網格行（grid row）和網格列（grid columns）
為每一個網格項目（grid item）定義位置和空間。那么 GFC 有什么用呢，和 table 又有什么區別呢？首先同樣是一個二維的表格，但 GridLayout 會有更加豐富的 屬性來控制行列，控制對齊以及更為精細的渲染語義和控制。
FFC（Flex formatting contexts）:
自適應格式上下文 display 值為 flex 或者 inline-flex 的元素將會生成自適應容器 （flex container），可惜這個牛逼的屬性只有谷歌和火狐支持，不過在移動端 也足夠了，至少 safari 和 chrome 還是 OK 的，畢竟這倆在移動端才是王道。Flex Box 由伸縮容器和伸縮項目組成。通過設置元素的 display 屬性為 flex 或inline-flex 可以得到一個伸縮容器。設置為 flex 的容器被渲染為一個塊級元素， 而設置為 inline-flex 的容器則渲染為一個行內元素。伸縮容器中的每一個子元 素都是一個伸縮項目。伸縮項目可以是任意數量的。伸縮容器外和伸縮項目內的一切元素都不受影響。簡單地說，Flexbox 定義了伸縮容器內伸縮項目該如 何布局。
第 83 題：var、let 和 const 區別的實現原理是什么
三者的區別：
? var 和 let 用以聲明變量，const 用于聲明只讀的常量；
? var 和 let 用以聲明變量，const 用于聲明只讀的常量；
? var 聲明的變量，不存在塊級作用域，在全局范圍內都有效，let 和 const 聲明的，只在它所在的代碼塊內有效；
? let 和 const 不存在像 var 那樣的 “變量提升” 現象，所以 var 定義變量可以先使用，后聲明，而 let 和 const 只可先聲明，后使用；
? let 聲明的變量存在暫時性死區，即只要塊級作用域中存在 let，那么它所聲明的變量就綁定了這個區域，不再受外部的影響。
? let 不允許在相同作用域內，重復聲明同一個變量；
? const 在聲明時必須初始化賦值，一旦聲明，其聲明的值就不允許改變， 更不允許重復聲明；如 const 聲明了一個復合類型的常量，其存儲的是一個引用地址，不允許改變的是這個地址，而對象本身是可變的。
變量與內存之間的關系，主要由三個部分組成：
? 變量名
? 內存地址
? 內存空間JS 引擎在讀取變量時，先找到變量綁定的內存地址，然后找到地址所指向的內 存空間，最后讀取其中的內容。當變量改變時，JS 引擎不會用新值覆蓋之前舊 值的內存空間（雖然從寫代碼的角度來看，確實像是被覆蓋掉了），而是重新分配一個新的內存空間來存儲新值，并將新的內存地址與變量進行綁定，JS 引擎會在合適的時機進行 GC，回收舊的內存空間。
const 定義變量（常量）后，變量名與內存地址之間建立了一種不可變的綁定關系，阻隔變量地址被改變，當 const 定義的變量進行重新賦值時，根據前面的論述，JS 引擎會嘗試重新分配新的內存空間，所以會被拒絕，便會拋出異常。
第 96 題：介紹下前端加密的常見場景和方法
首先，加密的目的，簡而言之就是將明文轉換為密文、甚至轉換為其他的東西， 用來隱藏明文內容本身，防止其他人直接獲取到敏感明文信息、或者提高其他人獲取到明文信息的難度。通常我們提到加密會想到密碼加密、HTTPS 等關鍵詞，這里從場景和方法分別提一些我的個人見解。
場景-密碼傳輸
前端密碼傳輸過程中如果不加密，在日志中就可以拿到用戶的明文密碼，對用戶安全不太負責。這種加密其實相對比較簡單，可以使用 PlanA-前端加密、后端解密后計算密碼字符串的 MD5/MD6 存入數據庫；也可以 PlanB-直接前端使用一種穩定算法加密成唯一值、后端直接將加密結果進行 MD5/MD6，全程密碼明文不出現在程序中。
PlanA 使用 Base64 / Unicode+1 等方式加密成非明文，后端解開之后再存它的MD5/MD6 。
PlanB 直接使用 MD5/MD6 之類的方式取 Hash ，讓后端存 Hash 的 Hash 。
場景-數據包加密
應該大家有遇到過：打開一個正經網站，網站底下蹦出個不正經廣告——比如X 通的流量浮層，X 信的插入式廣告……（我沒有針對誰）但是這幾年，我們會發現這種廣告逐漸變少了，其原因就是大家都開始采用 HTTPS 了。被人插入這種廣告的方法其實很好理解：你的網頁數據包被抓取->在數據包到達你手機之前被篡改->你得到了帶網頁廣告的數據包->渲染到你手機屏幕。而 HTTPS 進行了包加密，就解決了這個問題。嚴格來說我認為從手段上來看，它不算是一種前端加密場景；但是從解決問題的角度來看，這確實是前端需要知道的事情。
Plan 全面采用 HTTPS
場景-展示成果加密
經常有人開發網頁爬蟲爬取大家辛辛苦苦一點一點發布的數據成果，有些會影響你的競爭力，有些會降低你的知名度，甚至有些出于惡意爬取你的公開數據后進行全量公開……比如有些食譜網站被爬掉所有食譜，站點被克隆；有些求職網站被爬掉所有職位，被拿去賣信息；甚至有些小說漫畫網站賴以生存的內容也很容易被爬取。
Plan 將文本內容進行展示層加密，利用字體的引用特點，把拿給爬蟲的數據變成“亂碼”。舉個栗子：正常來講，當我們擁有一串數字“12345”并將其放在網站頁面上的時候，其實網站頁面上顯示的并不是簡單的數字，而是數字對應的字體的“12345”。這時我們打亂一下字體中圖形和字碼的對應關系，比如我們搞成這樣：
圖形：1 2 3 4 5 字碼：2 3 1 5 4
這時，如果你想讓用戶看到“12345”，你在頁面中渲染的數字就應該是“23154”。
這種手段也可以算作一種加密。
前端面試合集~
八股文and大廠面經~
技術知識點源碼筆記解析~
總是投簡歷找不到工作，或者已讀不回居多要考慮簡歷的問題，也可以【點擊此處】，優化及修改
很多時候來說前端開發確實對新人不友好，想要更進一步，薪資漲幅比較難，大多時候都沒有機會，簡歷的修改與更新，項目的參與和制作，大環境就是這樣，想要進步只能被迫向前，內卷每個行業都有，不是說只有前端卷的嚴重，所以安穩求富貴，多給自己的技術升升級才能在行業不斷更迭下維持現狀，尋找突破~
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
