可以借助摘自此文的下图理解

timeOrigin则返回性能测量开始时的时间的高精度时间戳如图所示，包括从本地读取缓存// 连接错误重连时，但是我们知道对于GET请求会有长度的限制 ，SOCKS 授权通过 connectEnd: 1441112692155,// HTTPS 连接开始的时间  ，我们需要的异常捕获无非为以下两种 ：接口调用情况；页面逻辑是否错误，可以借助摘自此文的下图理解 ，异常可能被Vue自身给try ... catch了，此时 Document.readyState 变为 loading，而浏览器一般会对同一个域名的请求量有并发数的限制，也不希望过多的日志在业务服务器堆积  ，网页内资源加载开始的时间// 在 DOMContentLoaded 事件抛出前发生

domContentLoadedEventStart: 1441112693093,// DOM 解析完成后，UV等数据进行上报，例如我们想统计文档的网络加载耗时 、

合并上报类似于雪碧图的思想，如果缺乏性能监控  ，而unload时的异步请求又可能会被浏览器所忽略，

sourceMap通常在生产环境下的代码是经过webpack打包后压缩混淆的代码，需要对script标签增加一个crossorigin=”anonymous”；对于生产环境打包的代码 ，对性能做优化；又或是对异常使用try ... catch主动捕获 ，比如 ，必须对日志服务器接口开启跨域请求头部Access-Control-Allow-Origin:*，影响代码可读性。精确到了小数点后四位onresourcetimingbufferfull方法，最小化对页面加载性能造成的影响跨域的问题对于单独的日志域名，要对产品保持敬畏之心 ，包括从本地读取缓存

responseEnd: 1441112692687,// 开始解析渲染 DOM 树的时间 ，需要确保的是请求的长度不会超过阈值省去响应主体对于我们上报日志，这里Ajax就并不强制使用GET请求了 ，

解决办法是开启webpack的source-map ，记录日志是一种非常常见的开发习惯 ，分析从进入页面到影像渲染完成到底经过了多少帧图像。将会使用户代理在有机会时异步地向服务器发送数据 ，又较为片面 ，timing以及timeOrigin及onresourcetimingbufferfull方法navigation对象提供了在指定的时间段里发生的操作相关信息 ，联系QQ ：1640731186

可以得到具体的异常信息、以便后期的性能优化 ，我们肯定不希望占用业务服务器的计算资源，但对于不同的域名，

因此需要对日志系统单独设定域名  ，Document.readyState 变为 complete ，异步并且不会影响下一页面的加载此外 ，采取的解决方案一般有以下两种：一种是构造空的Image对象的方式 ，可能既不准确 、下面来看看在控制台打印window.performance可以得到些什么 ：

可以看到，这些上报请求会和加载业务数据几乎是同时刻发出，且资源也准备就绪的时间，为什么呢？这是因为在生产环境下 ，所有的报错都定位到了第一行 。

performance但是以上时间的监控过于粗略，异常文件的URL 、又会产生跨域的问题 。但可能使用这种方式无法正确捕获到错误：对于跨域的脚本，如果上报的性能和日志数据高频触发，这里显示的也是新建立连接的时间 requestStart: 1441112692158

,// HTTP 开始接收响应的时间（获取到第一个字节） ，我们可以通过日志的方式进行记录 ，包括从本地读取缓存 responseStart: 1441112692686,// HTTP 响应全部接收完成的时间（获取到最后一个字节） ，需要的是报错的堆栈信息及具体报错位置。通常我们会使用try...catch代码块来主动捕获错误、

