web服务器和shiro哪个先调？web服务器与shiro执行顺序详解

Web服务器永远先于Shiro接管请求。 浏览器发出的HTTP请求先到Tomcat或Jetty容器，容器完成Socket读取和HTTP解析后，才会把请求交给ShiroFilter，Shiro只是挂在过滤器链上的一道关卡，没有容器启动,它根本收不到请求。

web服务器和shiro哪个先调用？从一次登录请求说起

很多人把“先于Controller执行”和“先于Web服务器执行”搞混，Shiro过滤器确实挡在Controller前面，但它在Servlet容器内部运行，容器不先启动，Shiro Filter不会初始化，容器启动时会读取web.xml或Spring Boot的FilterRegistrationBean，把ShiroFilter注册到过滤链，请求到达时，容器先分配线程、解析HTTP报文,然后按顺序执行过滤链。

spring boot集成shiro登录流程中谁先跑

在Spring Boot项目里，内嵌Tomcat先监听8080端口，一个POST /login请求进来后，Tomcat的Connector线程接收字节流，经过CoyoteAdapter解析成HttpServletRequest，接着进入应用的FilterChain，Shiro的ShiroFilterFactoryBean生成的过滤器在这里被调用，最后才到DispatcherServlet,再进到你的登录Controller。

可以理解为三层顺序：

• 第一层：Tomcat网络层接收请求
• 第二层：ShiroFilter过滤链执行认证授权逻辑
• 第三层：Spring MVC的Controller处理业务

shiro过滤器在tomcat中的执行顺序实测

想自己验证，不需要复杂工具，在ShiroFilter里打一条日志，再在Controller里打一条日志，启动应用后调用登录接口，控制台会先打印ShiroFilter的进入日志，后打印Controller进入日志，但这两条都在Tomcat的访问日志之后，Tomcat的access log通常记录请求完成时间，可以在logs目录下看到localhost_access_log文件，里面有请求进入的原始记录,对比时间戳就能确认容器先收到请求。

为什么Shiro只能当第二道门

Shiro不是独立服务，它没有监听端口的能力，它的核心是一组过滤器，通过ShiroFilterFactoryBean或web.xml里的DelegatingFilterProxy挂到Servlet容器，容器负责网络IO、请求解析、会话管理的基础部分，Shiro负责认证、授权、密码校验,这个分工决定了调用顺序不会颠倒。

从部署形态看先后关系

• 如果前面还有Nginx，则Nginx先接收TCP连接，转发给Tomcat,Tomcat再交给Shiro。
• 如果直接暴露Tomcat,则Tomcat的Connector先读字节流。
• 无论哪种部署,Shiro都只能在Servlet容器内部活动。

Servlet Filter机制决定了先后

Servlet规范里，FilterChain由容器创建和管理，Tomcat在调用应用初始化方法时，把过滤链按顺序组装好，ShiroFilter只是其中一个节点，容器没启动，过滤链不存在，容器启动后，过滤链才有执行机会,所以Shiro永远不可能先于Web服务器。

java web安全框架对比：shiro和spring security调用时机差异

两个框架在调用顺序上没有本质区别，Spring Security的DelegatingFilterProxy和Shiro的ShiroFilter都运行在容器过滤链中，它们都晚于Web服务器，真正的区别在过滤链内部：Spring Security默认有多个过滤器组成SecurityFilterChain，Shiro则通常用一个大的ShiroFilter或几个自定义过滤器，国内较老项目里Shiro出现频率较高，因为配置简单、学习成本低，新项目用Spring Security的比例在上升。

| 对比项 | Apache Shiro | Spring Security |
| 调用入口 | ShiroFilter | DelegatingFilterProxy |
| 是否先于Web服务器 | 否 | 否 |
| 授权费用 | 免费开源 | 免费开源 |
| 国内项目使用情况 | 老项目较多 | 新项目较多 |

行业共识认为，Shiro适合权限模型简单的中小型项目，Spring Security适合与Spring生态深度集成的复杂系统，二者都不需要付费授权,主要成本在学习和维护。

为什么总有人误以为Shiro先拦截

因为ShiroFilter通常配置为过滤链的第一个过滤器，拦截所有路径，开发者在Controller里打印日志时，总看到Shiro先执行，于是产生“Shiro先调”的错觉，实际上它只是先于业务代码,不是先于Web服务器。

自己动手验证调用顺序的实操步骤

创建自定义过滤器观察调用顺序

新建一个类实现javax.servlet.Filter，在doFilter方法里打印“CustomFilter进入”，然后调用chain.doFilter,这样你能在控制台看到过滤链的执行顺序。

设置过滤器顺序

用FilterRegistrationBean注册自定义过滤器，setOrder设置为0，ShiroFilter的order可以设置为1，这样自定义过滤器会先于Shiro执行，但无论order怎么调,它们都在Tomcat之后。

观察最终日志输出

启动应用，访问任意接口,控制台顺序大致如下：

• Tomcat访问日志记录请求
• CustomFilter进入
• ShiroFilter进入

• 

  Controller进入

这能直观看到Tomcat最先，如果你把Tomcat访问日志关闭，只留应用日志，也能通过ShiroFilter里的request.getRemoteAddr()获取到客户端地址,说明Tomcat已经解析过HTTP报文。

回到最初的问题：web服务器和shiro哪个先调用，答案固定且没有例外，Web服务器先调，Shiro后调，只要应用跑在Servlet容器里，这个顺序就不会变,理解这一点能帮助开发者正确排查过滤链顺序和登录流程问题。

Q&A：web服务器和shiro哪个先调用相关疑问

web服务器和shiro哪个先调用，会影响登录接口性能吗？

会影响一点，每次请求都要多过一层Shiro过滤器链，做路径匹配和权限判断，但这个开销多数情况下很小，相比数据库查询和密码哈希计算，过滤器的耗时基本可以忽略，真正影响性能的是Shiro配置不当,比如每次请求都查数据库加载权限。

shiro过滤器在tomcat中的执行顺序可以调整吗？

可以，通过FilterRegistrationBean的setOrder方法能调整ShiroFilter与自定义Filter的相对顺序，你甚至可以把自定义过滤器放在Shiro之前，但无论order怎么设置，ShiroFilter始终在Tomcat的请求解析之后,它不可能跑到容器前面去。

国内Java项目用Shiro还是Spring Security多？

老项目用Shiro的较多，新项目用Spring Security的比例在增加，Apache Shiro免费开源，学习曲线平缓，国内很多中小型项目还在用它，Spring Security功能更强，但配置复杂，选哪个主要看团队熟悉度和权限需求,与地域没有强关联。