企业官网建设流程全解析

1. 为什么在SpringBoot里还要选Shiro而不是Spring Security？

我第一次在某跨平台系统中接手权限模块时，团队正为“该用Shiro还是Spring Security”吵得不可开交。当时项目已用SpringBoot 2.7搭建了基础骨架，前端模板统一用Thymeleaf渲染，后端接口要同时支撑管理后台和轻量级运维看板。有人坚持“Spring全家桶就该用Security”，也有人翻出老项目文档说：“Shiro配置更直白，RBAC模型写三行代码就能跑通”。

后来我们实测对比了两套方案在真实业务场景下的表现——不是比文档厚度，而是看谁能让权限逻辑真正贴着业务走。结果发现：Shiro的Subject抽象天然契合Thymeleaf的模板级权限控制；它的FilterChainManager对URL路径的细粒度拦截，比Security的HttpSecurity DSL在复杂路由嵌套（比如/admin/**/export这种带通配符的导出路径）下更容易调试；更重要的是，当需要把权限判断下沉到Service层做数据级过滤（例如“用户只能看到自己创建的工单”），Shiro的@RequiresPermissions("ticket:read:own")注解配合自定义Realm，比Security的@PreAuthorize("hasPermission(#id, 'Ticket', 'READ_OWN')")更少依赖SpEL表达式上下文，出错时堆栈信息也更干净。

这不是技术站队，而是工程选择。Spring Security强在协议层（OAuth2、JWT、SAML），Shiro强在应用层（会话管理、多Realm集成、缓存穿透防护）。如果你的项目核心诉求是：

• 管理后台需支持按钮级（<button sec:authorize="hasRole('ADMIN')">）和字段级（<span th:if="${#authorization.hasPermission('user:update:email')}">）权限控制；
• 需要将登录态与WebSocket会话绑定（比如实时推送审批消息给指定角色）；
• 权限数据来自非标准源（如读取Excel配置表、调用内部HTTP权限服务、甚至混合数据库+Redis缓存）；

那么Shiro不是“过时的选择”，而是把权限逻辑从框架约束中解放出来的杠杆。它不阻止你用JWT，也不排斥OAuth2——你完全可以写一个JWTToken类继承AuthenticationToken，再让Shiro的Filter链在Spring Security的Filter之前截获请求。这种“混搭能力”，恰恰是很多教程里被忽略的实战价值。

提示：本篇所有配置均基于SpringBoot 2.7.18 + Shiro 1.11.0 + Thymeleaf 3.1.1，不兼容SpringBoot 3.x的Jakarta EE迁移版本。若你用的是SpringBoot 3，请先确认Shiro官方是否发布适配版——目前（2024年中）仍处于社区适配阶段，生产环境建议暂缓升级。

2. Shiro核心组件如何与Thymeleaf模板形成“权限反射链”

很多人卡在第一步：明明Shiro配置好了，Subject currentUser = SecurityUtils.getSubject()能拿到用户，但Thymeleaf里sec:authorize="hasRole('ADMIN')"却始终不生效。这问题90%出在权限上下文没有注入到Thymeleaf的ExpressionEvaluator中，而非Shiro本身没配对。

我们来拆解这个“反射链”的四个关键节点：

2.1 Subject与Thymeleaf的桥梁：ShiroDialect

Shiro官方提供的shiro-thymeleaf扩展包，本质是重写了Thymeleaf的StandardExpressionEvaluator。它在模板解析阶段做了两件事：

1. 将当前线程绑定的Subject实例，通过Context对象透传给Thymeleaf的IExpressionContext；
2. 注册shiro前缀的方言处理器（Dialect），把sec:authorize这类属性转换成Shiro的权限校验逻辑。

但注意：这个Dialect必须手动注册为Spring Bean，否则Thymeleaf根本不知道sec:是什么。很多教程直接贴配置却不说清这点，导致新手反复检查pom.xml依赖却找不到原因。

@Configuration public class ShiroConfig { @Bean public ShiroDialect shiroDialect() { return new ShiroDialect(); } }

这段代码看似简单，实则暗藏玄机——它必须在Thymeleaf的TemplateEngine初始化之后被Spring容器加载。如果ShiroConfig类被@ComponentScan扫到过早，而Thymeleaf的SpringTemplateEngineBean还未创建，就会导致Dialect注册失败。解决方案是显式声明依赖：

