带@Transactional注解的类中Entity更新及自定义UserDetails登录实现问询

结合你给出的代码片段，这里有几个关键的注意事项：

• 确保序列化正确性：Spring Security会把UserDetails对象存入Session（如果使用Session认证），所以你的CustomUserDetails以及内部的UserEntity必须实现Serializable接口，否则会抛出序列化异常，导致认证失败。
• 权限信息不能出错：虽然你继承了org.springframework.security.core.userdetails.User，但一定要保证getAuthorities()返回的权限集合准确对应用户的角色和权限。比如从UserEntity中取出角色列表，转换成SimpleGrantedAuthority对象（注意角色是否需要加ROLE_前缀取决于你的权限配置逻辑），如果权限返回错误，后续的URL或方法权限控制会完全失效。
• 用户状态校验必须到位：在loadUserByUsername方法中，查询到用户后，一定要检查用户的状态：是否启用（isEnabled）、账户是否锁定（isAccountNonLocked）、凭证是否过期（isCredentialsNonExpired）、账户是否过期（isAccountNonExpired）。这些状态要从UserEntity中取出，在构造CustomUserDetails时传入——Spring Security的默认认证逻辑会校验这些状态，忽略的话会导致禁用用户仍能登录的问题。
• 避免冗余数据占用Session：别把UserEntity的所有关联对象都塞进CustomUserDetails里（比如用户的订单、日志等），否则Session会变得很大，影响系统性能。只保留认证和权限控制必需的字段（比如id、username、email、角色）即可；如果必须关联其他数据，考虑用懒加载，但要注意Session关闭后懒加载的NPE问题。
• 用户名查询逻辑要严谨：你通过判断username是否包含@来区分邮箱和用户名登录，这里要注意业务边界：如果你的系统允许用户名包含@，这个逻辑就会出错。建议要么在数据库层面保证邮箱和用户名的唯一性，要么提供明确的登录类型参数，避免查询混淆。
• 异常处理要符合规范：loadUserByUsername必须在用户不存在时抛出UsernameNotFoundException，绝对不能返回null——否则Spring Security会抛出其他无法预期的异常。处理Optional时可以用orElseThrow来简化代码：

  UserEntity user = userOptional.orElseThrow(() -> 
      new UsernameNotFoundException("User not found: " + username)
  );
  

• Service Bean的命名要正确：你用了@Service("userDetailsService")，这个名字很关键——Spring Security默认会查找名为userDetailsService的Bean来做用户认证。如果名字不对，就需要在Security配置类中显式指定userDetailsService的Bean，否则会出现找不到用户服务的错误。
• 密码编码要保持一致：loadUserByUsername返回的CustomUserDetails中的密码，必须是数据库中存储的加密后的密码，且加密方式要和注册/修改密码时一致（比如BCrypt）。Spring Security的认证器会用配置的PasswordEncoder来匹配前端传入的明文密码和数据库密文，所以绝对不能存明文，也不能混用不同的加密算法。

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