shiro异常需显式构建异常链以保留原始原因：在自定义realm中用带cause构造器重抛，避免吞异常；securitymanager和全局处理器须透传cause；日志应调用log.error("msg", e)完整打印链路；spring中通过@exceptionhandler获取getcause()精准分类处理。
Shiro权限认证失败时，直接抛出的异常（如 UnauthorizedException 或 AuthenticationException）往往丢失原始原因——比如数据库连接超时、LDAP服务不可达、自定义 Realm 中的空指针或 SQL 执行异常。要保留真实上下文，必须显式构建异常链，让上层能通过 getCause() 逐层追溯。
在自定义 Realm 中主动封装原始异常
Shiro 的认证/授权逻辑通常写在 doGetAuthenticationInfo 或 doGetAuthorizationInfo 中。这里一旦发生底层异常（如 JPA 查询失败、Redis 连接中断），不应吞掉或简单包装为通用异常，而应用带 cause 的构造器重抛：
- 使用
new AuthenticationException("登录失败", originalException)，而非new AuthenticationException("登录失败") - 若原始异常是受检异常（如
SQLException），可包裹为运行时异常再链入：throw new AuthenticationException("获取用户信息失败", new RuntimeException(e)) - 避免在 catch 块中只记录日志却不重抛异常，否则调用链断裂
在 SecurityManager 或 Filter 层不破坏异常链
Shiro 的 SecurityManager 默认会将底层异常转为标准认证/授权异常，但部分自定义配置（如包装了异常处理器的 Spring AOP 切面）可能无意中截断 cause。需确保：
- 全局异常处理器（如
@ControllerAdvice）处理AuthenticationException时，调用e.getCause()获取根因，而不是仅输出e.getMessage() - 若使用 ShiroFilterFactoryBean，不要在 filter 链中用 try-catch 吞掉异常并返回新异常
- 在
ModularRealmAuthenticator的子类中覆写方法时，保留cause参数传递逻辑
日志与调试时正确展开异常链
SLF4J 或 Logback 默认只打印异常的首层堆栈。要看到完整链路，需显式记录 cause：
- 使用
log.error("认证失败", e)（推荐）——SLF4J 会自动递归打印 cause - 避免
log.error("认证失败: " + e.getMessage())，这丢弃了堆栈和嵌套信息 - 在 IDE 调试时，展开异常对象的
cause字段，逐层查看：例如AuthenticationException → RuntimeException → SQLException → SocketTimeoutException
配合 Spring 时利用 @ExceptionHandler 精准捕获并透传
Spring MVC 项目中，可在控制器层统一处理，并将原始异常信息透传给前端（如返回 error code 和 root cause 类型）：
- 定义
@ExceptionHandler(AuthenticationException.class)方法 - 在方法内调用
e.getCause()判断是否为SQLException或IOException，区分返回 “系统繁忙” 或 “账号异常” - 将
e.getCause().getClass().getSimpleName()作为 error_type 字段写入响应体，便于前端分类提示或埋点监控
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
