某日 16时 30分,监控实时大盘中全站 JavaScript 异常和 404 异常分别朝着不同的方向延伸, 橙色的 JavaScript 异常急剧上升。

详细数据中我们看到一向高标准高质量的收银台出现异常大量的异常。

我们发现其中有两个页面异常最多,而这两个页面中异常最多的『一个异常』详情如下:
\n File: 同页面 URL \n Line: 1 \n Message: Uncaught SyntaxError: Unexpected token a
客户端信息:
\n pc/\n1;windows/5.1;sg/2.x;webkit/535.1 \n pc/\n1;windows/6.1;sg/2.x;webkit/535.1
堆栈信息:
分析过程非常艰辛,重现异常的过程也是一波三折,这里不做赘述,最终分析得出:
\n 搜狗浏览器的 userAgent 太坑爹,几乎所有版本都是 2.x,开发者太不专业了。最终找到内核为 webkit/535.1 的是 3.2 版。
\n 重现到老版 arale 中的 ajax 模块中对 JSON 有特殊的处理,如果浏览器内置的 JSON 不支持非标准的 JSON (如 {a:1})则 hack 做兼容。
\n 抛出异常的代码是 JSON.parse("{a: 1}")
\n 但奇怪的是这段代码是放在 try/catch 中,为什么还会有异常被监控捕获?
\n 最终发现这是搜狗浏览器 3.2版极速(webkit)模式中的特性:即使 try/catch 住的异常,
同样会被 window.onerror 捕获,但并未因此中断业务逻辑,后续的代码仍然会按照正确的
try/catch 异常处理流程进行,所以对业务本身没有影响。
\n p.s. 搜狗浏览器没有控制台,用户不会知道出了异常。
\n 另外收银台之前异常量少的主要原因是主要的页面没有引入前端监控,用户抛出了异常而我们不知道而已。

最初虽然有些争议,但我们最终决定的处理方案是监控中临时排除 sg/2.x|webkit/535.1 中
Uncaught SyntaxError: Unexpected token a 异常。
呃,考虑到搜狗浏览器的份额,我们的策略是只排除已知的异常,未知的异常看最终分析结果再考虑。
这个异常排查的主要功臣 @wsvn53,我们在排查过程中频繁使用了他开发的工具 Fedit,可以直接修改线上代码。 排查线上故 障、线下接⼝什么的都非常⽅方便。强烈建议⼤家都装上⽤用。
我仅代表我自己,想说某些毫无责任心的国产浏览器壳厂商们,你们没有创造价值, 只是在各种不同方式的索取。