Spring Boot中应在哪个环节将密码保存至数据库？

重复哈希问题的根因 #

你之前遇到的双重哈希问题，本质不是把逻辑放在了Service层，而是没有做场景隔离：之前的实现大概率是对所有调用save的操作无差别执行密码哈希，完全不区分当前操作的类型。这时候如果是更新昵称、联系方式这类和密码完全无关的操作，流程中携带的密码本来就是数据库里存储的哈希值，被再次哈希一次，自然就和原始存储值对不上，导致后续CRUD更新、登录校验全部异常。

能不能把哈希逻辑放在User实体的setter方法里 #

绝对不推荐这么做，核心原因有三个：

• 实体类是和数据库表映射的POJO，设计原则是职责单一，不应该承载密码加密这类需要依赖外部组件（比如PasswordEncoder）的业务逻辑。而且实体是由JPA/Hibernate通过反射管理的，没办法正常注入Spring容器的Bean，很容易出现空指针。
• JPA从数据库查询数据、填充实体字段时，会自动通过反射调用setter方法。这时候读出来的密码本身就是已经完成哈希的存量值，setter自动执行哈希逻辑的话，会直接把正确的哈希值二次加密，导致后续校验全部失效。
• 没有灵活的场景判断能力：只要调用setPassword()就会触发哈希，完全没办法区分「当前传入的是需要加密的明文新密码」和「当前传入的是已加密的存量密码值」两类场景。

适配你当前UserRepository架构的正确实现方案 #

Service层本来就是放置业务逻辑的合理位置，只需要把无差别的哈希逻辑拆成场景化判断即可，不需要额外调整分层：

• 只在明确需要处理明文密码的业务入口执行哈希：也就是用户注册、用户修改密码两个场景，拿到前端传递的明文密码后，通过PasswordEncoder生成哈希值，再set到User实体上，最后调用userRepository.save()落库。
• 其他所有和密码无关的用户信息更新操作（比如修改昵称、联系方式、头像），直接从数据库查出对应的User实体，只修改需要更新的字段，全程不触碰密码字段，直接调用save即可，完全不会触发重复哈希的问题。

如果希望减少业务层的重复判断，也可以选择结合JPA的生命周期回调做适配，但要注意在回调方法中增加格式判断：比如BCrypt格式的哈希值都会以$2a$、$2b$这类固定前缀开头，如果检测到当前密码字段已经是符合加密格式的值，就跳过哈希逻辑，只对明文值做加密处理。但这种方式依然需要注意不要把逻辑写在setter方法里，要使用@PrePersist、@PreUpdate这类专门的生命周期注解实现。

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