应该是区别不了的，源码里没有msg字段... 展开详请

Script error. 也被称为跨域错误，当网站请求并且执行一个非本域名下的脚本的时候，如果跨域脚本发生错误，就有可能抛出这个错误。由于应用中，我们的脚本都是放在 CDN 上的，因此这种错误最为常见。 其实这并不是一个 JavaScript Bug。但出于安全考虑，浏览器会刻意隐藏其他域的 JS 文件抛出的具体错误信息，这样做可以有效避免敏感信息无意中被不受控制的第三方脚本捕获。因此浏览器只允许同域下的脚本捕获具体错误信息，而其他脚本只知道发生了一个错误，但无法获知错误的具体内容。更多信息，请参见 Webkit源码。 具体解决方式： 步骤1：资源添加 crossorigin 属性 步骤2：CDN 添加 cors 响应头，这个基本是 cdn 默认的，所以实际上我们并不需要做什么。 window.onerror 中只能捕获 Script error.，但是 try catch 中却能打印详细的错误栈。 如果不想解决，只想直接屏蔽，可以参考下一个问题，不上报特殊日志。... 展开详请

若 UA 里面有 NetType ，则 UA 是从 NetType 获取的。若没有，您用的是 navigator.connection.effectiveType || navigator.connection.type，effectiveType，则会根据您的网速推算出的一个类型，并不是实际类型。... 展开详请

我们目前通过 UA 里面的 NetType 和 navigator.connection.effectiveType 获取网络类型，前者依赖浏览器注入网络信息到 UA，后者是浏览器提供的 “等效网络类型”，并不代表真实的网络类型。navigator.connection.effectiveType 这个 API 目前还存在兼容性问题，IOS 暂不支持，所以会被识别为未知。... 展开详请

HTTP 接口的 status 是 0，有以下几种可能：超时，abort，cancel，跨域。 开发者本地调试可能没有发现这种错误，但是在用户侧却能经常发生，这个是什么原因呢？因为用户侧可能随时离开页面，或者因为网络问题把某次 HTTP 请求中断了，这种情况就会发生 status 为 0 的情况。 虽然 status 为 0 有多种情况，但是我们也可以根据日志里面的信息看出一些端倪。例如：上述截图里面的耗时都非常小，而且发生的用户比较集中，因此可以判断该接口是浏览器插件屏蔽掉了，这种情况常见于一些数据上报的接口。如果接口出现比较随机，耗时也不高，整体量也不算大，这种情况，abort 和 cancel 的概率比较大，经常发生于用户离开页面，刷新页面，接口没有请求完成的情况。如果看到 duration 非常长，那超时的可能性就比较大了，开发者也可以查看自己接口的超时时间来进行对比。至于跨域的情况，可以检查一下后台的业务逻辑是否正常，而 cancel 的情况，多半是前端业务控制的，也可以看下具体的业务逻辑。 因为用户侧可能随时离开页面，或者因为网络问题把某次 HTTP 请求中断了，这种情况就会发生 status 为 0 的情况。 虽然 status 为 0 有多种情况，但我们也可以根据日志里面的信息看出一些问题。例如上述截图里面的耗时都非常小，而且发生的用户比较集中，因此可以判断该接口是浏览器插件屏蔽掉了，这种情况常见于一些数据上报的接口。 如果看到 duration 非常长，那超时的可能性就比较大了，开发者也可以查看自己接口的超时时间来进行对比。至于跨域的情况，可以检查一下后台的业务逻辑是否正常，而 cancel 的情况，多半是前端业务控制的，也可以看下具体的业务逻辑。 SDK 通过从用户接口的返回值中的第一层和第二层中获取 code, ret, retcode, errcode 这几个参数中的任意一个，作为接口业务的返回码（区别于HTTP的状态码），默认这个返回码等于0接口为正常。 业务对于返回码有不同的定义，开发者可以通过 api 参数下的 retCodeHandler 函数对其进行矫正，retCodeHandler 函数返回 isErr 和 code 两个值。isErr 用来计算接口返回值的成功率，code 用来统计接口的返回码占比。当该函数返回 isErr 为 true 的时候，这个接口的信息会同时上报到历史日志里面的“接口返回码异常”，方便开发者定位接口问题。除此之外，还有很多非业务的接口，如一些数据上报，是不满足这些规范的，建议可以通过 beforeRequest 进行修正。 Aegis sdk 根据 DOM 变化记录首屏，如果您的 sdk 引入较晚，或者初始化较晚，可能会出现无法获取首屏的情况。如果出现这种情况的话，建议可以试着把 sdk 引入和初始化放在更前面，如 head 里，然后再观察一下数据。 有可能是因为初始化 Aegis 的时候这个接口已经发出去了。Aegis web sdk 目前只劫持了 fetch 和 xhr 两种发送请求的方式，如果您的请求是其他的方式，例如 beacon，就无法监控到。Aegis 小程序 sdk 也是通过劫持 wx.request 实现的，如果在引入 Aegis 之前，wx.request 已经被修改了，也可能监控不到，建议尽早引入和初始化 Aegis sdk。 总体来说，页面首屏和页面完全加载时间是正相关的。大多数情况下，用户的首屏时间是小于页面完全加载的。Aegis SDK 根据用户页面DOM变化计算首屏时间，如果用户页面完全加载后，还继续发生DOM变化，就有可能发生首屏时间晚于页面完全加载的情况。在服务端直出场景，瀑布图会出现首屏时间大于dom解析的情况，这是由于移动端设备兼容性问题，有些设备无法获取到DNS查询、TCP连接、SSL建连时间，这三个指标汇总后的平均值偏小，导致除了首屏时间外的其他指标都往左偏移。 接直出的页面需要注意两件事情: 1. aegis-web-sdk 只能运行在浏览器环境，所以记得在服务端不要执行初始化操作。2. SSR 页面初始化完成比较早，所以如果把 aegis-sdk 初始化放在比较靠后的地方（body里面或者最后）可能会导致 sdk 无法获取到页面首屏的情况。建议 SSR 页面使用 script 标签引入 aegis sdk，并且放在head中初始化，解决上述两个问题。 aegis sdk 上报数据的时候，默认只上报了接口的 url，没有上报参数，对于这种情况，我们提供 reportApiSpeed.urlHandler 钩子函数对上报内容进行修正，用户可以根据 urlHandler 参数里面的内容进行优化。 例如：腾讯云控制台上的接口，名称统一都是 console.cloud.tencent.com/cgi/capi，接口真实名称通过参数里面的 cmd 确定，这样的情况，优化方式如下：... 展开详请

接口403一般是因为页面域名校验失败导致的，可以检查应用创建时候设置的域名跟实际上报的域名是否一致。如果应用不需要校验，域名可以填 *。 用户在 RUM 上创建应用后，会得到一个长度为 18 位的字符串，这个字符串为上报 ID，new Aegis 的时候传入的 ID 就是这个上报 ID。如果这个 ID 不正确，也会报403。 Aegis 初始化... 展开详请