统计请求延迟时排除WebFilter耗时反而更高，代码是否存在问题？

代码问题 #

• PostFilter优先级无法保证最低：@Order(Ordered.LOWEST_PRECEDENCE)仅代表你设置的优先级数值为最大值，若Spring内置过滤器、第三方依赖的过滤器也使用了相同的LOWEST_PRECEDENCE配置，相同优先级的过滤器排序规则是不确定的，无法保证你的PostFilter是最后一个进入前置逻辑的过滤器，导致计时范围和预期不一致。
• 计时逻辑存在调度误差：你使用doOnTerminate触发结束时间采样，该回调的实际执行时间依赖Reactor的线程调度：若回调触发时对应线程存在任务积压、JVM发生STW、操作系统上下文切换，你获取的结束时间会晚于实际业务处理完成时间，导致计算的耗时偏大。
• 异常场景统计范围不一致：如果在PreFilter调用chain.filter之前发生异常，不会触发doOnTerminate，该异常请求不会被PreFilter统计；如果请求进入PostFilter之后才发生异常、被取消，会被PostFilter统计，两类过滤器统计的请求样本集本身就存在差异。

假设问题 #

• 默认所有请求都会经过两个过滤器：若中间存在其他过滤器提前返回响应（比如权限校验不通过直接返回）且没有触发异常，PostFilter根本不会执行，这部分请求只会被PreFilter统计，不会出现在PostFilter的样本中，拉低了PreFilter的统计均值。
• 默认WebFilter执行顺序的计时逻辑符合预期：你默认PreFilter的计时范围包含PostFilter的计时范围，这个结论仅在PostFilter确实是最后一个过滤器、回调没有调度延迟的前提下成立，实际运行中上述前提并不总是成立。

优化建议 #

• 显式设置PostFilter的Order值为Ordered.LOWEST_PRECEDENCE - 1，优先抢占最低优先级的排序位，避免和其他过滤器同优先级导致顺序错乱。
• 改用Micrometer官方的观察器钩子来统计延迟，不要自行在过滤器中计时，避免回调调度带来的误差。
• 给两个指标增加相同的请求状态标签（成功/失败/取消），对齐统计的样本范围，方便对比。

内容的提问来源于stack exchange，提问作者kane