JavaScript浏览器(兼容、调试)

1、浏览器主要组成部分
1】用户界面
2】浏览器引擎(负责窗口管理、Tab进程管理等)
3】渲染引擎(也叫内核，负责HTML和CSS解析、页面渲染)
4】JS引擎(JS解释器，如Chrome和Nodejs采用的V8)
5】网络
6】存储
注：我们常说的浏览器内核就是指渲染引擎

2、浏览器是多线程的吗？
是的。JS是单线程，但浏览器是多线程，比如渲染线程，JS引擎线程。

3、浏览器解析过程
（根据前端代码至上而下解析，html，css和js也是遵循此顺序，因此渲染引擎和js引擎无谓谁先谁后）
1）构建dom树
首先解析收到的文档，根据文档定义构建1棵 DOM 树，DOM树是由DOM元素及属性节点组成的。
2）构建css树
然后对CSS进行解析，生成CSSOM规则树。
3）构建渲染树
根据 DOM 树和 CSSOM 规则树构建渲染树。渲染树的节点被称为渲染对象，渲染对象是一个包含有颜色和大小等属性的矩形，渲染对象和 DOM 元素相对应，但这种对应关系不是一对一的，不可见的 DOM 元素不会被插入渲染树。还有一些 DOM元素对应几个可见对象，它们一般是一些具有复杂结构的元素，无法用一个矩形来描述。
4）布局（回流）
当渲染对象被创建并添加到树中，它们并没有位置和大小，所以当浏览器生成渲染树以后，就会根据渲染树来进行布局（也可以叫做回流）。这一阶段浏览器要做的事情是要弄清楚各个节点在页面中的确切位置和大小。通常这一行为也被称为“自动重排”。
**重排：就是重新布局
5）绘制
布局阶段结束后是绘制阶段，遍历渲染树并调用渲染对象的 paint 方法将它们的内容显示在屏幕上，绘制使用UI 基础组件。
**重绘：重新绘制
这个过程是逐步完成的，为了更好的用户体验，渲染引擎将会尽可能早的将内容呈现到屏幕上，并不会等到所有的 html 都解析完成之后再去构建和布局 render 树。它是解析完一部分内容就显示一部分内容，同时，可能还在通过网络下载其余内容。
注意：
正常的解析过程，渲染引擎先开始解析html标签，遇到css，阻塞html的解析，转而去解析css。遇到js，也会先阻塞html的解析，然后调用js引擎去解析js代码。因而屏幕会出现短暂的白屏现象。
优化：
1】将一些css代码，js代码写在html文件内联标签里，减少下载时间
2】尽量减小文件大小，缩减代码量有时不太实际，业务就需要那么多代码，但可以通过webpack，将代码压缩成一行，实现文件大小的缩减
3】可以将一些不需要在HTML解析阶段用到的JavaScript外部文件引入的script标签加上async或者defer，使得能异步加载，不阻塞页面构建
4】async：异步加载js文件，加载完成后，渲染引擎就会中断渲染，解析js文件造成阻塞。
defer 和 async 的区别在于：
defer 要等到整个页面在内存中正常渲染结束（DOM 结构完全生成，以及其他脚本执行完成），在window.onload 之前执行；
async 一旦下载完，渲染引擎就会中断渲染，执行这个脚本以后，再继续渲染。
如果有多个 defer 脚本，会按照它们在页面出现的顺序加载
多个 async 脚本不能保证加载顺序

4、什么是重绘（重新绘制）和回流（布局）？如何减少它们触发的次数？
1】重绘：渲染树更新某个属性，但不影响整体布局，比如更改背景颜色。
2】回流：更新某元素一些属性，需要重新进行布局，比如新增dom
3】频繁操作dom，就会多次引起浏览器的重绘和回流，消耗更多的资源，导致页面变慢。建议使用虚拟dom，将多次dom操作合并为一次。

