咋回事啊？
到底是咋回事呢？
且听我给你分析一波。
上一小节我说了，问题出在排序算法上。
org.apache.dubbo.common.extension.support.ActivateComparator
来，一起看一下：
首先标号为 ① 的地方就是把 before、after、order 封装了一下，然后提供了几个比较的方法。你知道 ActivateInfo 这个实体里面有这些东西就行了，后面的代码会用到。
然后说说标号为 ② 的地方。
这个地方你别看挺长的，但是其实逻辑特别简单，当前对比的两个 filter 中的任何一个配置了 before、after 就会进入到标号为 ② 的部分的逻辑。
然后这里面的一坨逻辑是的这样的：
具体逻辑不细说了，等会给你来个直观的演示。
最后标号为 ③ 这个地方，有点意思，稍微多说几句。
能走到标号为 ③ 的地方，说明当前对比的两个 filter 都没有配置 after、before 这两个属性。
直接对比 Order 就行了。
这个地方对 Order 相等的情况还做了一个特殊处理：
o1.getSimpleName().compareTo(o2.getSimpleName()) > 0 ? 1 : -1
如果 Order 相等，再比较类名。
这样做的原因也是保证排序的稳定性。
举个例子，比如这两 Filter，都没有指定 Order：
代码就变成了这样：
if (a1.order > a2.order) { return 1 } else { return -1 }
简化一下就是这样：
return a1.order > a2.order ? 1:-1
那么这一块的代码，整体就会变成这样：
好的，经过这样的一番改造。
恭喜你，获得了一个老版本的代码：
左边是之前版本的代码，右边是现在 Master 分支的代码：
为什么会发生变化，必然是有原因的。
看一眼提交记录：
这次提交指向了编号为 7778 的提交:
而这次提交指向了编号为 7757 的 issue：
https://github.com/apache/dubbo/issues/7757
而这个 issue 在前面提到的编号为 8055 的 issue 里也提到了：
这个 issue 主要就是两张图。
第一张图是这样的：
在没有任何自定义 Filter，仅有官方原有的 Filter 的情况下，构建出来的 Filter 链，ExecuteLimitFilter 在 MonitorFilter 之前。
第二张图是这样的：
在加入了一系列自定义的 Filter（没有指定 Order）之后，ExecuteLimitFilter 就排在了 MonitorFilter 之后了。
至于这两个 Filter 排前排后的影响是什么，和文本关系不大，就不扩展了，你有兴趣的可以去看看对应的链接。
总之，只有这样的判断逻辑是不稳当的：
return a1.order > a2.order ? 1:-1
