㈠ chrome瀏覽器js怎麼訪問注冊表
首先我們打開開發者工具，你可以直接在頁面上點擊右鍵，然後選擇審查元素或者在Chrome的工具中找到或者你直接記住這個快捷方式：Ctrl+Shift+I(或者Ctrl+Shift+J直接打開控制台)，或者直接按F12。打開的開發者工具就長下面的樣子，建議大家將開發者工具彈出作為一個獨立的窗口：1、Elements標簽頁這個就是查看、編輯頁面上的元素，包括HTML和CSS：左側就是對頁面HTML結構的查看與編輯，你可以直接在某個元素上雙擊修改元素的屬性，或者你點右鍵選;EditasHtml;直接對元素的HTML進行編輯，或者刪除某個元素，所有的修改都會即時在頁面上得到呈現。（註：看到上面右鍵菜單的最後一個選項;審查元素了么？這是不是說明這個開發者工具的頁面也是HTML來的呢？你點一下就知道了哦，嘿嘿）你還可以對某個元素進行監聽，在JS對元素的屬性或者HTML進行修改的時候，直接觸發斷點，跳轉到對改元素進行修改的JS代碼處：Elements標簽頁的右側可以對元素的CSS進行查看與編輯修改：你還可以通過這里看到各CSS選擇器設置的CSS值的覆蓋情況。下面的Metrics可以看到元素占的空間情況（寬、高、Padding、Margin）注意到上面的Properties沒有？這個很有用哦，可以讓你看到元素具有的方法與屬性，比查API手冊要方便得多哦（要注意某些方法和屬性在IE、FireFox等其他瀏覽器下面的支持情況哦）。2、Resources標簽頁Resources標簽頁可以查看到請求的資源情況，包括CSS、JS、圖片等的內容，同時還可以查看到存儲相關的如Cookies、HTML5的Database和LocalStore等，你可以對存儲的內容編輯和刪除。這里的CSS文件有一個好玩的特性，你可以直接修改CSS文件，並且修改即時生效哦：3、Network標簽頁Network標簽頁對於分析網站請求的網路情況、查看某一請求的請求頭和響應頭還有響應內容很有用，特別是在查看Ajax類請求的時候，非常有幫助。注意是在你打開Chrome開發者工具後發起的請求，才會在這里顯示的哦。點擊左側某一個具體去請求URL，可以看到該請求的詳細HTTP請求情況：我們可以在這里看到HTTP請求頭、HTTP響應頭、HTTP返回的內容等信息，對於開發、調試，都是很有用的。4、Scripts標簽頁很明顯，這個標簽頁就是查看JS文件、調試JS代碼的，直接看下圖的說明：還有你可以打開Javascript控制台，做一些其他的查看或者修改：你甚至還可以為某一XHR請求或者某一事件設置斷點：5、Timeline標簽頁注意這個Timeline的標簽頁不是指網路請求的時間響應情況哦（這個在Network標簽頁里查看），這個Timeline指的JS執行時間、頁面元素渲染時間：點擊底部的Record就可以開始錄制頁面上執行的內容。6、Profiles標簽頁這個主要是做性能優化的，包括查看CPU執行時間與內存佔用：7、Audits標簽頁這個對於優化前端頁面、加速網頁載入速度很有用哦（相當與Yslow）：點擊run按鈕，就可以開始分析頁面，分析完了就可以看到分析結果了它甚至可以分析出頁面上樣式表中有哪些CSS是沒有被使用的哦：8、Console標簽頁就是Javascript控制台了：這個除了查看錯誤信息、列印調試信息（console.log()）、寫一些測試腳本以外，還可以當作JavascriptAPI查看用。例如我想查看console都有哪些方法和屬性，我可以直接在Console中輸入;並執行：怎麼樣，一目瞭然了吧？再例如我想查看日期函數都有哪些方法：（註：注意在這里看到的某些方法和屬性是ES5新增的，記得兼容其他瀏覽器的支持情況哦）
㈡ 微前端 -- 乾坤（一）
在 toB 的前端開發工作中，我們往往就會遇到如下困境：
基座模式
通過一個主應用，來管理其它應用。設計難度小，方便實踐，但是通用度低。
自組織模式。應用之間是平等的，不存在相互管理的模式。設計難度大，不方便實施，但是通用度高。
就當前而言，基座模式實施起來比較方便，方案也是蠻多的。
注冊表模式
和微服務架構相似，不論是哪種微前端方式，都需要有一個應用注冊表的服務。這個應用注冊表擁有每個應用及對應的入口，即路由。
它可以是一個固定值的配置文件，如 JSON 文件，又或者是一個可動態更新的配置，又或者是一種動態的服務。
作用：
應用注冊。即提供新的微前端應用，向應用注冊表注冊功能。
應用發現。讓主應用可以尋找到其它應用。
首先看一下它的用法：
https://qiankun.umijs.org/zh/guide/getting-started
微前端每個應用都擁有自己的生命周期：
bootstrap， 只會在微應用初始化的時候調用一次，下次微應用重新進入時會直接調用 mount 鉤子，不會再重復觸發 bootstrap。 通常我們可以在這里做一些全局變數的初始化，比如不會在 unmount 階段被銷毀的應用級別的緩存等。
Mount，應用每次進入都會調用 mount 方法，通常我們在這里觸發應用的渲染方法
Unload，刪除應用的生命周期
Unmount，應用每次 切出/卸載 會調用的方法，通常在這里我們會卸載微應用的應用實例
乾坤，作為一款微前端領域的知名框架，其建立在single-spa基礎上。相較於single-spa，乾坤做了兩件重要的事情，其一是載入資源，第二是進行資源隔離。而資源隔離又分為Js資源隔離和css資源隔離.
每個微應用對全局的影響都會局限在微應用自己的作用域內。比如 A 應用在 window 上新增了個屬性 test，這個屬性只能在 A 應用自己的作用域通過 window.test 獲取到，主應用或者其他應用都無法拿到這個變數。
1、快照沙箱
2、支持多應用的代理沙箱
💪 HTML Entry 接入方式，讓你接入微應用像使用 iframe 一樣簡單。
在使用 single-spa 載入微應用時，我們載入的不是微應用本身，而是微應用導出的 JS 文件，即JS Entry。
要接入一個微應用，就需要對微應用進行一系列的改造，然而 JS Entry 的問題就出在這兒，改造時對微應用的侵入行太強，而且和主應用的耦合性太強。
微應用改造一般分為三步：
l 微應用路由改造，添加一個特定的前綴
l 微應用入口改造，掛載點變更和生命周期函數導出
在js文件的入口中會導出一個對象，這個對象上有 bootstrap、mount、unmount 這三個接入 single-spa 框架必須提供的生命周期方法，其中 mount 方法規定了微應用應該怎麼掛載到主應用提供的容器節點上。
l 打包工具配置更改
侵入型強其實說的就是第三點，更改打包工具的配置，使用 single-spa 接入微應用需要將微應用整個打包成一個 JS 文件，發布到靜態資源伺服器，然後在主應用中配置該 JS 文件的地址告訴 single-spa 去這個地址載入微應用。這就導致常見的打包優化基本上都沒了，比如：按需載入、首屏資源載入優化、css 獨立打包等優化措施。
項目發布以後出現了 bug ，修復之後需要更新上線，為了清除瀏覽器緩存帶來的應用，一般文件名會帶上 chunkcontent，微應用發布之後文件名都會發生變化，這時候還需要更新主應用中微應用配置，然後重新編譯主應用然後發布，這套操作簡直是不能忍受的。這也是 微前端框架 之 single-spa 從入門到精通 這篇文章中示例項目中微應用發布時的環境配置選擇 development 的原因。
qiankun 框架為了解決 JS Entry 的問題，於是採用了 HTML Entry 的方式，讓用戶接入微應用就像使用 iframe 一樣簡單。
https://github.com/sy-l123/qiankun-demo
㈢ 寫前端用哪個軟體好
編寫代碼的軟體有不少：WebStorm、Sublime、HBuilderX、Editplus和Dreamweaver等。
每個軟體各有優缺點。
我自己主要用Dreamweaver這個軟體，用習慣了；有時用一下 HBuilderX