5、什么是文档的预解析？（浏览器解析过程）
Webkit 和 Firefox 都做了这个优化，当执行 JavaScript 脚本时，另一个线程解析剩下的文档，并加载后面需要通过网络加载的资源。这种方式可以使资源并行加载从而使整体速度更快。需要注意的是，预解析并不改变 DOM 树，它将这个工作留给主解析 过程，自己只解析外部资源的引用，比如外部脚本、样式表及图片。

6、浏览器端的存储技术有哪些？
浏览器常见的存储技术有 cookie、localStorage 和 sessionStorage。
还有两种存储技术用于大规模数据存储，webSQL（已被废除）和 indexDB。

7、Cookie放哪里，Cookie能做的事情和存在的价值
1】后端生成， 放在http的请求头，最终存储在浏览器里面里， 一般4k大小
2】内容：名（name）、值（value）、等号和过期时间
3】作用：cookie本身是用于客户端和服务器之间的通信，用于身份认证的功能， 携带少量的信息 每次发起http请求都会带上
4】会话cookie 和 持久cookie
指定了expire time（有效期）的是持久cookie
没有指定expire time（有效期）的是会话cookie

8、cookie和session有哪些方面的区别?
1】cookie 机制采用的是在客户端保持状态的方案 session 机制采用的是在服务器端保持状态的方案
2】cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗 考虑到安全应当使用session
3】session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能 考虑到减轻服务器性能方面，应当使用COOKIE
4】单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie；而session的大小不限制，具体看服务器容量
5】将登陆信息等重要信息存放为SESSION 其他信息如果需要保留，可以放在COOKIE中

9、localStorage 和 sessionStorage
localStorage和sessionStorage都是webstorage，为本地存储，存储在客户端，大小为5M
1】localStorage生命周期是永久，这意味着除非用户显示在浏览器提供的UI上清除localStorage信息，否则这些信息将永远存在。适合做一些长期存储。
2】sessionStorage仅在当前会话下有效，关闭页面或浏览器后被清除。适合做一些一次性存储。
与cookie的区别：
a、存储上限为5M，比cookie的4k大
b、http请求的时候不会带上
缺陷：
容易被伪造
应用场景：大表单数据缓存

10、浏览器同源政策
同源下的浏览器资源才能共享，不同源则不可
1】所谓"同源"指的是：
协议相同、域名相同、端口相同
2】如果非同源，共有三种行为受到限制：
（1） AJAX 请求不能发送。
（2） Cookie、webStorage 和 IndexDB 无法读取。
（3） DOM 无法获得。（webview可以获取）
浏览器这个策略的本质是，一个域名的 JS ，在未经允许的情况下，不得读取另一个域名的内容。但浏览器并不阻止你向另一个域名发送请求。

11、跨域
1】定义
受到浏览器同源政策的限制，当一个请求url的协议、域名、端口三者之间任意一个与当前页面url不同即为跨域。本质上是浏览器的一种安全策略。
2】解决方案
a、CORS
CORS 是跨域资源共享（Cross-Origin Resource Sharing）的缩写。它是 W3C 标准，属于跨源 AJAX 请求的根本解决方法
1）普通跨域请求：只需服务器端设置Access-Control-Allow-Origin
2）带cookie跨域请求：前后端都需要进行设置
前端：根据xhr.withCredentials字段判断是否带有cookie
服务器：主要是通过设置Access-Control-Allow-Origin来进行的

b、JSONP
JSONP 是服务器与客户端跨源通信的常用方法。最大特点就是简单适用，兼容性好（兼容低版本IE），缺点是只支持get请求，不支持post请求
核心思想：网页通过添加一个

c、使用代理工具
1）vue-cli的proxyTable
在项目目录里找到config文件夹，然后找到index.js，找到proxyTable选项，target参数设置为要代理的 url 即可。
2）whistle
我们只需要在whistle的配置文件里面设置好ip和域名之间的映射，就不用频繁去修改本地的host配置
npm可以直接安装whistle，chrome里面也有对应的whistle插件。
（这个工具也可以用于排查bug，特别是上线的H5应用，可以用于mock模拟api）