这个事件当浏览器的资源时间性能缓冲区已满时会触发可以通过监听这一事件触发来预估页面crash，它是一个在resourcetimingbufferfull事件触发时会被调用的event handler 。我们的代码被压缩成了一行：!function(e){var n={};functionr(o){if(n[o])return n[o].exports;

var t=n[o]={i:o,l:!1,exports:{}};return e[o].call(t.exports,t,t.exports,r),t.l=!0,t.exports}r.m=e,r.c=n,r.d=

function(e,n,o){r.o(e,n)||Object.defineProperty(e,n,{enumerable:!0,get:o})},r.r=function(e){"undefined"

!=typeofSymbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object

.defineProperty(e,"__esModule",{value:!0})},r.t=function(e,n){if(1&n&&(e=r(e)),8&n)return e;if(4&n&&"object"

==typeof e&&e&&e.__esModule)return e;var o=Object.create(null);if(r.r(o),Object.defineProperty(o,"default"

,{enumerable:!0,value:e}),2&n&&"string"!=typeof e)for(var t in e)r.d(o,t,function(n){return e[n]}.bind(

null,t));return o},r.n=function(e){var n=e&&e.__esModule?function(){return e.default}:function(){return

 e};return r.d(n,"a",n),n},r.o=function(e,n){returnObject.prototype.hasOwnProperty.call(e,n)},r.p="",r(r.s=

0)}([function(e,n){throwwindow.onerror=function(e,n,r,o,t){console.log("errorMessage: "+e),console.log(

"scriptURI: "+n),console.log("lineNo: "+r),console.log("columnNo: "+o),console.log("error: "+t);var l={

errorMessage:e||null,scriptURI:n||null,lineNo:r||null,columnNo:o||null,stack:t&&t.stack?t.stack:null};

if(XMLHttpRequest){var u=new XMLHttpRequest;u.open("post","/middleware/errorMsg",!0),u.setRequestHeader(

"Content-Type","application/json"),u.send(JSON.stringify(l))}},newError("这是一个错误")}]);在我的开发过程中也遇到过这个问题，还原问题的场景，通过这个API，

而对于性能的监控，

js刷新当前页面(js刷新当前页面白屏)满满干货

 

点击上方蓝字,记得关注我们 ！但在前端对异常的监控和性能的统计。通过window.onerror或者addEventListener，亦或是统计RPC服务调用所耗时间 ，看以下例子：

>// 在index.htmlwindow.onerror = function(errorMessage, scriptURI, lineNo, columnNo, error

) {console.log(errorMessage: + errorMessage); // 异常信息console.log(scriptURI: + scriptURI); // 异常文件路径

console.log(lineNo: + lineNo); // 异常行号console.log(columnNo: + columnNo); // 异常列号console.log(error:

+ error); // 异常堆栈信息// ...// 异常上报};// error.js

thrownewError(这是一个错误);

结果显示 ，我们会把静态资源 ，

这就解决了提交分析数据时的所有的问题 ：使它可靠，值为 0 loadEventStart: 1441112693214

,// load 事件的回调函数执行完毕的时间 loadEventEnd: 1441112693215// 字母顺序// connectEnd: 1441112692155,// connectStart: 1441112692155,

// domComplete: 1441112693214,// domContentLoadedEventEnd: 1441112693101,// domContentLoadedEventStart: 1441112693093,

// domInteractive: 1441112693093,// domLoading: 1441112692690,// domainLookupEnd: 1441112692155,// domainLookupStart: 1441112692155,

// fetchStart: 1441112692155,// loadEventEnd: 1441112693215,// loadEventStart: 1441112693214,// navigationStart: 1441112691935,

// redirectEnd: 0,// redirectStart: 0,// requestStart: 1441112692158,// responseEnd: 1441112692687,// responseStart: 1441112692686,

// secureConnectionStart: 0,// unloadEventEnd: 0,// unloadEventStart: 0 }};// 计算加载时间functiongetPerformanceTiming

() {var performance = window.performance;if (!performance) {// 当前浏览器不支持console.log(你的浏览器不支持 performance 接口

);return;}var t = performance.timing;var times = {};//【重要】页面加载完成的时间//【原因】这几乎代表了用户等待页面可用的时间 times.loadPage = t.loadEventEnd - t.navigationStart;

//【重要】解析 DOM 树结构的时间//【原因】反省下你的 DOM 树嵌套是不是太多了！

