有一次面试，面试官直接抛给我一个问题：“如果现在让你负责一个 Spring Boot 项目的权限体系，你会选择 Spring Security 还是 Shiro？”
当时我没有立即回答。因为这个问题表面上是在问两个框架有什么区别，实际上他想考察的是：你到底懂不懂一个权限系统应该怎么设计。
如果只背一句“Spring Security 功能强大，Shiro 简单易用”，基本就是面试现场的“标准答案播放器”。真正有经验的开发者应该意识到：安全框架很像公司的门卫系统。
- Shiro 更像一位经验丰富、装备精简的门卫：规则直观，配置简单，上手极快。
- Spring Security 则像大型园区的完整安防体系：门禁、身份认证、权限控制、攻击防护、OAuth2、JWT、方法级权限控制……各种设备一应俱全，但设备多了，学习成本自然上升。
那么，Spring Security 和 Shiro 到底该怎么选？
先搞明白：安全框架到底解决什么问题？
不要急着比较两个框架。假设我们开发一个电商后台，系统里有三类人：
用户登录之后，系统至少要解决三个问题：
- 第一，你是谁？这就是认证 Authentication。
- 第二，你能干什么？这就是授权 Authorization。
- 第三，如果有人故意攻击系统怎么办？这就涉及会话管理、CSRF 防护、密码处理、攻击防护等安全能力。
所以安全框架并不是简单的“登录工具”，它更像机场安检系统：登录相当于确认“你是不是本人”；权限相当于确认“你能不能进入这个区域”；安全防护则负责处理伪造身份、非法请求、恶意攻击等问题。
理解了这一层，再看 Spring Security 和 Shiro，思路就清晰很多。
Shiro：小巧、直观、容易上手
Apache Shiro 的设计思路比较直观，它把安全体系抽象成几个核心概念：Subject、SecurityManager、Realm。
其中 Subject 可以理解成“当前正在操作系统的人”：
Subject subject = SecurityUtils.getSubject();
然后可以进行登录：
subject.login(token);
也可以判断权限：
subject.checkPermission("user:delete");
这种设计非常符合人的直觉。
你可以把 Shiro 想象成一个小区门卫：
- 住户来了，门卫问“你是谁？”，这就是验证身份。
- 继续问“你有没有权限进入地下车库？”，这是检查权限。
- 再问“有没有权限进入物业办公室？”，继续检查权限。
整个过程清晰明了。
Shiro 最大的优势之一，就是 API 简单、概念容易理解。对于传统 Web 项目、中小型后台系统、内部管理系统来说，这种简单往往非常有价值。
Spring Security：功能丰富，但学习曲线更陡
如果说 Shiro 是小区门卫，Spring Security 更像大型机场的完整安防体系。它不只是处理登录和权限，还把大量安全能力整合到了 Spring 生态里，比如：
- 表单登录
- HTTP Basic
- Session 管理
- CSRF 防护
- CORS 配置
- 方法级权限控制
- OAuth2
- OpenID Connect
- JWT 场景
- 密码编码
- Remember-Me
- 多种认证机制
而且它和 Spring Boot、Spring MVC、Spring Session 等组件结合得非常紧密，例如方法级权限控制：
这时候权限已经不只是停留在 URL 层面，而是可以深入业务方法。
这对于大型系统非常重要。大型系统的权限通常不是简单的“访问 /admin/** 就行”，而是“你可以查看订单，但不能修改订单；可以修改自己部门的数据，但不能修改其他部门的数据”。
这时候 Spring Security 的扩展能力就开始体现价值了。
两者最核心的区别在哪里？
把两者放在一起看：
这里有个很容易出现的误区：“功能多”并不一定意味着“更适合”。
如果只是开发一个几十个接口的内部管理系统，却引入大量复杂安全配置，反而是在增加维护成本。就像每天骑自行车上班的人，给自行车装了一套飞机驾驶舱——设备确实先进，但没必要。
Spring Security 的优点和缺点
先看优点。
1. Spring 生态集成非常好
如果项目本身就是 Spring Boot，那么 Spring Security 几乎可以自然融入整个项目。
Security Filter Chain、Authentication、Authorization、Method Security 等机制，都可以和 Spring 的 IoC、AOP 等能力结合。这意味着大型 Spring 项目可以建立比较完整的安全体系。
2. 安全能力比较全面
它不只是解决“用户名密码登录”这一个问题。对于现代系统常见的 OAuth2、JWT、资源服务器、客户端认证等场景，都有成熟的生态支持。
尤其是现在微服务越来越普遍，一个系统可能涉及：前端 → 网关 → 用户中心 → 订单服务 → 商品服务。
这时候单纯依靠传统 Session 已经不够用了，Spring Security 在复杂认证授权体系中的扩展空间比较大。
3. 扩展能力强
认证过程、授权过程、Filter、Provider、Handler 等都可以扩展。例如可以接入：
- LDAP
- OAuth2
- JWT
- 自定义登录方式
- 第三方身份认证
这也是大型项目比较看重的一点。
但缺点也非常明显——学习成本高。刚接触 Spring Security 的时候，很多人会被一堆概念绕进去：
- Authentication 是什么？
- AuthenticationManager 是什么？
- SecurityContext 又是什么？
- FilterChain 为什么这么长？
- ProviderManager 又是什么？
这就像第一次进入机场安检中心，你会发现这里不是一个门卫，而是一整套系统。
Shiro 的优点和缺点
Shiro 最大的优势其实就是两个字：简单。
它的认证、授权、会话管理等概念非常清晰。很多业务系统只需要“登录”“判断角色”“判断权限”这三件事，Shiro 就能比较快速地完成。而且它不像 Spring Security 那样深度绑定 Spring 框架，在一些非 Spring 项目中也比较灵活。
但问题也来了：当业务越来越复杂时，Shiro 往往需要更多的自定义工作。比如现代系统需要：
- OAuth2？
- JWT？
- 复杂的单点登录？
- 多服务统一认证？
- 第三方身份平台？
这时候就需要结合其他组件和方案了。
因此可以简单理解成：
- Shiro 更强调简单易用；
- Spring Security 更强调完整能力和生态集成。
真正的面试重点：不要只会背“优缺点”
如果面试官继续追问“那你的项目应该怎么选？”，这时千万不要直接说“我选 Spring Security”或者“我选 Shiro”。
这种回答还是太浅。更好的思考方式是先分析业务：
- 如果是一个简单的后台管理系统：用户数量不大，认证方式简单，权限模型也不复杂，那么 Shiro 的简单性可能很有价值。
- 如果是大型 Spring Boot 项目：需要 OAuth2、JWT、微服务认证、复杂授权、方法级安全控制，那么 Spring Security 的生态和扩展能力通常更容易满足需求。
所以真正应该比较的，不是谁更强，而是谁更适合当前系统。这也是社招面试和校招面试很大的区别：
- 初级程序员喜欢回答：“这个框架有什么功能？”
- 有项目经验的程序员更应该回答：“我的业务需要什么能力？这个框架能不能低成本满足？”
还有一个容易被忽略的问题：权限模型
安全框架只是工具，真正复杂的地方往往是权限模型。最常见的 RBAC 模型就是：用户 → 角色 → 权限。
但企业系统可能还需要：用户 → 部门 → 数据权限。例如张三属于华东区，他可以查看华东区订单，但不能查看华南区订单。
- 这时候仅仅判断
order:read 已经不够了。
- 系统还需要判断：用户有没有订单查询权限？用户有没有查看这条订单数据的权限？
这就是所谓的功能权限 + 数据权限。无论你使用 Spring Security 还是 Shiro，这些业务权限模型最终都需要自己设计。
所以千万不要产生一种错觉：用了安全框架，就拥有了完整的权限系统。
- 安全框架负责的是安全基础设施。
- 业务权限依然需要自己设计。
如果让我在面试现场回答，我会这样说
如果面试官问：“比较一下 Spring Security 和 Shiro 各自的优缺点。”
我会先从设计定位说起：
Shiro 的优势是简单、易理解、API 直观，对认证、授权、Session 等基础安全场景支持比较方便，适合一些中小型或者安全模型相对简单的项目。
Spring Security 的优势则是和 Spring 生态结合紧密，安全能力更加全面，在 OAuth2、JWT、方法级安全以及复杂认证授权场景下具有较强的扩展能力。
但是 Spring Security 的代价是学习成本和配置复杂度相对更高；Shiro 虽然简单，但在现代复杂认证体系下，可能需要更多第三方组件或者自定义能力。
最终选择不能简单看谁“更强”，而应该结合项目规模、Spring 生态、认证方式、权限模型以及未来扩展需求综合判断。
说完这些，面试官一般还会继续追问：“那 Spring Security 的认证流程你了解吗？”
这时候，真正的战斗才刚刚开始。因为下一道题，很可能就是：一次用户登录请求，到底是怎么穿过 Spring Security 那一层层 Filter，最后完成认证的？
这才是 Spring Security 真正值得深入研究的地方。
关于 Spring Security 的 Filter 认证链路，后续可以再单独展开。如果你也在 Java 安全框架的实际选型和落地上有困惑，不妨到云栈社区看看其他开发者的实战讨论，会有不少一手经验值得参考。
发表于 18 小时前
|
查看: 3|
回复: 0
