问题排查思路
这里说的是主要是debug以及线上问题排查的思路.
解决问题的步骤
确认环境、确定问题、复现问题、查看日志、定位问题 、解决问题
确认环境/url/参数
- 确认是哪个环境。
是开发环境，测试环境，还是生产环境。
如果问题是在测试环境，去开发环境看问题，不一定能复现。
如果采用了微服务架构，还要查看注册中心，服务是否生效，启用了哪一个实例。
- 哪个接口？哪些参数？哪个时间段？
确认url是否正确，参数有没有传错了。
确定问题
有时候测试/用户提出的问题，不一定是bug。
一定要跟需求做校对，确认是否与需求一致，是否因需求不合理导致的。
复现问题
问清楚测试/用户，问题是如何出现的，具体的操作步骤是什么，查看是否因为操作步骤不正确导致的。
在相同的环境，自己重新操作一遍，复现问题。
如果无法复现，问清楚出错的操作时间，直接查看日志。
如果无法确定逻辑，可以问产品，问测试。
如果无法确定是哪个接口，哪个字段，可以问前端。
查看日志
生产环境中，是没法进行debug的，所以日志非常重要。
开发中，一定要把重要的变量打印出来。
打印日志， 非常有利于解决问题。
- 链路追踪
如果项目使用了微服务架构，最好有相应的链路追踪中间件，比如 SkyWalking。
traceId，用于标识一次请求的ID。在同一个请求调用过的服务模块中，traceId都是相同的。
可以通过traceId不断地追踪。
从上往下追踪，A服务调用B服务，先去A服务看下日志，找出 traceId，然后去B服务根据 traceId 继续追踪。
如果没有 SkyWalking, 也可以看下打印的日志有没有带上线程 id，可以根据线程id去跟踪。
在日志比较多的情况下，根据线程id找出请求相关的日志，方便定位问题。
-
异常错误
如果是异常错误，直接查看error日志中在堆栈信息，找到出错在代码就可以了。
-
逻辑错误
查看info/debug日志中的信息。
如果关键的信息没有打印日志，那么补充日志后，重新发布到开发/测试环境中。
在解决问题时，补充日志，重新发布环境，是非常有效的方法。 虽然土，但是有用。绝大部分逻辑问题，都可以通过打印日志解决。
-
复制数据到本地环境调试
如果是在生产环境，可以把日志打印出来，如果是对象，可以打印成json字符串，本地环境再转换成对象。
通过复制数据到本地环境，进行调试。
查询数据源
将查询或更新的sql或es等语句找出来，在对应的数据源中查询进行定位。
可以用下 MyBatis Log Free 插件： (免费)显示Mybatis的Sql。一下子把sql打印出来。
可以说是开发必须的插件了，遇到问题，马上打印sql，能快速定位问题。
定位问题
数据的流程一般是： 数据源产生数据--->加工数据--->目标变量获取数据
如果数据有问题，那么就要从这三方面分析，是在哪一步出错了。
是数据源的数据本来就不对，或者数据在加工过程中出错了，还是目标变量取错了数据，数据出错 ？
IDEA查看变量的调用链，可以参考以下文章：
https://www.cnblogs.com/expiator/p/10856482.html
解决问题
修改代码后，重新发布环境，查看问题是否已经解决。
结语
实际中遇到的问题，可能会更加复杂，还是需要多思考，多分析，多解决实际问题。
无他，唯手熟尔。