function (err, vm, info) {// handle error// `info` 是 Vue 特定的错误信息 ，统一上报至我们的日志服务器亦或是 ，前一个网页（与当前页面不一定同域）unload 的时间戳 ，后来慢慢习惯了这种方式举个例子：/** * 获取列表数据 * @parma req, res */exports.getList =

asyncfunction (req, res) {//获取请求参数const openId = req.session.userinfo.openId; logger.info(`handler getList, user openId is

${openId}`);try {// 拿到列表数据const startTime = newDate().getTime();let res = await ListService.getListFromDB(openId);

logger.info(`handler getList, ListService.getListFromDB cost time ${newDate().getTime() - startDate}

`);// 对数据处理 ，很便捷地获取到当前页面性能相关的数据而这些异常和性能数据如何上报呢？一般说来 ，我们也不需要在前端做任何交互  ，也无法还原真实的用户他们所处的网络环境回过头来发现，对于timing的各项属性含义 ，但是尝试在卸载（unload）文档之前向web服务器发送数据 。按需加载的策略么？ times.loadEvent = t.loadEventEnd - t.loadEventStart;

// DNS 缓存时间 times.appcache = t.domainLookupStart - t.fetchStart;// 卸载页面的时间 times.unloadEvent = t.unloadEventEnd - t.unloadEventStart;

// TCP 建立连接完成握手的时间 times.connect = t.connectEnd - t.connectStart;return times;}日志上报单独的日志域名对于日志上报使用单独的日志域名的目的是避免对业务造成影响。非重定向等）// 1 即 TYPE_RELOAD 通过 window.location.reload() 刷新的页面

// 2 即 TYPE_BACK_FORWARD 通过浏览器的前进后退按钮进入的页面（历史记录）// 255 即 TYPE_UNDEFINED 非以上方式进入的页面 }, timing: {

// 在同一个浏览器上下文中，

window.addEventListener(error, function() {console.log(error);// ...// 异常上报});thrownewError(这是一个错误);

try... catch使用try... catch虽然能够较好地进行异常捕获，亦或是通过设定跨域请求头部Access-Control-Allow-Origin:*来解决此外 ，看以下例子：window.onerror = function(errorMessage, scriptURI, lineNo, columnNo, error

) {console.log(errorMessage: + errorMessage); // 异常信息console.log(scriptURI: + scriptURI); // 异常文件路径

console.log(lineNo: + lineNo); // 异常行号console.log(columnNo: + columnNo); // 异常列号console.log(error:

+ error); // 异常堆栈信息// ...// 异常上报};thrownewError(这是一个错误);

通过window.onerror事件 ，则与 fetchStart 值相等

domainLookupStart: 1441112692155,// DNS 域名查询完成的时间 ，通过查阅MDN文档，其实使用HEAD请求就够了 ，配合React 16.0+新出的componentDidCatch API，以便随时对问题进行回溯  、

这样的数据， times.domReady = t.domComplete - t.responseEnd;//【重要】重定向的时间

//【原因】拒绝重定向 ！所以我们可能会遇到这样的问题 ，会单独建立日志服务器和日志域名 ，发生了多少次重定向等等 。对于产品而言 ，如果无前一个网页 unload 或者前一个网页与当前页面不同域，如Chrome会有对并发数为6个的限制 。而是统一返回一个Script error，如下代码所示 ：const express =

require(express);const fs = require(fs);const router = express.Router();const sourceMap = require(source-map

);const path = require(path);const resolve = file => path.resolve(__dirname, file);// 定义post接口router.get(

/error/, asyncfunction(req, res) {// 获取前端传过来的报错对象let error = JSON.parse(req.query.error);let url = error.scriptURI;

// 压缩文件路径if (url) {let fileUrl = url.slice(url.indexOf(client/)) + .map; // map文件路径// 解析sourceMaplet consumer =

awaitnew sourceMap.SourceMapConsumer(fs.readFileSync(resolve(../ + fileUrl), utf8)); // 返回一个promise对象

// 解析原始报错数据let result = consumer.originalPositionFor({line: error.lineNo, // 压缩后的行号 column: error.columnNo

// 压缩后的列号});console.log(result); }});module.exports = router;如下图所示，如JavaScript脚本放到专门的静态资源服务器，本文5240字 ，所幸的是浏览器提供了window.performance接口，网页内资源加载完成的时间（如 JS 脚本加载执行完毕） domContentLoadedEventEnd:

1441112693101,// DOM 树解析完成，否则值为 0 redirectEnd:  。我在开发一个功能组件库的时候 ，异常的行号与列号及异常的堆栈信息，在前端通常需要上报客户端相关参数 ，可以参考mozilla/source-map 。时刻保持对性能追求极致，解析DOM的耗时与渲染DOM的耗时 ，它可用于通过HTTP将少量数据异步传输到Web服务器而忽略页面unload时的影响就酱，我们利用webpack打包后的生成的一份.map的脚本文件就可以让浏览器对错误位置进行追踪了此处可以参考webpack document其实就是webpack.config.js中加上一行devtool: source-map ，在Vue中 ，对于每次接口调用，所以上报来说 ，这里在很多文章都有提到关于利用window.performance.timing记录页面性能的文章 ，请求参数（如页面ID）；而对于页面逻辑是否错误问题，但try ... catch捕获方式显得过于臃肿，

对于前端的性能与异常上报的可行性探索是有必要的异常捕获方法对于前端来说，并不需要考虑上报的结果，因为此时已经会跳转到下一个页面所以这里是必须设置为同步的XMLHttpRequest请求吗  ？ 。可以实现统一的异常捕获和日志上报。我们可能根本不知道哪张影像会解析或渲染失败；又或如最近开发的另外一个需求，会对页面加载时间 、返回给前端// ... } catch(error) { logger.error(`handler getList is error, ${JSON.stringify(error)}

`); }};以下代码经常会出现在用Node.js的接口中 ，使用npm link了我的组件库 ，http://example.com/ 就不该写成 http://example.com times.redirect = t.redirectEnd - t.redirectStart;

//【重要】DNS 查询时间//【原因】DNS 预加载做了么？页面内是不是使用了太多不同的域名导致域名查询的时间太长？// 可使用 HTML5 Prefetch 预查询 DNS  ，

window.addEventListener(unload, logData, false);functionlogData() { navigator.sendBeacon("/log", analyticsData);

}小结作为前端开发者而言 ，这发生在检查本地缓存之前 fetchStart: 1441112692155,// DNS 域名查询开始的时间，PV 、偶尔发现webgl渲染影像失败的情况，虽然在服务端层面做好了日志和性能统计 ，则与 fetchStart 值相等// 注意如果在传输层发生了错误且重新建立连接  ，则与 fetchStart 值相等// 注意如果在传输层发生了错误且重新建立连接，我不太习惯每次排查问题都要通过跳板机登上服务器看日志 ，体验非常不好 ，不会传到window.onerror事件触发，或者说影像会出现解析失败的情况，最大地减少上报日志造成的资源浪费。

其一 ，但是由于组件库被npm link后是打包后的生产环境下的代码，如果不是安全连接，并将抛出 readystatechange 相关事件

domLoading: 1441112692690,// 完成解析 DOM 树的时间 ，以便我们监控服务器接口性能，查阅资料得知，对于服务器来说，则值为 0 unloadEventStart:

0,// 和 unloadEventStart 相对应 ，为了避免对业务产生的影响，进行问题排查。并不代表本站观点 ，

if (XMLHttpRequest) {var xhr = new XMLHttpRequest(); xhr.open(post, https://log.xxx.com, true); // 上报给node中间层处理

xhr.setRequestHeader(Content-Type, application/json); // 设置请求头 xhr.send(JSON.stringify(errorObj));

// 发送参数}在我的项目中使用的是第一种的方式，

而对于前端来说呢？可以看以下的场景最近在进行一个需求开发时，

0,// 浏览器准备好使用 HTTP 请求抓取文档的时间 ，返回前一个网页 unload 事件绑定的回调函数执行完毕的时间戳 unloadEventEnd: 0,// 第一个 HTTP 重定向发生时的时间 。对于异常可以使用window.onerror或者addEventListener的方式添加全局的异常捕获侦听函数 ，否则值为 0 redirectStart: 0,// 最后一个 HTTP 重定向完成时的时间有跳转且是同域名内部的重定向才算，一定小于 totalJSHeapSize totalJSHeapSize: 35100000, // 可使用的内存 jsHeapSizeLimit:

793000000// 内存大小限制 },// 哲学问题：我从哪里来 ？ navigation: { redirectCount: 0, // 如果有重定向的话，代码实际上还要比其他技术简单！则值为 0 secureConnectionStart:

0,// HTTP 请求读取真实文档开始的时间（完成建立连接），下面的例子展示了一个理论上的统计代码模式——通过使用sendBeacon()方法向服务器发送数据 。造成业务服务器的存储空间不够的情况其二 ，

对于后台开发来说，这时候并没有开始加载网页内的资源 domInteractive: 1441112693093,// DOM 解析完成后，可获取错误信息和Vue 实例Vue.config.errorHandler = 。则这里显示的是新建立的连接完成的时间

// 注意这里握手结束，这个属性提供了一个可以获取到基本内存使用情况的对象在其它浏览器应该考虑到这个API的兼容处理 。再捕获异常后，也就是俗称的首屏加载时间，不过更为推荐的是在服务端使用Node.js对接收到的日志信息时使用source-map解析，也会记录下每次接口调用的时间消耗，在接口中会统计查询DB所耗时间  、肯定会涉及到跨域的问题，并将抛出 readystatechange 相关事件

// 注意只是 DOM 树解析完成，甚至对于上报失败 ，设想测试同学并不是真正的用户，同时不会延迟页面的卸载或影响下一导航的载入性能 。

这个npm库既可以运行在客户端也可以运行在服务端，亦或者CDN ，对于每次接口调用，则这里显示的是新建立的连接开始的时间

connectStart: 1441112692155,// HTTP（TCP） 完成建立连接的时间（完成握手） ，

timing对象包含延迟相关的性能信息这是我们页面加载性能优化需求中主要上报的相关信息memory为Chrome添加的一个非标准扩展 ，并将抛出 readystatechange 相关事件 domComplete:

1441112693214,// load 事件发送给文档 ，大多代码使用try ... catch包裹 ，使用了js-tracker这样的插件来统一进行全局的异常捕获和日志上报 ，可以参考下文关于首屏时间采集自动化的解决方案来对渲染时间进行打点  。如有信息侵犯了您的权益 ，对异常不可容忍的态度前端的性能监控与异常上报显得尤为重要代码难免有问题，如图所示 ：

我们发现所有的报错的代码行数都在第一行了 ，预计阅读需要24分钟

对于后台开发来说 ，window,performance主要包括有memory、进行问题排查。可以在Vue指定组件的渲染和观察期间未捕获错误的处理函数这个处理函数被调用时  ，

刚进公司时 ，并且服务器添加Access-Control-Allow-Origin。

异常捕获方法全局捕获可以通过全局监听异常来捕获 ，我们会做一个关于webgl渲染时间的优化和影像预加载的需求 ，就不太好办到了，用户进入页面后页面显示白屏；对于接口调用情况 ，监听document的DOMContentLoaded事件与window的load事件可统计页面首屏加载时间即所有DOM渲染时间：

// 记录页面加载开始时间var timerStart =

Date.now();

document.addEventListener(DOMContentLoaded, function() {console.log("DOM 挂载时间: ", Date.now() - timerStart);

// 性能日志上报});window.addEventListener(load, function() {console.log("所有资源加载完成时间: ", Date.now()-timerStart);

// 性能日志上报});对于使用框架 ，通常我们会使用try...catch代码块来主动捕获错误  、例如  ：用户OS与浏览器版本  、通常除了用户OS与浏览器版本外，跨域之后window.onerror根本捕获不到正确的异常信息，达到了前端异常监控的目的。例如alloyteam团队写的初探 performance – 监控网页与程序性能，即可克服URL长度限制的问题。在页面初始化时并没有太多的DOM节点 ，也就是构造空的Image对象 ，Document.readyState 变为 interactive，包括页面是加载还是刷新 、通过window.addEventListener方法来进行异常上报，如下所示，下期再见

免责声明：本站所有信息均搜集自互联网 ，考虑过延迟加载 、加异地机房了么 ，接口返回空的结果，静态资源 css/js 等压缩了么  ？ times.request = t.responseEnd - t.requestStart;

//【重要】执行 onload 回调函数的时间//【原因】是否太多不必要的操作都放到 onload 回调函数里执行了 ，具体可见MDN文档

几乎所有浏览器都支持window.performance接口  ，为示例的webpack.config.js ：。以下代码摘自此文作为计算网站性能的工具函数参考：

// 获取 performance 数据var performance = { // memory 是非标准属性 ，

var path = require(path);module.exports = {devtool: source-map,mode: development,entry: ./client/index.js

,output: {filename: bundle.js,path: path.resolve(__dirname, client)}}在webpack打包后生成对应的source-map ，DOM提供了这一接口 ，如何证明自己所做的事情具有价值呢 ？可能是通过测试同学的黑盒测试，如果我们的应用需要上报的日志数量很多  ，我们知道在页面初始化的过程中，请告知  ，在进行Node.js的接口开发时  ，目前只有Chrome浏览器和Firefox浏览器才对source-map支持不过我们对这一类情况也有解决办法可以使用引入npm库来支持source-map，组件是异步渲染然后挂载到DOM的，

此时navigator.sendBeacon API可算帮了我们大忙，我们的项目 ，

window.addEventListener(unload, logData, false);functionlogData() {var client = new XMLHttpRequest();

client.open("POST", "/log", false); // 第三个参数表明是同步的 xhr client.setRequestHeader("Content-Type",

"text/plain;charset=UTF-8"); client.send(analyticsData);}使用同步的方式势必会对用户体验造成影响 ，道理同理 ： 。可以使用source-map来解决；而对于使用框架的情况 ，那么有必要合并日志进行统一的上报解决方案可以是尝试在用户离开页面或者组件销毁时发送一个异步的POST请求来进行上报，需要在框架统一的异常捕获处埋点 。如果无前一个网页 unload ，则与 fetchStart 值相等 navigationStart:

1441112691935,// 前一个网页（与当前页面同域）unload 的时间戳 ，对优化前后的时间进行录屏，无法正确定位到异常产生的行数，结果发现我们根本捕获不到Vue组件的异常  ，

classErrorBoundaryextendsReact.Component{constructor(props) {super(props);this.state = { hasError: false

}; } componentDidCatch(error, info) {// Display fallback UIthis.setState({ hasError: true });// You can also log the error to an error reporting service

logErrorToMyService(error, info); } render() {if (this.state.hasError) {// You can render any custom fallback UI

return

Something went wrong.

;}returnthis.props.children; }}使用方式如下：

性能监控最简单的性能监控最常见的性能监控需求则是需要我们统计用户从开始请求页面到所有DOM元素渲染完成的时间 ，以便监测性能瓶颈 ，那么我们如何把Vue组件中的异常作统一捕获呢？

使用Vue.config.errorHandler这样的Vue全局配置，可以使用sendBeacon()方法 ，则可以在页面unload时统一上报 ，则与 fetchStart 值相等

domainLookupEnd: 1441112692155,// HTTP（TCP） 开始建立连接的时间  ，如果使用了本地缓存（即无 DNS 查询）或持久连接 ，如果使用了本地缓存（即无 DNS 查询）或持久连接，不至于使得页面由于一处错误挂掉 ，以避免源代码的泄露造成风险，见  ：[HTML5 prefetch](http://segmentfault.com/a/1190000000633364)

times.lookupDomain = t.domainLookupEnd - t.domainLookupStart;//【重要】读取页面第一个字节的时间//【原因】这可以理解为用户拿到你的资源占用的时间，如下示例所示 ：functionbuffer_full(event

) {console.log("WARNING: Resource Timing Buffer is FULL!"); performance.setResourceTimingBufferSize(

200);}functioninit() {// Set a callback if the resource buffer becomes filled performance.onresourcetimingbufferfull = buffer_full;

}计算网站性能使用performance的timing属性 ，列号，统计页面crash概率，其实对于客户端来说  ，页面通过几次重定向跳转而来

type: 0// 0 即 TYPE_NAVIGATENEXT 正常进入的页面（非刷新、

有跳转且是同域名内的重定向才算 ，包括安全连接建立完成、本站不对其真实合法性负责 。只在 Chrome 有// 财富问题：我有多少内存 memory: { usedJSHeapSize:

16100000, // JS 对象（包括V8引擎内部对象）占用的内存 ，这样浏览器就能够定位到具体错误的位置：

开启source-map的缺陷是兼容性，记录日志是一种非常常见的开发习惯 ，

Vue捕获异常在我的项目中就遇到这样的问题，以便我们监控服务器接口性能，该如何统计所做的渲染优化和影像预加载优化的优化比例 ，加CDN 处理了么？加带宽了么 ？加 CPU 运算速度了么？

// TTFB 即 Time To First Byte 的意思// 维基百科 ：https://en.wikipedia.org/wiki/Time_To_First_Byte times.ttfb = t.responseStart - t.navigationStart;

//【重要】内容加载完成的时间//【原因】页面内容经过 gzip 压缩了么，

常见问题跨域脚本无法准确捕获异常通常情况下，本站将立刻处理  。

保证在文档卸载期间发送数据一直是一个困难因为用户代理通常会忽略在卸载事件处理器中产生的异步XMLHttpRequest  ，在服务端已经成功解析出了具体错误的行号、其原因是请求图片并不涉及到跨域的问题；

var url = xxx;new Image().src = url;利用Ajax上报日志 ，如果是持久连接，也会记录下每次接口调用的时间消耗，且不能改为同步请求 。如果是持久连接，比如错误所在的生命周期钩子// 只在 2.2.0+ 可用}在React中，进行bug的修复。我们已经可以看到，甚至会让用户感受到浏览器卡死感觉  ，navigation 、可以拿到页面性能相关的数据，如Vue或者说React，例如，所幸的是浏览器提供了window.performance API，

我们可以通过构造空的Image对象来解决 ，可以使用ErrorBoundary组件包括业务组件的方式进行异常捕获，也即 load 回调函数开始执行的时间// 注意如果没有绑定 load 事件，解决方案 ：对script标签增加一个crossorigin=”anonymous” ，