Spring Security与Shiro核心能力深度对比
选框架前得先搞清楚：它俩到底能干嘛？去年那个企业后台项目，朋友一开始觉得“安全框架不就是登录授权吗？随便选一个就行”，结果搭完Shiro发现不支持OAuth2.0，又换Spring Security，白白浪费一周时间。其实这俩框架的核心能力差异比你想的大，我把关键维度整理成了表格，你可以直接对着看：
| 对比维度 | Spring Security | Apache Shiro |
|---|---|---|
| 核心功能覆盖 | 认证、授权、加密、防CSRF、会话管理、OAuth2.0/OIDC | 认证、授权、加密、会话管理（OAuth2.0需额外集成插件） |
| Spring生态集成 | 原生支持Spring Boot/Cloud，自动配置无需额外代码 | 需手动配置整合，部分场景需自定义starter |
| 学习曲线 | 较陡，需理解Spring IoC/AOP，默认配置项超200个 | 平缓，核心组件仅4个（Subject/SecurityManager等），文档示例清晰 |
| 分布式适配 | 原生支持Spring Session，可无缝对接Redis/ZooKeeper | 需手动集成第三方组件，分布式会话需额外开发 |
光看表格可能还是抽象，说个具体例子：去年那个企业后台用的是Spring Boot+Vue，需要对接微信登录（OAuth2.0）。一开始试了Shiro，按官方文档配了三天，发现Shiro原生不支持OAuth2.0，得集成第三方库，最后代码写了200多行，还老出bug。后来换成Spring Security，加个spring-boot-starter-oauth2-client依赖，配几行yml就跑通了——这就是生态集成的差距。
为什么会这样？Spring Security从设计之初就深度绑定Spring生态，它的自动配置类会扫描Spring环境中的Bean，比如你用了Spring Data JPA，它能自动关联用户表；而Shiro更像个独立工具，需要手动把各个模块“拼”起来。就像搭积木，Spring Security是现成的乐高套装，Shiro是散装零件，前者快但不灵活，后者灵活但费时间。
不过也别觉得Shiro就不行。我另一个朋友做的是内部管理系统，用户就50人，功能简单，用Shiro两天就搭完了安全模块。他跟我说：“Spring Security的配置文档我看了三小时，还没找到哪里改登录页；Shiro的示例代码复制过来，改改用户名密码字段就跑起来了。”这就是轻量级项目的优势——Shiro的核心代码就200KB，学习成本低，适合小团队快速上手。
从配置到上线：三个最容易踩的坑及解决方案
选好框架只是第一步，实际开发中掉坑才是常态。去年我帮一个电商项目排查问题，他们用Spring Security做权限管理，上线后发现普通用户能访问管理员接口，查了半天才发现是权限注解用错了——这种“一看就懂，一做就错”的坑，我 了三个最常见的，每个都附了具体解决办法。
第一个坑：权限注解不生效，到底是@PreAuthorize还是@RequiresPermissions？
这是最容易搞混的地方。Spring Security用的是@PreAuthorize("hasRole('ADMIN')")，Shiro用的是@RequiresPermissions("order:edit")，但光加注解还不够。我之前见过有人在Spring Boot项目里用@PreAuthorize，结果发现所有用户都能访问，查了半天发现没加@EnableGlobalMethodSecurity(prePostEnabled = true)注解——这就像开车忘了插钥匙，再好的功能也用不了。
更坑的是权限表达式的写法。比如你想限制“只有订单创建者能编辑订单”，Spring Security要写成@PreAuthorize("authentication.principal.id == #order.userId")，这里的#order是方法参数，得确保参数名和表达式里一致；Shiro则需要自定义Permission类，实现isPermitted方法。去年那个电商项目就因为参数名不一致，导致权限校验一直失败，后来用IDE的“查看变量名”功能才发现，方法参数写的是OrderDTO orderDto，表达式里却用的#order。
第二个坑：分布式环境下会话共享失效
现在微服务项目多，用户登录后会话存在哪个服务？去年有个分布式项目用Shiro，一开始把会话存在内存里，结果用户登录A服务，访问B服务时又要重新登录。他们试着用Redis存会话，写了个RedisSessionDAO，结果发现Shiro的会话对象序列化后有8KB，每次请求都要传这么大的数据，接口响应慢了300ms。
其实Spring Security在这方面更有优势，它的Spring Session模块能无缝对接Redis，而且默认用JSON序列化，会话数据能压缩到1KB左右。配置也简单，加个spring-session-data-redis依赖，配一下Redis地址，会话就自动共享了。如果用Shiro， 直接用shiro-redis这个第三方库（https://github.com/alexxiyang/shiro-redis），它封装了Redis会话管理，比自己写靠谱多了。
第三个坑：加密算法选不对，密码等于白存
安全框架的加密功能很重要，但很多人随便选个MD5就完事了。我见过最夸张的项目，数据库里用户密码居然是明文——这要是被拖库，后果不堪设想。其实不管用哪个框架，都要选带“盐值”的加密算法，比如BCrypt或PBKDF2。
Spring Security默认用的就是BCrypt，它会自动生成随机盐值，每次加密结果都不一样，比如密码“123456”，第一次加密是$2a$10$xxx，第二次是$2a$10$yyy，但验证时都能通过。Shiro需要手动配置HashedCredentialsMatcher，记得把hashIterations设为1024以上——迭代次数越多，破解难度越大。我一般会在配置类里加个注释：“加密迭代次数至少1024，低于这个值等于没加密”，防止后来人随便改。
如果你不知道怎么选加密算法，可以参考OWASP的 （https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html），他们推荐优先用Argon2或BCrypt，这俩都是目前公认安全性较高的算法。
最后想说的是，框架没有绝对的好坏，只有适不适合。如果你做的是企业级应用，用Spring Boot/Cloud，选Spring Security准没错；如果是小项目、内部系统，Shiro足够用还省钱。最重要的是先想清楚项目需求：用户量多少？要不要对接第三方登录？是不是分布式架构？把这些列出来，再对照框架的能力，答案自然就有了。如果你已经踩了哪个坑，或者有选型疑问，欢迎在评论区留言，我会尽量帮你分析！
你知道吗，Spring Security和Shiro这俩框架，就像两套不同品牌的工具箱，看着都能拧螺丝、锯木头，但内核的“操作逻辑”差远了，硬要混着用，就跟用菜刀剪头发似的——不是不能用，但大概率出乱子。你想想啊，Spring Security的过滤器链是跟着Spring的DispatcherServlet走的，从请求进来开始，一层层经过UsernamePasswordAuthenticationFilter、ExceptionTranslationFilter这些“关卡”，每个环节都和Spring的IoC容器深度绑定；而Shiro呢，它有自己独立的ShiroFilter，会先拦截所有请求，再走自己的认证授权流程。这两套过滤器要是同时配置在一个项目里，就像两条路抢一辆车，轻则重复拦截（比如一个请求被两个框架的过滤器各查一遍权限），重则直接“撞车”——去年我见过最离谱的情况，有团队配了Shiro的登录过滤器，又开了Spring Security的formLogin，结果用户输完密码点登录，页面直接跳转到404，查日志才发现两个框架的登录接口路径冲突了，请求被互相覆盖。
更麻烦的是认证核心组件的冲突。Spring Security靠AuthenticationManager管认证，Shiro靠SecurityManager统筹全局，这俩“老大”在同一个项目里碰面，就像两个部门经理抢着指挥同一个团队。去年帮朋友的电商项目排查问题，他们为了“保险”，同时集成了两个框架，结果登录后发现普通用户能调管理员接口。我当时翻他们代码，发现Shiro的SecurityManager把用户角色存到了session里，而Spring Security的Authentication对象里却没角色信息——因为两个框架的认证流程互相干扰，Shiro认证通过后，Spring Security根本没拿到用户权限数据，等于白做了权限校验。最后没办法，只能把Shiro的配置全删了，光留Spring Security，问题才解决。所以说啊，框架这东西不是“越多越安全”，选一个适合项目的，把它吃透用透，比混搭两个半吊子强得多。
小项目该选Spring Security还是Shiro？
小项目（如内部管理系统、用户量50人以内） 优先选Shiro，它轻量灵活，学习曲线平缓，2-3天即可上手配置基础认证授权；若项目依赖Spring Boot/Cloud生态，或需要OAuth2.0、分布式会话等功能，即使是小项目也 用Spring Security，避免后期功能扩展时重构成本。
Spring Security和Shiro可以混合使用吗？
不 混合使用。两者核心机制（如认证流程、会话管理）差异较大，混合会导致配置冲突（如过滤器链重复拦截）、权限逻辑混乱（如双重认证校验）。去年有团队尝试在Spring Boot项目中同时集成两者，结果出现“登录后权限不生效”的问题，排查发现Shiro的SecurityManager与Spring Security的AuthenticationManager冲突，最终只能移除其中一个框架。
学习Spring Security有哪些推荐资源？
官方文档是首选（Spring Security官方文档），其“Getting Started”章节提供了从基础到进阶的示例；实战层面可参考《Spring Security实战》一书，书中结合电商、后台系统等场景拆解配置逻辑；若想快速上手，B站“黑马程序员Spring Security实战”视频（非广告，亲测案例代码可直接复用）适合零基础入门。
分布式项目必须用Spring Security吗？
不一定，但Spring Security更适配。分布式场景（如微服务、多节点部署）需解决会话共享、跨服务权限同步问题，Spring Security可通过Spring Session无缝对接Redis，配置仅需3行yml（指定Redis地址、会话存储类型）；Shiro需额外集成shiro-redis插件，手动实现分布式会话DAO，开发成本比Spring Security高30%-50%，适合对定制化要求极高的场景（如自研会话存储方案）。
密码加密选BCrypt还是PBKDF2？
优先选BCrypt，其次是Argon2（OWASP 2023年推荐）。BCrypt优势在于自动生成随机盐值，每次加密结果不同但验证兼容，且迭代次数可调整（默认10次， 设为12-16次），平衡安全性与性能；PBKDF2需手动管理盐值存储，实现复杂度略高。实际开发中，Spring Security默认提供BCrypt加密器，直接注入PasswordEncoder即可使用，无需额外配置。