d、域名未备案
如果域名未备案的话，也会引发跨域。因此，绑定云服务器的域名，最好先备案。

12、Ajax发生跨域要设置什么（前端）
$.ajax({
url: “http://localhost:8080/orders”,
type: “GET”,
xhrFields: {
withCredentials: true
},
crossDomain: true,
success: function (data) {
render(data);
}
});
跨域请求想要带上cookies必须在请求头里面加上{crossDomain: true, xhrFields: {withCredentials: true}}设置

13、加上CORS之后从发起到请求正式成功的过程
1】浏览器直接发送CORS跨域请求，并在header信息中增加一个Origin字段，表明这是一个跨域的请求。
2】服务器根据这个值，决定是否同意这次请求。如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应
3】浏览器收到这个回应发现这个回应的头信息没有包含Access-Control-Allow-Origin字段，就知道错了，从而会抛出一个错误，被XMLHttpRequest的onerror回调函数捕获
注意这种错误无法通过状态码识别，此时HTTP回应的状态码可能是200

14、jsonp为什么不支持post方法
因为jsonp的原理实际上就是使用js的script标签进行传参，那么必然是get方式的了，和浏览器中敲入1个url一样
************jsonp方案需要服务端怎么配合？
jsonp的基本思想是，网页通过添加一个

15、如何实现浏览器内多个标签页之间的通信?
1】实现的方式是使用 websocket 协议，因为 websocket 协议可以实现服务器推送，所以服务器就可以用来当做这个中介者。
标签页通过向服务器发送数据，然后由服务器向其他标签页推送转发。
2】使用 ShareWorker 的方式，shareWorker 会在页面存在的生命周期内创建一个唯一的线程，并且开启多个页面也只会使
用同一个线程。这个时候共享线程就可以充当中介者的角色。标签页间通过共享一个线程，然后通过这个共享的线程来实现数据的交换。
3】使用 localStorage 的方式，我们可以在一个标签页对 localStorage 的变化事件进行监听，然后当另一个标签页。修改数据的时候，我们就可以通过这个监听事件来获取到数据。这个时候 localStorage 对象就是充当的中介者的角色。

4】使用 postMessage 方法，如果我们能够获得对应标签页的引用，我们就可以使用 postMessage 方法，进行通信。（要求同源）

16、优雅降级和渐进增强
渐进增强（Progressive Enhancement）：一开始就针对低版本浏览器进行构建页面，完成基本的功能，然后再针对高级浏览器进行效果、交互、追加功能达到更好的体验。
优雅降级（Graceful Degradation）：一开始就构建站点的完整功能，然后针对浏览器测试和修复。比如一开始使用 CSS3 的特性构建了一个应用，然后逐步针对各大浏览器进行 hack 使其可以在低版本浏览器上正常浏览。
其实渐进增强和优雅降级并非什么新概念，只是旧的概念换了一个新的说法。在传统软件开发中，经常会提到向上兼容和向下兼容的概念。渐进增强相当于向上兼容，而优雅降级相当于向下兼容

17、浏览器的内核有哪些？分别有什么代表的浏览器？
Trident 内核：IE，其内核有大量bug
Gecko 内核：Mozilla Firefox（火狐浏览器），Netscape6及以上版本
Webkit 内核：Safari 、曾经的 Chrome
Presto 内核：Opera 7到Opera12.17（欧朋浏览器）之间的版本采用的内核
Blink 内核：现在 Chrome 内核是 Blink，Opera现已改用Google Chrome的Blink内核

18、网站URL优化，绝对路径还是相对路径好一点
1】绝对路径优缺点
优点：
有利于网站的SEO
如果网页文件位置改变，里面的链接还是指向正确的
缺点：
文件移动困难，一旦在服务器上面移动静态文件，会导致链接发生变化
当URL链接数量变多的时候，会增加整体的HTML代码量
2】相对路径的优缺点
优点：
文件移动方便，文件的移动一般不会引起服务器返回404
HTML代码简洁
缺点：
不利于SEO
如果网页文件位置改变，里面的链接指向就不一定是正确的

