shiro 1.10+ 中 securitymanager 不再自动绑定到 threadcontext，需显式调用 securityutils.setsecuritymanager() 初始化；authc 强制有效 session，user 支持 rememberme；shiro 2.0-alpha 不兼容 spring boot 3 的 jakarta ee 9+；hashalgorithmname 必须与密码哈希算法严格一致。
Shiro 1.10+ 中 SecurityManager 不再自动绑定到 ThreadContext
升级到 Shiro 1.10 后，很多老代码里直接调用 SecurityUtils.getSubject() 报 NoSecurityManagerException，根本原因是新版本默认不自动把 SecurityManager 注入线程上下文。这不是配置漏了，是设计变更。
- 必须显式初始化并绑定：在应用启动时（如 Spring 的
@PostConstruct或 Servletinit()）调用SecurityUtils.setSecurityManager(securityManager) - Spring Boot 用户注意：
ShiroConfig里返回的SecurityManagerbean 不会自动绑定，得额外加一个@Bean或监听器触发绑定 - 非 Web 场景（如命令行工具）更易踩坑——没手动绑定就调
getSubject()，必崩
INI 配置里 authc 和 user 过滤器的区别常被搞反
写 /admin/** = authc 看似没问题，但用户登出后再次访问会被重定向到登录页；而用 /profile/** = user 才允许已认证或“记住我”的用户访问。混淆这两者会导致体验断裂甚至权限绕过。
-
authc：强制要求当前请求携带有效 Session（即刚登录、未超时），RememberMe用户也会被拒 -
user：接受已认证用户 +RememberMe用户，适合个人中心类路径 -
anon不代表“无权限”，而是“不参与认证流程”——它跳过所有 Shiro 拦截，别误用在敏感接口上
Spring Boot 3.x + Shiro 2.0-alpha 依赖冲突报 NoClassDefFoundError: org/apache/shiro/mgt/SecurityManager
Shiro 2.0-alpha 尚未适配 Jakarta EE 9+，而 Spring Boot 3 默认使用 jakarta.* 包名。直接引入会因 javax.servlet 类缺失导致启动失败，不是 Shiro 配置问题，是底层包名断层。
- 短期解法：降级到 Spring Boot 2.7.x + Shiro 1.11.x（稳定组合）
- 若必须用 SB3，请确认 Shiro 依赖是否声明了
jakarta.servlet-api，并排除掉所有javax.servlet传递依赖 - Shiro 2.0 官方尚未发布正式版，alpha 版不建议用于生产环境
HashedCredentialsMatcher 的 hashAlgorithmName 必须和密码哈希时一致
后台用 MD5 加盐算出密码存库，但配置里写成 SHA-256，登录永远失败。这个参数不校验合法性，也不会报错，只会默默比对失败。
立即学习“Java免费学习笔记（深入）”；
- 常见错误值：
md5（小写）、MD5（大写）、md5s（多打 s）——Shiro 只认标准算法名，如MD5、SHA-256 - 如果用了自定义 Hash（如加了多次迭代），必须用
HashedCredentialsMatcher子类，不能只改算法名 - 数据库里存的密文长度可辅助判断：MD5 是 32 位 hex，SHA-256 是 64 位
Shiro 的核心复杂点不在配置语法，而在它的生命周期管理（尤其是线程绑定）和安全语义边界（比如 user 和 authc 的实际行为差异）。这些地方不写日志、不抛明确异常，容易调试半天才发现是概念理解偏差。