@Bean @DependsOn("templateEngine") // 强制等待Thymeleaf引擎初始化完成 public ShiroDialect shiroDialect() { return new ShiroDialect(); }

2.2 权限校验的执行时机：Filter链与模板渲染的时序关系

Shiro的权限控制分两个层面：

• URL级：由ShiroFilterFactoryBean配置的Filter链（如authc,perms,roles）在DispatcherServlet之前拦截HTTP请求；
• 模板级：由ShiroDialect在Thymeleaf渲染HTML时，调用Subject.isPermitted()或Subject.hasRole()实时判断。

这两者看似独立，实则共享同一个Subject实例。关键在于：Subject的生命周期绑定在当前HTTP请求线程上，Shiro通过ThreadLocal存储。这意味着——
✅ 当用户访问/admin/user/list时，ShiroFilter先校验URL权限，通过后才进入Controller；
✅ Controller返回ModelAndView，Thymeleaf开始渲染模板；
✅ 此时sec:authorize调用的Subject，正是Filter链中认证过的那个实例；
❌ 但如果Controller里手动调用了SecurityUtils.getSubject().logout()，后续模板中的权限判断就会失效（因为Subject已被销毁）。

这个时序陷阱，在开发“登出后跳转首页但首页仍有用户信息”的场景时特别明显。常见错误写法：

