关键词：处理线上用户反馈
作者之所以要将这个问题定义为 【master】级别， 是因为这个问题， 说简单又简单， 说难又是有不小难度的。
作者认为：在一个团队里面， 能够快速解决用户的线上反馈问题， 这个是 中级、高级开发的能力要求。
但是，在一个团队里面， 提供一个完整的线上问题反馈的解决方案， 是一个资深研发工程师的能力要求模型。还有这个是一个开放型的问题，各位小伙伴可以根据各自的情况， 自由发挥吧
修复 bug 研发往往需要先复现，而复现需要依赖一些关键信息，比如用户操作路径，日志信息等等；但站在组织架构角度，研发同学一般不会直接跟客户打交道，所以在客户提出问题的同时尝试搜集必要的 bug 信息对于整个 bug 修复流程很有重要。
当然在很多公司， 用户问题是会先反馈给销售团队或者技术支持团队。 我们这里讨论的情况是， 问题就已经反馈到了研发同学的情况。
客户沟通原则
原则很简单， 就是尝试自己复现， 如果自己无法复现， 再去尝试跟客户沟通。
前期通用排查手段
1. 是否受缓存影响？
浏览器缓存：包裹 cookies、本地缓存、indexDB 等等，这些缓存一般存储用户数据，账号信息，关键逻辑缓存等等。验证是否受浏览器缓存影响最直接的是让用户新开一个无痕浏览器测试功能是否正常即可，如果无痕正常但非无痕有问题，那就可以确定是这个问题了。
2. 是否受浏览器插件影响？
也是直接使用无痕浏览器验证功能是否正常
3. 浏览器版本问题
尝试升级浏览器即可， 或者换一个浏览器
4. 网络网关问题
遇到这个问题， 应该该用户整个网内都有该问题。
可以通过心跳检测， 资源加载检测等手段， 确认是否是网络问题。
信息收集
这部分主要收集用户的一些操作信息， 例如用户操作路径、报错信息、运行日志等。
这里就直接整理一下需要收集的一些信息。
- 用户复现问题路径
- 用户信息
- 客户出现问题使用的操作系统和版本
- 客户使用的浏览器类型与具体版本
- 报错信息
- 客户遇到问题时的截图或录屏
- 此问题是否是近期突然出现还是一直存在
- 对于公司群体用户是否只有特定用户遇到了这个问题
- 性能问题的 performance 文件
这里只是列举了一些常用的信息，建议信息收集的时候， 直接介入一个完整的日志报警平台。 通过上报日志与监控报警的方式来收集这部分信息。
这里如果公司没有自检报警监控的框架， 我这里直接就推荐开源日志框架的 Sentry
Sentry：一个功能强大的错误监控和日志收集工具。支持多种前端框架和语言，能够实时捕获和报告前端应用中的错误和异常，并提供详细的错误上下文信息。