---

兼容问题
现在说的兼容性问题，主要是说IE与几个主流浏览器如firefox，google等。而对IE浏览器来说，IE7又是个跨度，因为之前的版本更新甚慢，bug甚多。从IE8开始，IE浏览器渐渐遵循标准，到IE9后由于大家都一致认为标准很重要，可以说在兼容性上比较好，但在中国来说，由于xp的占有率问题，使用IE7以下的用户仍然很多，所以不得不考虑低版本浏览器的兼容。
对浏览器兼容问题，一般分，HTML，Javascript兼容，CSS兼容。 其中html相关问题较容易处理，无非是高版本浏览器用了低版本浏览器无法识别的元素，致其不能解析，所以平时注意一点。特别是HTML5增加了许多新标签，低版本浏览器有点影响时代进步。

1、 如何处理 HTML5 新标签的浏览器兼容问题？
1） IE8/IE7/IE6 支持通过 document.createElement 方法产生的标签，可以利用这一特性让这些浏览器支持HTML5 新标签，浏览器支持新标签后，还需要添加标签默认的样式。
2） 当然也可以直接使用成熟的框架，比如 html5shiv

2、不同浏览器的标签默认的外补丁和内补丁不同
问题症状：随便写几个标签，不加样式控制的情况下，各自的margin 和padding差异较大
碰到频率: 100%
解决方案：css里 {margin:0;padding:0;}
备注：这个是最常见的也是最易解决的一个浏览器兼容性问题，几乎所有的css文件开头都会用通配符来设置各个标签的内外补丁是0

3、块属性标签float后，又有横行的margin情况下，在ie6显示margin比设置的大
问题症状:常见症状是ie6中后面的一块被顶到下一行
碰到频率：90%（稍微复杂点的页面都会碰到，float布局最常见的浏览器兼容问题）
解决方案：在float的标签样式控制中加入 display:inline;将其转化为行内属性
备注：我们最常用的就是div+css布局了，而div就是个典型的块属性标签，横向布局的时候我们通常都是用div float实现的，横向的间距设置如果用margin实现，这是个必然会碰到的兼容性问题

4、设置较小高度标签（一般小于10px），在ie6，ie7，遨游中高度超出自己设置高度
问题症状：ie6、7和遨游里这个标签的高度不受控制，超出自己设置的高度
碰到频率：60%
解决方案：给超出高度的标签设置overflow:hidden;或者设置行高line-height 小于你设置的高度。
备注：这一般出现在我们设置小圆角背景的标签里。出现这个问题的原因是ie8之前的浏览器都会给标签一个最小默认的行高的高度。即使你的标签是空的，这个标签的高度还是会达到默认的行高

5、行内属性标签，设置display:block后采用float布局，又有横行的margin的情况，ie6间距bug（类似第二种）
问题症状：ie6里的间距比超过设置的间距
碰到几率：20%
解决方案：在display:block;后面加入display:inline;display:table;
备注：行内属性标签，为设置宽高，我们需要设置display:block;(除input标签比较特殊)。在用float布局并有横向的margin后，在ie6下，他就具有了块属性float后的横向margin的bug。不过因它本身就是行内属性标签，所以我们再加上display:inline的话，它的高宽就不可设了。这时候我们还需要在display:inline后面加入display:talbe

6、图片默认有间距
问题症状：几个img标签放在一起的时候，有些浏览器会有默认的间距，加上问题一中提到的通配符也不起作用
碰到几率：20%
解决方案：使用float属性为img布局
备注：因img标签是行内属性标签，所以只要不超出容器宽度，img标签都会排在一行里，但是部分浏览器的img标签之间会有个间距。去掉这个间距使用float是王道

