如何尽可能早的捕获JS 异常？

背景

前段时间，超级会员的业务上线之后，总有人反馈它的会员落地页打不开了，打开就是空白。空白页

反馈不多，但是总是有几个人持续在反馈.

用户ID：23，用户积分兑换页面进入总是进不去，好几天了。已经清理过缓存

严选|赖* 11:02:00 用户ID: 93 用户反馈切换网络，清理缓存，退出登录都是无法进入签到页面

起初是根据反馈人数不多，加载页面速度过快等 APM 数据，以为它的网络被劫持了。随着这批用户持续的反馈，

活动组|徐** 18:16:07用户反馈电脑和手机均无法进入带有会员活动的页面，试过了UC 华为自带谷歌，客户说明都是已经试过了而且在公司使用公司网络其他同事可以点开，用其他手机登录自己账户就无法点开

从用户反馈的操作来看，初步排除用户被劫持。经过各种 traceId 和后端排查，确定是请求没有到后端、应该是前端很早的时候，JS 出错导致后续 JS 逻辑没有执行，应该和用户自己的数据有关系，那到底是什么数据呢？

如何定位 JS 异常信息

如果是和用户账号相关，有以下方式获取错误信息：

申请启用白名单，免密登录用户信息，在本地尝试复现—— 目前严选不支持此类免登服务
使用 APM 平台获取此用户 UID 相关信息—— 当时超会页面没有接入 APM，而且 APM 捕获的时机比较靠后，实际上是抓不到这种很早就出错的异常。
启用远程协助调试——严选没有，也没有业界可里参考的例子，最初的想法是需要用户人肉配合我们在他自己的手机上调试问题。

远程协助调试

构想是：我们编写一个和超会同域名的页面，让用户帮忙用 App 扫码打开，然后让用户把他看到的错误信息回传给我们，供我们分析，从而定位问题。根据定位问题的难易程度，定义了以下指标：

主要采集信息项

指标性	目的
1. JS 执行错误	用来排查是否有脚本错误。
2. response （html）源码	用来排查是否 html 被篡改
3. 所有 JS 的 response	用来排查 JS 劫持
4. 是否是缓存导致的问题	通过追加时间戳确认问题所在
5. 远程页面调试	遇到上述情况还没有解决的问题，需要启用 weinre 远程调试。

本文重点介绍下如何去捕获页面的脚本错误，思路如下：

使用 window.onerror 来捕获脚本错误，参考来源, MDN GlobalEventHandlers，忽略个别不 bubble up 的错误异常。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


window.onerror = function (msg, url, lineNo, columnNo, error) {
  var string = msg.toLowerCase();
  var substring = "script error";
  if (string.indexOf(substring) > -1){
    alert('Script Error: See Browser Console for Detail');
  } else {
    var message = [
      'Message: ' + msg,
      'URL: ' + url,
      'Line: ' + lineNo,
      'Column: ' + columnNo,
      'Error object: ' + JSON.stringify(error)
    ].join(' - ');

    alert(message);
  }

  return false;
};

考虑到超会页面脚本出错较早，一种方式是把以上脚本放在超会页面 html 页面结构的尽可能前面。但是问题1，**究竟多前面才能算前面呢？放到标签第一个元素吗？**问题2，需要在原来的超会页面基础上添加调试代码，不够通用，如果是积分页面那又要改一遍吗？问题3，对真实页面 JS 加载有干扰。这种方案不行。
在 WKWebView 里注册 documentStart 时机的脚本。

1
2


WKUserScript *userScript = [[WKUserScript alloc] initWithSource:js injectionTime:WKUserScriptInjectionTimeAtDocumentStart forMainFrameOnly:YES];
    [userContentController addUserScript:userScript];

这种方案的问题是，1. Android 不能用；2. 需要客户发版，不适合紧急调试；2. 对真实的页面加载有干扰，客户端和 h5 需要配合，不好控制。

终极方案

我们最后想到一种不用修改旧页面结构，不干扰真实页面加载，而且还能尽可能早，捕获一切 JS 异常的方案，堪称 JS 界的防侧漏—— 使用 iframe 加载来监听。核心代码如下，

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>页面故障白屏自助排查工具</title>
</head>

<body>
    <iframe id="iframe" name="iframe" src="<真实调试页面地址>"></iframe>
    <script>
        var h5Iframe = document.getElementById('iframe');
        h5Iframe.contentWindow.window.onerror = function iframe_onerror(msg, url, lineNo, columnNo, error) {
            var string = msg.toLowerCase();
            var substring = "script error";
            if (string.indexOf(substring) > -1) {
                alert('Script Error: See Browser Console for Detail');
            } else {
                var message = [
                    'Message: ' + msg,
                    'URL: ' + url,
                    'Line: ' + lineNo,
                    'Column: ' + columnNo,
                    'Error object: ' + JSON.stringify(error)
                ].join(' - ');

                alert(message);
            }

            return false;
        };
    </script>
</body>

</html>

只需要把包含代码的页面发送给用户，让用户打开（其实真实调试页面还包含了其他的排查问题手段）。在搭建好调试页面之后，我们通过电话回访联系到用户，让他实操了下，一打开页面就发现问题所在。 JS 异常再经过其他文件分析，最后发现是在整个 html 骨架下面第一个 FreeMark 产生的 Script 脚本出错了。具体错误可见参考本文提供的 JSErrorCatch demo。

总结

使用 在 WKWebView 里注册 documentStart 时机的脚本 的方案是扩展性比较好的实现 APM 能力的方式，但不跨平台；使用 iframe 的方式不适合做日常的 APM 数据采集，而作为临时的远程协助调试能力是个不错的选择。

后续

本文旨在介绍一种简单实用捕获 JS 异常的方案。但它的目的是如何发现线上，个别用户的运行错误信息，不知道业界有没有合适的方案能分享，让我们学习一下。

Contents

背景

如何定位 JS 异常信息

远程协助调试

主要采集信息项

终极方案

总结

后续