小明：请求地址 ：/getUsersByOrgAndRole （根据角色code和组织id查用户）
请求参数:{"delFlag":0,"orgIds":["1867927118148894721"],"roleCodes":["123"],"type":0}
请求结果:{"status":"complete","count":0,"resultData":[],"success":true}
图1：组织下有用户cqy
图2：角色下有用户cqy
我：什么问题？？？
小明： 我的这个用户为什么查不出来，应该是有数据的
小明： 你这个是不是还有redis缓存呀
我：这个没用缓存吧 我看看，哪个环境啊
20分钟过去了
我： 我在这个接口上测了，开发和测试环境都可以，没问题啊。（选了一个用户进行测试）
小明： 用我的参数接口请求可以吗
我： 你的不行 查不到
小明： 是不是token问题，不是admin租户的（项目是租户隔离的）
我： 不确定 再看看 应该和租户没关系吧 这个没有判断租户
启动本地服务，调用接口中，找到对应方法，眉头一皱，没有一点注释，开始硬看，找到一个奇怪的调用方法
//部分代码
orgIds.forEach(item -> {
queryWrapper.or(i -> i.apply("parent_ids like {0}", "%" + item + "%"));
});
是不是这个方法的问题，开始思考。
10分钟又过去了，哦，原来是根据组织 ID 查他们的下级组织的。
soga原来是只能查询下级组织的用户啊，不能查这个组织下的用户。（其实会查本组织，但是被之前测试的结果迷惑了）
我： 不能用这个组织查，要用他的上级
小明： 为什么呀，组织是有这个用户的，但是查不到，从理论上应该是允许查的，基于什么原因做这样的设计吗
我： （汗流浃背，有道理，开始怀疑自己） 好像也不是，我再看看代码很奇怪。
跳过这个方法继续排查，找到了对应的mapper层方法调用
大致就是根据角色的id和组织的id，查询启用和未删除的用户。
开始查库，查这个用户的组织和角色，确认是否存在因前端页面配置导致实际上数据库中缺乏相关角色、用户或其关联关系的情况。
30分钟过去了，把mapper层写的sql语句，抽离放到数据库中验证，sql的调用没问题，可以查到这个用户，但是调用的接口查不到，这是为什么啊。
反复去看环境，并找了个新的用户试了下没问题，急急急，赶紧找高级开发看一下，跟他一说，描述+展示情况又耗费了20分钟，他说先发给我吧，有可能是环境不对（数据库不一致），或者他们传的参数本身有问题，先上具体的环境看一下，什么情况。
上午完
下午，小休之后，继续看代码，越看越怀疑自己。不对劲，不可能啊，啊啊啊，假的都是假的，发癫中。
10分钟后冷静下来，细想了一下是不是sql执行的代码没全，一细看mapper层，有个activateFlag没判断，一加上果然查不到了。
哦哦哦。
原来是之前默认会查激活的。
xx.setActivateFlag(Arrays.asList(ActivateFlagEnum.ENABLE.getCode()));
上环境一看果然，用户没启用。
我： （tnnd给我玩阴的是吧）小明， 误我啊 给的禁用的用户 让我查
小明：
测试提的问题
我也没注意到这个
6呀！这都查出来了
我： 我和大佬 一起查，疯狂看代码，搞了半天
小明： 明天请你们喝王老吉降降火
我： （当然是选择原谅他）小问题 下次记得先发环境页面 我上去瞅瞅
总结教训：下次一定先去看环境到底是不是这样的，对别人提供的信息保持一定的怀疑态度，sql语句要看全。
