咱们先从你给出的配置代码入手，一步步拆解Spring Security识别用户角色的逻辑：

1. 角色数据的加载：从数据库到Spring Security #

你配置里的auth.jdbcAuthentication()是Spring Security提供的JDBC认证方式，其中两个关键的SQL查询负责加载用户和角色信息：

• usersByUsernameQuery：用来获取用户的基础信息（用户名、加密后的密码、账号是否启用），这是登录校验的基础。
• authoritiesByUsernameQuery：这就是加载用户角色的核心！你写的SQL（select username, role from user inner joi...）应该是关联用户表和角色表，查询出指定用户名对应的所有角色。

当用户登录时，Spring Security会执行这个角色查询SQL，把返回的每一条role值封装成GrantedAuthority对象（Spring Security中表示权限/角色的标准接口），最终和用户信息一起存入Authentication对象中。

2. 角色的识别与权限校验逻辑 #

有了加载好的角色数据，Spring Security就靠这些GrantedAuthority来做权限判断：

• HTTP请求权限控制：比如你配置http.authorizeRequests().antMatchers("/admin/**").hasRole("ADMIN")时，Spring Security会自动给ADMIN加上ROLE_前缀，检查用户的GrantedAuthority中是否存在ROLE_ADMIN。
• 方法级权限控制：如果用@PreAuthorize("hasRole('ADMIN')")注解，逻辑和上面一样，也是基于GrantedAuthority集合来匹配。
• 如果你不想用默认的ROLE_前缀，可以用hasAuthority()方法，它会直接匹配数据库中存储的角色名（比如数据库存的是ADMIN，就写hasAuthority("ADMIN")）。

3. 关键细节提醒 #

• 确保你的authoritiesByUsernameQuery能正确返回所有用户对应的角色，一个用户可能有多个角色，SQL需要返回多条记录。
• 密码一定要加密存储！Spring Security默认会校验加密后的密码，如果你用明文密码，需要额外配置密码编码器（比如passwordEncoder(NoOpPasswordEncoder.getInstance())，但生产环境绝对不推荐）。

内容的提问来源于stack exchange，提问作者Daimon