密码哈希出错主因是Encoder配置不匹配，需显式声明BCryptPasswordEncoder Bean、统一哈希前缀、用matches()比对、合理设置strength值（推荐11）、限制密码≤72字符并扩展数据库字段。
密码哈希出错，八成不是算法本身有问题，而是 Encoder 配置没对上。常见表现包括登录失败、密码修改无效、“invalid_client”报错，或日志里反复出现“Encoded password does not look like BCrypt”这类提示。问题根源往往藏在初始化方式、强度设置、比对逻辑或 Spring Boot 版本适配这几个环节。
确认PasswordEncoder是否已显式声明
Spring Boot 3.x 起，不再提供默认 PasswordEncoder。若没在配置类中明确定义 Bean，应用启动就会抛异常：IllegalArgumentException: There is no PasswordEncoder mapped for the id "null"。
- 必须手动声明：@Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(11); }
- 避免只写
new BCryptPasswordEncoder()——它隐式用 strength=10，高并发下易拖垮 CPU - 数据库中存储的哈希值建议统一加前缀，如
{bcrypt}$2a$11$...，便于未来策略路由
检查密码比对是否用了 matches() 方法
哈希值验证绝不能用字符串相等（.equals()）或手写逻辑。BCrypt 的盐值、版本号、哈希结果都封装在完整字符串里，只有 matches() 能安全提取并恒定时间比对，防时序攻击。
- ✅ 正确：
passwordEncoder.matches(rawPassword, storedHash)（storedHash 是数据库存的完整字符串，如$2a$11$...） - ❌ 错误：
rawPassword.equals(storedHash)或user.getPassword().equals(encoder.encode(...)) - 注意：
matches()内部会自动识别$2a$、$2b$、$2y$等版本，兼容性没问题
核对强度值是否合理且一致
strength 值不是越高越好，也不是越低越快，得在安全与响应之间找平衡点。默认 10 在多数生产环境已偏弱；11 是较稳妥的起点；12 以上需压测，单次 encode 可能超 250ms。
- 高并发登录场景下，strength=10 可能导致 CPU 突增，容器资源受限时触发超时
- 旧系统迁移时，必须保留当时使用的 strength 值，否则无法校验历史密码
- 别在代码里动态算 strength，写死在配置类中，方便审计和统一管理
留意密码长度与内容限制
BCrypt 对输入敏感：空密码不支持；超过 72 字节的密码会被静默截断——这会导致用户输长密码却校验失败，且难以排查。
- 前端可做长度提示（建议 ≤ 72 字符），后端宜加日志告警：若检测到原始密码 > 72 字节，记录 warn 级别日志
- 数据库字段建议设为
VARCHAR(512)（非 255），尤其用 Argon2 等更长哈希时，避免存储截断 - 测试时务必覆盖边界情况：空密码、72 字符、73 字符输入