7、标签最低高度设置min-height不兼容
问题症状：因为min-height本身就是一个不兼容的css属性，所以设置min-height时不能很好的被各个浏览器兼容
碰到几率：5%
解决方案：如果我们要设置一个标签的最小高度200px，需要进行的设置为：{min-height:200px; height:auto !important; height:200px; overflow:visible;}
备注：在B/S系统前端开时，有很多情况下我们有这种需求。当内容小于一个值（如300px）时。容器高度为300px；当内容高度大于这个值时，容器高度被撑高，而不是出现滚动条。这时候我们就会面临这个兼容性问题

8、透明度的兼容css设置
方法是：每写一小段代码（布局中的一行或者一块）我们都要在不同的浏览器中看是否兼容，当然熟练到一定的程度就没这么麻烦了。建议经常
会碰到兼容性问题的新手使用。很多兼容性问题都是因为浏览器对标签的默认属性解析不同造成的，只要我们稍加设置都能轻松地解决这些兼容
问题。如果我们熟悉标签的默认属性的话，就能很好的理解为什么会出现兼容问题以及怎么去解决这些兼容问题

9、ul标签内外边距问题ul标签在IE6\IE7中，有个默认的外边距，但是在IE8以上及其他浏览器中有个默认的内边距
解决方法：统一设置ul的内外边距为0

10、JavaScript的兼容性
1】标准的事件绑定方法函数为addEventListener，但IE下是attachEvent；
2】事件的捕获方式不一致，标准浏览器是由外至内，而IE是由内到外，但是最后的结果是将IE的标准定为标准
3】window.event获取的。并且获取目标元素的方法也不同，标准浏览器是event.target，而IE下是event.srcElement
4】在低版本的IE中获取的日期处理函数的值不是与1900的差值，但是在高版本的IE中和标准浏览器保持了一致，获取的值也是与1900的差值。
比如：var year= new Date().getYear();
5】ajax的实现方式不同，这个我所理解的是获取XMLHttpRequest的不同，IE下是activeXObject
6】IE中不能操作tr的innerHtml7.获得DOM节点的父节点、子节点的方式不同
其他浏览器：parentNode parentNode.childNodes
IE：parentElement parentElement.children

11、微信 H5 页面兼容性解决方案
1、ios端兼容input光标高度
问题详情描述：input输入框光标，在安卓手机上显示没有问题，但是在苹果手机上当点击输入的时候，光标的高度和父盒子的高度一样。例如下图，左图是正常所期待的输入框光标，右边是ios的input光标。

出现原因分析：通常我们习惯用height属性设置行间的高度和line-height属性设置行间的距离（行高），当点击输入的时候，光标的高度就自动和父盒子的高度一样了。（谷歌浏览器的设计原则，还有一种可能就是当没有内容的时候光标的高度等于input的line-height的值，当有内容时，光标从input的顶端到文字的底部
解决办法：高度height和行高line-height内容用padding撑开

2、ios端微信h5页面上下滑动时卡顿、页面缺失
问题详情描述：在ios端，上下滑动页面时，如果页面高度超出了一屏，就会出现明显的卡顿，页面有部分内容显示不全的情况，例如下图，右图是正常页面，左边是ios上下滑动后，卡顿导致如左图下面部分丢失。

出现原因分析：
笼统说微信浏览器的内核，Android上面是使用自带的WebKit内核，iOS里面由于苹果的原因，使用了自带的Safari内核，Safari对于overflow-scrolling用了原生控件来实现。对于有-webkit-overflow-scrolling的网页，会创建一个UIScrollView，提供子layer给渲染模块使用。【有待考证】
解决办法：只需要在公共样式加入下面这行代码
*{ -webkit-overflow-scrolling: touch;}
But，这个属性是有bug的，比如如果你的页面中有设置了绝对定位的节点，那么该节点的显示会错乱，当然还有会有其他的一些bug。
拓展知识： -webkit-overflow-scrolling:touch是什么？
MDN上是这样定义的：
-webkit-overflow-scrolling 属性控制元素在移动设备上是否使用滚动回弹效果.
auto: 使用普通滚动, 当手指从触摸屏上移开，滚动会立即停止。
touch: 使用具有回弹效果的滚动, 当手指从触摸屏上移开，内容会继续保持一段时间的滚动效果。继续滚动的速度和持续的时间和滚动手势的强烈程度成正比。同时也会创建一个新的堆栈上下文。

