应采用双轨并存+渐进升级策略：保留旧哈希值，新增scheme标识字段，登录时按标识调用对应验证算法，成功后立即用新算法更新；禁用批量重算，避免安全风险。
旧密码哈希无法被新系统验证怎么办
直接换加密方式会导致所有存量用户登录失败——新系统算出的 hash 和数据库里老的 hash 对不上，这是最典型的兼容断裂点。核心思路不是“统一换掉”，而是“双轨并存 + 渐进升级”。
- 数据库字段必须保留原始哈希值（比如
password_hash），同时加一个标识字段（如password_scheme），记录这条密码是用bcrypt、sha256还是md5算的 - 登录时先查
password_scheme，再调用对应算法验证；匹配成功后，立刻用新算法重算并更新字段（含password_hash和password_scheme） - 绝不批量重算旧密码——没明文，没法批量转；强行用弱算法反推等于放弃安全底线
Node.js 里怎么安全支持多套密码验证逻辑
别写一堆 if (scheme === 'md5') {...} 堆砌判断。用策略模式更清晰，也方便后续加新算法。
- 把每种算法封装成独立函数，统一接收
password和storedHash，返回boolean，例如：verifyWithMD5(password, storedHash)、verifyWithBcrypt(password, storedHash) - 用对象映射方案：
const verifiers = { md5: verifyWithMD5, bcrypt: verifyWithBcrypt }，查表调用比 if/else 更易维护 - 注意：
bcrypt.compare()内部有防时序攻击设计，而手写的md5(password) === storedHash没有——如果还留着 MD5，至少用crypto.timingSafeEqual()做比较
Java Spring Security 怎么配置混合 PasswordEncoder
Spring Security 5.0+ 的 DelegatingPasswordEncoder 就是为这事设计的，但默认只认 {bcrypt} 这类前缀，旧数据往往没前缀。
- 初始化时用
new MessageDigestPasswordEncoder("md5")或new StandardPasswordEncoder("secret")（已弃用，仅过渡）包装旧逻辑 - 注册多个
PasswordEncoder到DelegatingPasswordEncoder，并指定默认编码器；对无前缀的 hash，让它 fallback 到你写的LegacyPasswordEncoder - 关键陷阱：
matches()方法里不能直接抛异常，要返回false，否则认证流程会中断；错误日志里记下 scheme 不匹配，方便后续审计
MySQL 用户表加字段时要注意什么
加 password_scheme 字段看似简单，但线上表结构变更容易锁表或丢数据。
- 用
ALTER TABLE users ADD COLUMN password_scheme VARCHAR(16) DEFAULT 'md5'，别设NOT NULL初始值——老数据迁移前字段为空，强制非空会失败 - 批量更新旧数据时，分批次执行：
UPDATE users SET password_scheme = 'md5' WHERE id BETWEEN 1000 AND 2000 AND password_scheme IS NULL，避免长事务阻塞 - 确认应用层所有读写路径都已适配新字段，尤其注意管理员后台重置密码、第三方 OAuth 回调等边缘路径——它们可能绕过主登录逻辑，直接写死某种 hash 方式
真正难的不是换算法，是理清哪些服务还在用旧连接池、哪些客户端缓存了硬编码的加盐逻辑、哪些运维脚本会直连数据库做批量操作——这些地方漏一个，就可能让某类用户永远登不进去。
