㈠ 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