3、ios键盘唤起，键盘收起以后页面不归位
问题详情描述：
输入内容，软键盘弹出，页面内容整体上移，但是键盘收起，页面内容不下滑
出现原因分析：
固定定位的元素 在元素内 input 框聚焦的时候 弹出的软键盘占位 失去焦点的时候软键盘消失 但是还是占位的 导致input框不能再次输入 在失去焦点的时候给一个事件
解决办法：

拓展知识： position: fixed的元素在ios里，收起键盘的时候会被顶上去，特别是第三方键盘

4、安卓弹出的键盘遮盖文本框
问题详情描述：
安卓微信H5弹出软键盘后挡住input输入框，如下左图是期待唤起键盘的时候样子，右边是实际唤起键盘的样子

出现原因分析：待补充
解决办法：给input和textarea标签添加focus事件，如下，先判断是不是安卓手机下的操作，当然，可以不用判断机型，Document 对象属性和方法，setTimeout延时0.5秒，因为调用安卓键盘有一点迟钝，导致如果不延时处理的话，滚动就失效了

拓展知识：
Element.scrollIntoView()方法让当前的元素滚动到浏览器窗口的可视区域内。而Element.scrollIntoViewIfNeeded()方法也是用来将不在浏览器窗口的可见区域内的元素滚动到浏览器窗口的可见区域。但如果该元素已经在浏览器窗口的可见区域内，则不会发生滚动

5、Vue中路由使用hash模式，开发微信H5页面分享时在安卓上设置分享成功，但是ios的分享异常
问题详情描述：
ios当前页面分享给好友，点击进来是正常，如果二次分享，则跳转到首页；使用vue router跳转到第二个页面后在分享时，分享设置失败；以上安卓分享都是正常

出现原因分析：jssdk是后端进行签署，前端校验，但是有时跨域，ios是分享以后会自动带上 from=singlemessage&isappinstalled=0 以及其他参数，分享朋友圈参数还不一样，貌似系统不一样参数也不一样，但是每次获取url并不能获取后面这些参数
解决办法：
(1)可以使用改页面this.$router.push跳转，为window.location.href去跳转，而不使用路由跳转，这样可以使地址栏的地址与当前页的地址一样，可以分享成功（适合分享的页面不多的情况下，作为一个单单页运用，这样刷新页面跳转，还是…）
（2）把入口地址保存在本地，等需要获取签名的时候 取出来，注意：sessionStorage.setItem(‘href’,href); 只在刚进入单应用的时候保存！【该方法未验证】

题外话：
如果能用小程序写的页面，尽量上小程序吧，H5开发在微信开发者工具里看页面效果可能看不出问题，因为不能唤起软键盘。避免频繁线上发布，可以用花生壳或者idcfengye，做内网穿透，搭建一个可以通过域名访问的开发环境的h5页面，在手机上看看效果，对了微信内置浏览器缓存机制。会导致刚提交的代码（特别是js）效果要半个小时左右才生效。

6、video兼容性问题以及解决对策
1】全屏和方向
webkit-playsinline=“true” //兼容ios
x5-playsinline=“true” //兼容安卓
x5-video-player-fullscreen=“true” //全屏方式
x5-video-orientation=“landscape” //横屏
x5-video-orientation=“portrait” //竖屏
2】微信浏览器自动播放
引入微信插件jweixin-1.2.0.js

7、阻止键盘唤起
此方法可以加在input的click事件里面：
document.activeElement.blur(); //阻止键盘唤起，安卓和ios均适用

8、ios的input框的placeholder文字下面被遮挡
给适当的font-size即可

9、ios的input框设置box-shadow没有效果，而且重叠了
请加属性：-webkit-appearance: none;

