背景
当发生很明显的线上问题时，我们可能直接就回滚代码了。但多数线上js error或告警 反映的只是一些边缘的case，量很小，但也是安全隐患，需要定位和排查。但由于量很小，或者触发的情况很特别，导致排查的难度大，效率低下，影响其他工作进度。所以花点时间，总结思考一下，如何提升排查疑难问题的效率
快速定位线上问题的办法
其实就2点：
- 看报错信息 + sourcemap，定位代码问题
- 找到真实用户访问链路，复现错误，再解决
展开讲一讲
1. 看报错信息 + sourcemap，定位代码问题
贴一段报错信息
TypeError: `undefined is not an object (evaluating 'n.headers')`
- webpack:///node_modules/vue-loader/lib/index.js
- 很明显是代码没有兼容好
贴一段对应sourcemap
- 找到对应代码位置，处理一下就行了
基本上一些明显的错误，直接看这些就够。
但有些情况是，报错信息很明显，但这个代码可能以前没出过问题，只是最近才开始出问题（很常见），通过查看一些最近的提交记录也很难归因，并且只是少量的用户会这样。特别是一些网站是动态生成的，有多少页面是不固定的
这种时候就需要定位真正的用户访问链路
2. 找到真实用户访问链路，复现错误，再解决
我们要模拟用户情况的话，需要充分了解用户当时的情况，所以我们需要这些信息：
-
- 可能是浏览器版本 或 mobile端 或 操作系统 兼容问题
-
了解用户使用场景：具体哪个url，url上有哪些参数，并了解url链路（中间跳了几次）
- 知道具体url + 参数 + url链路，才方便我们复现问题
-
了解用户操作链路：包括前端 + 后端
-
比如先点的哪个按钮，跳到了哪个页面，然后才报错的，这样可以缩小排查问题的范围
-
当请求到了后端时，后端很可能也有多个下游链路，并且操作步骤也很多（有日志），如果可以整个串起来，那么排查问题就会变得很轻松（相当于知道了代码执行到那一行出错的）
-
-
了解复现概率，比如10000个用户访问，80次出错，错误率0.8%
-
这种偶现的问题，我们可能很难复现。所以需要整合上面提到的信息，来帮助我们复现。 另外了解错误量级，可以协调资源 更快速的修复问题
-
如果一直复现不了，可以尝试用弱网试试
-
Q&A
Q：如何拿到真实用户的js error？
- A：公司如果没有这个基建的话，那么恭喜你，机会来了：你可以实现一套（结合开源sentry），然后推广到全公司用
Q：如何拿到真实用户的sourcemap？
- A：线上包肯定是没有sourcemap代码的，否则十分影响性能。所以只能通过上面收集到的js error，来用sourcemap包反解。 具体实现思路是：实现一个webpack plugin（假设你用webpack），作用：让项目在打包阶段，把sourcemap打包出来，然后上传到你们的服务器，完事后删除代码包里的sourcemap。然后下次捕获到线上js error时，用这个sourcemap反解出来
Q：如何拿到用户前端操作链路？
-
A：基建应该要支持这个。如果公司基建不支持的话，建议去提需求，实在不行就自己去打路径埋点。比如：页面show -> click/input/其他行为 -> 其他。然后可能还需要自己搭看板，把这些埋点串起来（用session）
-
如果公司暂时没基建的话，或者想先快速定位问题的话？
-
还可以从console.log 和 network（有埋点上报）可以看代码具体执行到哪一行断的
-
埋点和log太少，还是定位不到错误的话，可以考虑加埋点，串trace了。不过最好在开发之初，对核心业务就应该做好这些事情
-
-
Q：如何拿到后端操作链路？
- A：思路和上面一样，需要一个session id，把整条链路串起来。比如:从 SSR服务 -> 服务A -> 服务C -> 服务B，大家都用同一个session id打log，最终可以通过这个session id把整条链路的log给串起来！
如果是端上项目，还有webview环境的话，也是这个 session id把整条链路串起来的 思路
码字不易，点赞鼓励！！