@GetMapping("/logout") public String logout() { SecurityUtils.getSubject().logout(); // 错！登出后Subject为空 return "redirect:/login"; // 模板里sec:authorize全失效 }

正确做法是让ShiroFilter接管登出流程：

@Bean public ShiroFilterFactoryBean shiroFilterFactoryBean(SecurityManager securityManager) { ShiroFilterFactoryBean bean = new ShiroFilterFactoryBean(); bean.setSecurityManager(securityManager); // 配置登出Filter，自动清理Session和Subject Map<String, Filter> filters = new LinkedHashMap<>(); filters.put("logout", new LogoutFilter()); bean.setFilters(filters); Map<String, String> filterChainDefinitionMap = new LinkedHashMap<>(); filterChainDefinitionMap.put("/logout", "logout"); // 触发登出Filter filterChainDefinitionMap.put("/**", "authc"); bean.setFilterChainDefinitionMap(filterChainDefinitionMap); return bean; }

这样/logout请求会被LogoutFilter处理，它会安全地销毁Session、清除ThreadLocal中的Subject，并重定向到登录页——此时模板渲染时sec:authorize依然可用，因为重定向是新请求，ShiroFilter会重新建立Subject。

2.3 Thymeleaf权限标签的底层映射逻辑

sec:authorize不是魔法，它背后是ShiroDialect对Thymeleaf标准属性处理器的重写。我们以最常用的三个标签为例，看它们如何翻译成Shiro API：

注意：principal是Shiro对用户身份标识的统称，不一定是用户名。如果你的Realm中doGetAuthenticationInfo返回的SimpleAuthenticationInfo构造参数是new SimpleAuthenticationInfo(user, user.getPassword(), getName())，那么principal就是user对象本身，你甚至可以在模板里写<span th:text="${#authentication.principal.username}"></span>直接取字段。

但这里有个坑：如果principal是String类型（比如只返回用户名），而你在模板里试图调用principal.email，Thymeleaf会抛PropertyNotFoundException。解决方案是在Realm中返回完整的User对象，并确保其getter方法符合JavaBean规范。

2.4 权限缓存穿透防护：为什么你的“权限按钮”总在刷新后消失

线上曾遇到一个诡异问题：管理员登录后，首页的“删除用户”按钮正常显示；但F5刷新页面，按钮突然消失。排查发现是Shiro的权限缓存机制在作祟。

Shiro默认使用MemoryConstrainedCacheManager，它把权限数据（如角色-权限映射关系）缓存在JVM内存中。当用户首次登录，Shiro从Realm加载其角色列表，再根据角色查出所有权限字符串，存入缓存。但问题在于：这个缓存是按Subject的Principal（即用户标识）为key存储的，而Thymeleaf模板渲染时，可能触发多次isPermitted()调用，每次调用都尝试从缓存取数据。

如果缓存未命中（比如刚更新了权限配置但缓存未刷新），Shiro会回源Realm重新查询——而很多自定义Realm的doGetAuthorizationInfo方法里，习惯性地写return null表示无权限，导致模板判断失败。

解决思路有二：

1. 强制缓存预热：在用户登录成功后，主动调用subject.checkRole()和subject.isPermitted()触发缓存加载；
2. 改用可靠缓存：集成Redis作为Shiro的AuthorizationCache，避免单机内存缓存失效问题。

后者更彻底。配置如下：

@Bean public CacheManager cacheManager(RedisTemplate redisTemplate) { RedisCacheManager cacheManager = new RedisCacheManager(); cacheManager.setRedisTemplate(redisTemplate); // 设置权限缓存过期时间（秒） cacheManager.setExpire(1800); return cacheManager; } @Bean public SecurityManager securityManager(Realm realm, CacheManager cacheManager) { DefaultWebSecurityManager securityManager = new DefaultWebSecurityManager(); securityManager.setRealm(realm); securityManager.setCacheManager(cacheManager); return securityManager; }

此时权限数据存入Redis，所有集群节点共享同一份缓存，彻底规避刷新丢失问题。

3. 从零搭建可落地的整合工程：五步闭环实现

现在我们把理论变成可运行的代码。以下步骤基于真实项目结构设计，每一步都标注了为什么必须这么做，而非简单罗列命令。

3.1 第一步：Maven依赖精准锁定版本

很多整合失败源于依赖冲突。SpringBoot 2.7默认引入spring-boot-starter-web，它依赖spring-webmvc5.3.x，而Shiro 1.11.0要求javax.servlet-api4.0.1以上。若不显式声明，Maven可能拉取低版本Servlet API导致Filter类找不到。

<dependencies> <!-- SpringBoot核心 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <version>2.7.18</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> <version>2.7.18</version> </dependency> <!-- Shiro核心 --> <dependency> <groupId>org.apache.shiro</groupId> <artifactId>shiro-spring-boot-web-starter</artifactId> <version>1.11.0</version> </dependency> <!-- Shiro与Thymeleaf桥接 --> <dependency> <groupId>com.github.theborakompanioni</groupId> <artifactId>thymeleaf-extras-shiro</artifactId> <version>2.0.0</version> </dependency> <!-- Servlet API显式声明，避免版本冲突 --> <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency> </dependencies>

注意：thymeleaf-extras-shiro2.0.0是目前唯一兼容SpringBoot 2.7 + Thymeleaf 3.1的稳定版。网上流传的1.2.x版本在Thymeleaf 3.1中会因ITemplateContext接口变更而报ClassCastException。

3.2 第二步：自定义Realm实现双认证逻辑

真实项目中，用户可能来自不同数据源：普通用户存MySQL，第三方登录用户存Redis，系统管理员硬编码在配置里。Shiro的Realm设计天生支持这种混合模式。

我们写一个MultiSourceRealm，它按顺序尝试三种认证方式：

public class MultiSourceRealm extends AuthorizingRealm { @Autowired private UserService userService; // MySQL用户服务 @Autowired private RedisTemplate redisTemplate; // Redis用户缓存 // 硬编码管理员（仅用于演示，生产环境请移至配置中心） private final Map<String, String> adminUsers = Map.of( "admin", "8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918" ); @Override protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException { UsernamePasswordToken upToken = (UsernamePasswordToken) token; String username = upToken.getUsername(); // 1. 先查硬编码管理员 if (adminUsers.containsKey(username)) { String passwordHash = adminUsers.get(username); return new SimpleAuthenticationInfo( username, // principal passwordHash, // credentials (SHA256哈希) getName() // realm name ); } // 2. 再查Redis缓存（第三方登录用户） String redisKey = "user:third:" + username; Object cachedUser = redisTemplate.opsForValue().get(redisKey); if (cachedUser != null) { User user = (User) cachedUser; return new SimpleAuthenticationInfo( user, // principal为完整User对象 user.getPassword(), // credentials getName() ); } // 3. 最后查MySQL User dbUser = userService.findByUsername(username); if (dbUser != null) { return new SimpleAuthenticationInfo( dbUser, dbUser.getPassword(), getName() ); } throw new UnknownAccountException("用户不存在: " + username); } @Override protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) { User user = (User) principals.getPrimaryPrincipal(); SimpleAuthorizationInfo info = new SimpleAuthorizationInfo(); // 加载角色（假设User实体有getRoles()方法） info.setRoles(user.getRoles()); // 加载权限（支持字符串和Permission对象两种形式） List<String> permissions = userService.findPermissionsByUserId(user.getId()); info.setStringPermissions(new HashSet<>(permissions)); return info; } }

这个Realm的关键设计点：

• 认证顺序可控：硬编码→Redis→MySQL，避免每次登录都查库；
• Principal类型统一：无论从哪来的用户，都返回User对象，确保Thymeleaf中#authentication.principal.username始终可用；
• 密码安全处理：硬编码管理员密码用SHA256哈希存储，符合最小权限原则。

3.3 第三步：ShiroFilter链的URL权限精确映射

URL权限配置是Shiro最易出错的部分。新手常犯的错误是把所有路径写成/** = authc，结果连/static/css/app.css都要登录才能访问，导致页面样式丢失。

正确的做法是分层配置，按资源敏感度划分：

@Bean public ShiroFilterFactoryBean shiroFilterFactoryBean(SecurityManager securityManager) { ShiroFilterFactoryBean bean = new ShiroFilterFactoryBean(); bean.setSecurityManager(securityManager); // 定义Filter链 Map<String, String> filterChainDefinitionMap = new LinkedHashMap<>(); // 1. 静态资源放行（CSS/JS/图片） filterChainDefinitionMap.put("/static/**", "anon"); filterChainDefinitionMap.put("/favicon.ico", "anon"); // 2. 登录相关路径 filterChainDefinitionMap.put("/login", "anon"); filterChainDefinitionMap.put("/login-error", "anon"); filterChainDefinitionMap.put("/logout", "logout"); // 3. API接口权限（RESTful风格） filterChainDefinitionMap.put("/api/v1/users/**", "authc,perms[user:read]"); filterChainDefinitionMap.put("/api/v1/users/**", "authc,perms[user:update]"); filterChainDefinitionMap.put("/api/v1/admin/**", "authc,roles[ADMIN]"); // 4. 页面级权限（Thymeleaf模板） filterChainDefinitionMap.put("/admin/**", "authc,roles[ADMIN]"); filterChainDefinitionMap.put("/user/profile", "authc"); filterChainDefinitionMap.put("/user/settings", "authc,perms[user:settings]"); // 5. 默认拦截：所有其他路径需登录 filterChainDefinitionMap.put("/**", "authc"); bean.setFilterChainDefinitionMap(filterChainDefinitionMap); return bean; }

重点解析几个易错配置：

• /api/v1/users/**同时配置了perms[user:read]和perms[user:update]？这是错误示范！Shiro的Filter链是“或”关系，只要满足任一条件就放行。正确做法是合并为perms[user:read,user:update]，或用rest[user]这种REST风格过滤器。
• /admin/**用roles[ADMIN]而非perms[admin:*]，因为角色判断比权限字符串匹配更快，且符合RBAC模型中“角色决定可见范围”的设计原则。
• /**放在最后，确保前面的精确路径规则优先生效——这是Filter链的匹配逻辑，不是正则优先级。

3.4 第四步：Thymeleaf模板中的权限控制实战

现在看一个真实管理后台的HTML片段，展示如何组合使用各种权限标签：

<!DOCTYPE html> <html xmlns:th="http://www.thymeleaf.org" xmlns:sec="http://www.thymeleaf.org/extras/shiro"> <head> <title>用户管理</title> </head> <body> <!-- 顶部导航栏：仅登录用户可见 --> <nav sec:authorize="principal != null"> <ul> <li><a href="/user/profile">个人资料</a></li> <li sec:authorize="hasRole('ADMIN')"><a href="/admin/dashboard">管理后台</a></li> <li><a href="/logout">退出登录</a></li> </ul> </nav> <!-- 用户列表表格 --> <table> <thead> <tr> <th>用户名</th> <th>邮箱</th> <th>操作</th> </tr> </thead> <tbody> <tr th:each="user : ${users}"> <td th:text="${user.username}"></td> <td th:text="${user.email}"></td> <td> <!-- 编辑按钮：需user:update权限 --> <button type="button" sec:authorize="hasPermission('user:update')" th:onclick="'editUser(\'' + ${user.id} + '\')'"> 编辑 </button> <!-- 删除按钮：仅管理员可见，且需user:delete权限 --> <button type="button" sec:authorize="hasRole('ADMIN') and hasPermission('user:delete')" th:onclick="'deleteUser(\'' + ${user.id} + '\')'"> 删除 </button> </td> </tr> </tbody> </table> <!-- 批量操作区域：仅当用户有批量权限时显示 --> <div sec:authorize="hasPermission('user:batch')"> <button type="button" onclick="batchImport()">批量导入</button> <button type="button" onclick="batchExport()">批量导出</button> </div> <!-- 未登录提示 --> <div sec:authorize="!isAuthenticated()"> <p>请先<a href="/login">登录</a>查看用户列表</p> </div> </body> </html>

这个模板体现了四个关键技巧：

1. 组合条件：sec:authorize="hasRole('ADMIN') and hasPermission('user:delete')"，避免仅靠角色判断导致权限过大；
2. 动态参数传递：th:onclick中拼接${user.id}，确保JavaScript能获取当前行数据；
3. 兜底提示：sec:authorize="!isAuthenticated()"覆盖未登录状态，提升用户体验；
4. 语义化分组：将批量操作单独用<div>包裹，便于CSS控制显示/隐藏。

注意：sec:authorize不支持复杂的SpEL表达式（如#authentication.principal.type == 'ADMIN'），所有逻辑必须简化为Shiro提供的标准方法调用。若需复杂判断，应在Controller中计算好布尔值传入Model。

3.5 第五步：全局异常处理与登录态保持

最后补上两个生产环境必备环节：异常统一处理和RememberMe配置。

全局异常处理器

Shiro抛出的异常（如UnauthorizedException、UnauthenticatedException）需要被Spring捕获并转为友好页面：

@ControllerAdvice public class ShiroExceptionHandler { @ExceptionHandler(UnauthenticatedException.class) public String unauthenticatedExceptionHandler(HttpServletRequest request) { // 未登录，重定向到登录页 return "redirect:/login?error=unauthenticated"; } @ExceptionHandler(UnauthorizedException.class) public String unauthorizedExceptionHandler(HttpServletRequest request) { // 无权限，跳转到403页面 return "error/403"; } }

对应templates/error/403.html：

<!DOCTYPE html> <html xmlns:th="http://www.thymeleaf.org"> <head> <title>权限不足</title> </head> <body> <h1>抱歉，您没有访问此页面的权限</h1> <p th:if="${#authentication.principal != null}"> 您当前角色：<span th:text="${#authentication.principal.roleName}"></span> </p> <a href="/">返回首页</a> </body> </html>

RememberMe自动登录

启用RememberMe后，用户勾选“记住我”，下次访问自动登录：

@Bean public SecurityManager securityManager(Realm realm) { DefaultWebSecurityManager securityManager = new DefaultWebSecurityManager(); securityManager.setRealm(realm); // 启用RememberMe CookieRememberMeManager rememberMeManager = new CookieRememberMeManager(); // 使用AES加密RememberMe Cookie（密钥需生产环境替换） rememberMeManager.setCipherKey(Base64.decode("4AvVhmFLUs0KTA3Kprsdag==")); securityManager.setRememberMeManager(rememberMeManager); return securityManager; }

在登录表单中添加RememberMe字段：

<form action="/login" method="post"> <input type="text" name="username" required /> <input type="password" name="password" required /> <label> <input type="checkbox" name="rememberMe" /> 记住我 </label> <button type="submit">登录</button> </form>

RememberMe的Cookie默认有效期为maxAge=1209600（14天），可通过SimpleCookie配置调整。

4. 生产环境避坑指南：那些文档不会写的细节

整合看似简单，但上线后常因几个隐蔽细节引发故障。以下是我在三个不同规模项目中踩过的坑，附带验证方法和修复方案。

4.1 坑位一：ShiroFilter与Spring SecurityFilterChain的加载顺序冲突

现象：项目同时引入了spring-boot-starter-security和shiro-spring-boot-web-starter，启动时报错Filter with name 'shiroFilter' is already registered，或权限控制完全失效。

根因：SpringBoot 2.7默认注册SpringSecurityFilterChain，而Shiro Starter也试图注册自己的ShiroFilter。两者都是Filter类型，Spring容器按Bean名称排序，若shiroFilter排在springSecurityFilterChain之后，Shiro的Filter就无法生效。

验证方法：启动时加JVM参数-Dlogging.level.org.springframework.boot.web.servlet=DEBUG，观察日志中Filter注册顺序。

修复方案：强制ShiroFilter优先加载。在application.yml中配置：

spring: main: allow-bean-definition-overriding: true shiro: enabled: true filter: # 关键：禁用Shiro Starter的自动Filter注册 auto-registry: false

然后手动定义Filter Bean，并指定@Order：

@Bean @Order(-100) // 数值越小，优先级越高 public FilterRegistrationBean<ShiroFilterFactoryBean> shiroFilterRegistration( ShiroFilterFactoryBean shiroFilterFactoryBean) { FilterRegistrationBean<ShiroFilterFactoryBean> registration = new FilterRegistrationBean<>(); registration.setFilter(shiroFilterFactoryBean); registration.setEnabled(true); registration.addUrlPatterns("/*"); registration.setName("shiroFilter"); return registration; }

4.2 坑位二：Thymeleaf模板中sec:authorize在AJAX请求中失效

现象：页面用jQuery AJAX加载用户列表，返回的HTML片段中sec:authorize标签未被解析，显示为原始文本<button sec:authorize="...">。

根因：sec:authorize是Thymeleaf的服务器端标签，只在服务端渲染HTML时生效。AJAX返回的是纯HTML字符串，浏览器端无法执行Thymeleaf语法。

解决方案分两种场景：

• 服务端渲染片段：用ThymeleafViewResolver返回Fragment，Controller返回"user :: list"（指向user.html中的<div th:fragment="list">），此时ShiroDialect仍生效；
• 客户端权限控制：在AJAX成功回调中，用JavaScript读取window.currentUserRole（由后端在页面中注入），再动态显示/隐藏按钮：

<!-- 在主页面中注入当前用户角色 --> <script th:inline="javascript"> var currentUserRole = [[${#authentication.principal.role}]]; </script>

// AJAX回调中 success: function(data) { $('#user-list').html(data); // 根据角色动态控制按钮 if (currentUserRole !== 'ADMIN') { $('.delete-btn').hide(); } }

4.3 坑位三：分布式Session导致Shiro权限判断不一致

现象：项目部署在Nginx+两台Tomcat集群，用户A在Tomcat1登录后，访问Tomcat2的/admin页面时提示“权限不足”。

根因：Shiro默认使用ServletContainerSessionManager，Session存储在单机内存中。用户请求被Nginx分发到不同Tomcat时，Shiro无法获取原Session中的Subject状态。

验证方法：在两台机器上分别打印SecurityUtils.getSubject().getSession().getId()，若ID不同则确认是Session未共享。

修复方案：集成Redis作为Session存储。使用shiro-redis插件：

<dependency> <groupId>org.crazycake</groupId> <artifactId>shiro-redis</artifactId> <version>3.3.1</version> </dependency>

配置RedisSessionDAO：

@Bean public SessionDAO sessionDAO() { RedisSessionDAO sessionDAO = new RedisSessionDAO(); sessionDAO.setRedisManager(redisManager()); sessionDAO.setExpire(1800); // Session过期时间（秒） return sessionDAO; } @Bean public SessionManager sessionManager() { DefaultWebSessionManager sessionManager = new DefaultWebSessionManager(); sessionManager.setSessionDAO(sessionDAO()); sessionManager.setGlobalSessionTimeout(1800000); // 30分钟 return sessionManager; }

此时所有Tomcat节点共享同一份Session，Subject状态全局一致。

4.4 坑位四：Thymeleaf缓存导致权限修改不生效

现象：管理员在后台修改了用户权限，但用户刷新页面后，sec:authorize仍显示旧权限。

根因：Thymeleaf默认开启模板缓存（spring.thymeleaf.cache=true），它缓存的是渲染后的HTML，而非权限判断逻辑。但更深层的问题是：权限数据被Shiro缓存，而缓存未及时刷新。

验证方法：关闭Thymeleaf缓存（spring.thymeleaf.cache=false），问题依旧存在，则确认是Shiro缓存问题。

修复方案：提供手动刷新权限缓存的管理接口：

@RestController @RequestMapping("/admin/cache") public class CacheController { @Autowired private CacheManager cacheManager; @PostMapping("/clear-authz") public Result clearAuthzCache(@RequestParam String username) { // 清除指定用户的授权缓存 Cache<Object, Object> authzCache = cacheManager.getCache("authorization"); authzCache.remove(username); return Result.success("缓存已清除"); } }

在权限管理页面添加“刷新缓存”按钮，调用此接口即可。

5. 权限模型演进：从RBAC到ABAC的平滑过渡

当项目发展到一定规模，单纯的角色-权限模型（RBAC）会显得僵硬。比如“财务专员”角色通常有invoice:read权限，但某次审计要求：只有处理过100万以上合同的财务专员，才能查看历史发票。这时就需要属性基访问控制（ABAC）。

Shiro原生不支持ABAC，但可以通过自定义Permission类实现平滑过渡。

5.1 定义ABAC Permission类

public class InvoicePermission implements Permission { private final String resource; private final String action; private final int contractAmount; // 合同金额阈值（万元） public InvoicePermission(String resource, String action, int contractAmount) { this.resource = resource; this.action = action; this.contractAmount = contractAmount; } @Override public boolean implies(Permission p) { if (!(p instanceof InvoicePermission)) { return false; } InvoicePermission that = (InvoicePermission) p; // ABAC核心逻辑：当前权限的合同金额阈值 <= 请求权限的阈值 return this.resource.equals(that.resource) && this.action.equals(that.action) && this.contractAmount <= that.contractAmount; } }

5.2 在Realm中动态生成ABAC权限

@Override protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) { User user = (User) principals.getPrimaryPrincipal(); SimpleAuthorizationInfo info = new SimpleAuthorizationInfo(); // 加载基础RBAC权限 info.setRoles(user.getRoles()); info.setStringPermissions(user.getPermissions()); // 动态添加ABAC权限 int maxContract = userService.findMaxContractAmountByUserId(user.getId()); if (maxContract >= 100) { // 合同额超100万，授予高阶权限 info.addObjectPermission(new InvoicePermission("invoice", "read", 100)); } return info; }

5.3 在Controller中使用ABAC权限

@GetMapping("/invoices/history") @RequiresPermissions("invoice:read:100") // 自定义权限字符串解析 public String history(Model model) { // 返回历史发票列表 return "invoice/history"; }

此时@RequiresPermissions注解会触发Shiro的PermissionResolver，将其解析为InvoicePermission("invoice", "read", 100)，再调用implies()方法与Realm中加载的权限比对。

这种设计的优势在于：
✅ 不破坏现有RBAC结构，ABAC作为补充；
✅ 权限判断逻辑集中在implies()方法，易于单元测试；
✅ 未来可扩展为JSON格式权限（如{"resource":"invoice","action":"read","conditions":{"contractAmount":">=100"}}），对接策略引擎。

我在某金融系统中实践过此方案，将ABAC权限控制接入风控规则引擎，实现了“根据用户信用分动态调整数据导出权限”的需求，整个过程未改动一行Shiro核心代码。

6. 性能压测实录：万级并发下的Shiro响应表现

最后分享一组真实压测数据。我们用JMeter对整合后的系统进行压力测试，目标是验证Shiro在高并发下的稳定性。

6.1 测试环境配置

• 应用服务器：SpringBoot 2.7.18（JVM参数：-Xms2g -Xmx2g -XX:+UseG1GC）
• 数据库：MySQL 8.0（连接池HikariCP，最大连接数100）
• 缓存：Redis 7.0（单节点，6GB内存）
• 压测工具：JMeter 5.4.1，线程组设置1000线程，Ramp-up时间60秒

6.2 关键指标对比