---

1、异常捕获和定位
source、performance、memory
1）浏览器控制台打断点（sourceMap打开）

控制台切换到source，点击对应的文件，找到指定的行数打上断点，然后重新运行代码。代码运行到断点处会暂停，要手动点击运行才能继续执行下去。

2）window.onerror
它是一个全局的异常处理函数，可以抓取所有的 JavaScript 异常
当 JavaScript 运行时错误（包括语法错误）发生时候， window 会触发一个 ErrorEvent 接口的 error 事件，并执行 window.onerror()。加载一个全局的 error 事件处理函数可用于自动收集错误报告。
window.onerror = function(message, source, lineno, colno, error) { … }
3）Promise
Promise().catch(e)
可以捕获异步的异常
4）try…catch(e)…
只能捕获同步的异常
5）关于 Vue 异常捕获
Vue 自身已经通过 try…catch… 处理，而不会触发 window.onerror 事件
使用 Vue.config.errorHandler 对 Vue 进行全局的异常捕获
可以在控制台打印一下相关的报错信息，注意默认这个捕获的方法是不会在控制台打印的，这对于我们开发来讲是不友好的
Vue.config.errorHandler = function (err, vm, info) {
// handle error
// info 是 Vue 特定的错误信息，比如错误所在的生命周期钩子
// 只在 2.2.0+ 可用
}
6）关于 sourcemap
我们在使用webpack时，运行时的打包后的代码，然而打包后的代码是经过转换压缩了的，如果我们在开发过程中代码出现了错误，在浏览器中只能定位到打包后的代码中出现错误的地方，而无法定位到打包前代码的错误位置，这使得我们在查找错误点时相当的麻烦。
然而有了SourceMap，它可以对打包前后的文件进行映射。Source map就是一个信息文件，里面储存着位置信息。也就是说，转换后的代码的每一个位置，所对应的转换前的位置。有了这种映射关系后，出错时，可以在控制台直接显示源代码中出错的位置。
要想在webpack的生成Source Map也很简单，我们只需要进行简单的配置即可，有一个叫做devtool的属性。
//webpack.config.js
module.exports = {
devtool: ‘source-map’
}
但是出自安全方面的考虑，生产上不建议使用 sourcemap，本地 webpack 打包依然生成 sourcemap 文件，但是我们不上传到服务器，仅供本地使用。
7）埋点
目前一些公司流行的做法
8）已上线的H5
a、利用vConsole插件进行排查，在URL里面埋一个后门，传输指定的参数过去即可显示
b、利用whistle代理插件模拟后端API请求，从而结合数据来一起排查

2、利用浏览器控制台进行调试（内存泄漏如何排查 / 常规BUG排查思路）
场景：
1个表单，由很多行子表单组成，每1行包含很多子组件，然后发现表单使用过程中很卡顿。
解决方案：
卡顿的原因很多种，具体情况具体分析
1、提交时卡顿
可能跟后端接口有关，这个找后端来一起联调排查
2、未提交前 使用卡顿
可能因为代码一些逻辑引发了内存泄漏
利用Chrome浏览器控制台的Memory里面的profiles进行快照
1】打开控制台上的Memory面板。
2】选择堆快照类型。我一般是使用前两种：Heap snapshot（JS堆快照）
3】开始录制前先点击下垃圾回收–>点击开始录制

4】JS堆快照切换为Comparison 对比视图：对比两个快照
对比不同操作之后的堆快照，查看内存的释放及引用计数，来分析内存是否泄露及其原因。

new是新增的对象，delete是回收的对象，delta对象变化值（新增-回收）
可以根据前后两次delta值的变化，来判断是否存在内存泄漏。
5】具体定位到哪一部分的代码存在内存泄漏

在Class filter(类过滤器)文本框中输入Detached可以搜索分离的DOM树。如果分离节点被JS引用，有可能就是泄露点。
注意：这里需要打开webpack里面的sourceMap，更加方便找到代码之间的映射关系。