怎么应对复现不了的 bug？

[nnegier]

就是有些 bug 比如闪退比如功能异常发生在特定的某些手机上，但是找来了同型号手机依旧是复现不了那个问题。因为复现不了，虽然有报错日志，但弄起来极其没底没边。因为涉及到隐私和用户不便也不能向客户要来手机 debug ，就很为难，而且有些用户它只是告诉你有问题（当然这样已经比很多用户好了，更多的用户是有 bug 就直接不用了，懒得告诉你），就没然后了，也无法继续联系交流

[maigebaoer]

随缘吧，能修就修，不能就算了

[IsuYww83LvR48EaC]

崩溃日志上传

[nnegier]

@jiaqizhang 有的

[lakehylia]

崩溃堆栈收集啊

[opengps]

这种神级 bug 的分析不能靠自己，多找几个不同开发风格的人来围观评论下

[NoOneNoBody]

眼不见为净

[iyiluo]

日志，超详细的日志，碰到很多难复现的 bug 最后都是靠日志里面的蛛丝马迹发现线头的

[mogutouer]

写好日志，等一个运气不好的

[9c04C5dO01Sw5DNL]

再想想，捣鼓捣鼓

[402124773]

学习如何 battle ，降 bug 等级。

[Baymaxbowen]

先针对这个 bug 的现象打个补丁上去再说😂

[liuhuansir]

我司复现不了的 bug ，都是直接打回去，让测试复现

[Yesr00]

让测试去找复现步骤。得复现概率 90%以上的才能整。😂

[xdeng]

那就不是 bug

[Vindroid]

能取到客户设备 log 的情况下，在可能的地方加 log ，后续版本持续跟踪。取不到 log ，也没有能复现问题的操作，神仙也难解啊

[gam2046]

复现不了的 bug = 没有 bug

怨天怨地怨空气，也不能怨你（狗头保命

[NoDataNoBB]

@gam2046 但是有工单

[wpblank]

我们公司之前有联系客户，然后带电脑上门 debug 的

[leeson888]

复现不了还叫 bug 吗

[messaround]

检查代码，推敲逻辑

[xueling]

说一下我的看法，这种问题排查不要只从能否复现的角度处理，应该主要从两方面着手，1 是日志，2 是监控。
1 、app 程序层面的问题，分为普通异常日志和崩溃日志，一般来说异常类日志都有较完整的调用链信息，定位问题相对容易。但造成崩溃的原因比较多，可能是内存问题，用户设备问题、也可能只是某个参数校验失败或空指针异常处理不当导致的，不同情况下崩溃日志有可能完整也可能不完整。所以从日志层面上可以添加全局的异常信息捕获，并将全局异常日志上报，防止漏掉异常信息，而导致排查无从下手。
2 、app 的异常监控体系不完善，可以使用我的开源项目，快速搭建起异常监控体系，https://github.com/xl-xueling/xl-lighthouse ，基于通用型流式统计实现，接入方便、使用灵活、性能强大，轻松实现任意细粒度、任意维度的数据监控。将手机型号、手机系统版本号、app 版本号、页面、模块、错误码等关键信息上报。全面监控各类异常的次数和频率等信息（我自己感觉我的开源项目是应对这类问题业内最强大的工具了~~）。

总之，我觉得 app 问题处理，侧重点应在两方面：一是全局异常日志（代表你没有正常处理的异常），二是普遍性错误（比如：某个 app 版本或某个机型错误率或崩溃率在 0.5%以上的异常），公司内部可以对异常阈值确定一个标准，比如灰度时发现影响超过 0.5%的用户的异常必须测试人员复测解决，该版本不能继续发布，而影响范围较小的偶发性问题、不容易复现的问题，可以暂时忽略或陆续解决。要做到应对领导的所有盘问一切以数据说话，只要日志和监控体系建立起来，你对线上故障的驾驭能力会得到极大的提升。

[yb2313]

这是 feature

[musi]

复现不了的 bug 就不是 bug
什么？老板找你？你让老板把这个 bug 给你复现了再说

[jeesk]

要不要看看这个 bug ？
https://github.com/facebook/react-native/issues/37871 ？