BCryptPasswordEncoder 默认强度为10，但高并发下易致CPU飙升，推荐显式指定strength=11；必须用matches()比对密码，严禁字符串直接比较；Spring Boot 3需显式配置PasswordEncoder Bean，且密码长度不得超过72字节。
BCryptPasswordEncoder 默认强度是 10，别直接用 new BCryptPasswordEncoder()
Spring Security 的 BCryptPasswordEncoder 默认构造函数设的是强度 10，但很多项目上线后才发现：这个值在高并发登录场景下 CPU 占用突增，尤其容器资源受限时容易触发超时。不是不够安全，而是“默认”不等于“适合你”。
- 强度每 +1，计算耗时约翻倍；强度 12 在普通云主机上单次 encode 可能达 250ms+
- 若旧系统迁移，必须记录当时使用的
strength值，否则无法校验老密码 - Spring Boot 2.7+ 中，
new BCryptPasswordEncoder()和new BCryptPasswordEncoder(10)行为一致，但显式写出更利于审计 - 推荐做法：
new BCryptPasswordEncoder(11)（平衡安全与响应）或根据压测结果定值，写死在配置类里
passwordEncoder.matches() 是唯一合法的密码比对方式
别手写字符串比较，也别把 encode() 结果拆开比对盐值——BCrypt 的验证逻辑封装在 matches() 里，它会自动提取哈希中的盐、重算并恒定时间比对，防时序攻击。
- 错误示范：
user.getPassword().equals(encoder.encode(raw))—— 永远 false，且泄露处理逻辑 - 错误示范：
rawPassword.equals(storedHash)—— 明文比密文，毫无意义 - 正确调用：
passwordEncoder.matches(rawPassword, storedHash)，其中storedHash是数据库里存的完整 BCrypt 字符串（形如$2a$11$...） - 注意：
matches()内部会解析storedHash的版本号（$2a$/$2b$/$2y$），Spring Security 5.8+ 默认生成$2a$，但兼容全部
Spring Boot 3.x 起，BCryptPasswordEncoder 不再是默认 PasswordEncoder
Boot 3 引入了 DelegatingPasswordEncoder，启动时若没显式配置，会抛 IllegalArgumentException: There is no PasswordEncoder mapped for the id "null"。这不是 bug，是强制你声明策略。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 原因：支持多算法共存（比如部分用户用 BCrypt，部分用 SCrypt），靠前缀识别，如
{bcrypt}$2a$10$... - 必须在配置类中定义 Bean：
@Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(11); } - 如果沿用旧库（如 Spring Security 5.x 的 XML 配置习惯），漏掉这步，应用根本启不来
- 数据库里存的哈希值建议统一加前缀：
{bcrypt}$2a$11$...，这样即使未来切换策略，也能靠前缀路由
BCrypt 不支持空密码和超长密码（72 字节截断）
这是 BCrypt 算法层限制，不是 Spring 封装的问题。传入超过 72 字节的原始密码，会在 encode 前被静默截断，导致同样输入不同输出（比如 73 字节和 74 字节的密码可能 hash 相同）。
立即学习“Java免费学习笔记（深入）”；
- 常见现象：用户输了一长串特殊符号密码，登录失败，但换短密码就成功——大概率是截断导致 hash 不匹配
- 解决方案：在 service 层做长度校验，例如
if (rawPassword.length() > 72) throw new IllegalArgumentException("Password too long"); - 空密码会被 encode 成固定值（
$2a$10$XXXXXXXXXXXXXXXXXXXXXX...），虽然matches()能正确返回 false，但业务上应拒绝空值 - 别试图 Base64 或 SHA-256 预处理再喂给 BCrypt——破坏盐的随机性，且无实际收益
BCrypt 的盐是每次 encode 自动生成并嵌入结果的，你没法也不该干预它的生成逻辑。真正要盯住的，是 strength 值是否合理、hash 是否带前缀、比对是否走 matches，以及原始密码有没有踩到 72 字节那个隐形墙。
