常见密码迁移场景
搞密码迁移自动化，说白了就三种常见场景：数据库迁移、配置文件迁移、用户系统迁移。我这些年大大小小的项目，几乎每个都会碰到其中至少一种。你想想看，如果能把这三类场景的自动化路子摸透，后续碰到再奇葩的需求也能举一反三。
1. 数据库迁移
这是最常见的场景。比如你要把 MySQL 的密码表迁到 PostgreSQL，或者从自建库迁到云数据库。密码字段本身通常经过哈希或加密，迁移时最怕格式不兼容、编码错乱、哈希算法不一致。
核心原则：绝不在迁移过程中尝试解密或重新哈希。只搬「密文」本身。
我习惯把数据库密码迁移拆成三步：
- 导出阶段：用
SELECT password_hash, salt, created_at ...把密码相关列单独导出成 CSV 或 JSON。 - 校验阶段：检查目标数据库的字段类型（比如 MySQL 的
VARCHAR(255)迁到 SQL Server 的NVARCHAR(256)）是否足够容纳源数据。我在项目中遇到过因为字段长度不够导致迁移失败的事——嗯，后来我每次都会加一个长度检查脚本。 - 导入阶段：用批量 INSERT，并开启事务。记得加上
ON CONFLICT处理逻辑，别因为一条脏数据把整个批次回滚了。
特别注意：如果源库和目标库的哈希算法不同（比如 MD5 → bcrypt），别在迁移时做转换！应该先迁密文，再通过业务逻辑逐步升级。我曾经图省事直接改，结果所有密码都验证失败，用户炸了。
2. 配置文件迁移
很多项目把数据库连接密码、 写在 .env、application.yml 或 config.json 里。当 CI 流水线换环境或重构配置中心时，迁移这些文件就成了头疼事。
我个人建议做三步：
- 摸底：用 grep 扫描所有配置文件，标记出所有含密码、、secret 的键。举个例子：
grep -rn "password\|secret\|" config/ --include="*.{yml,json,env}"- 标准化：把所有密码值替换成占位符，比如
${DB_PASSWORD}。实际值统一存到 CI 的 secrets 或 Vault 里。 - 自动化替换：写一个脚本，在部署阶段从密钥存储拉取真实值，注入到配置文件。
我常用的做法是：在 Git 仓库里只留模板（含占位符），CI 构建时用
envsubst 或 sed 替换。这样密码永远不会进版本历史。
有一回我接手一个遗留项目，配置文件里直接硬编码了生产密码。迁移时我傻眼了——得先找出所有地方，还要确保替换后不影响运行。后来我写了个「占位符自动生成 + 替换验证」的 CI 任务，才算把这坑填平。
| 步骤 | 操作 | 避坑要点 |
|---|---|---|
| 摸底 | 扫描所有配置文件中的密钥 | 注意注释中的密码也可能被误当变量 |
| 标准化 | 替换为占位符，值移到 CI secrets | 区分开发/测试/生产环境的占位符 |
| 自动化注入 | 部署前用脚本填入真实值 | 写入后立即清除临时文件 |
3. 用户系统迁移
这个场景最复杂，因为涉及用户认证逻辑。比如从旧的 Session 系统迁到 JWT，或者从自建用户表迁到 LDAP / SSO。密码迁移只是其中一环，但往往是卡点。
我踩过最大的坑是：
- 哈希算法不兼容：旧系统用 SHA-1 + 固定 salt，新系统用 Argon2。没法直接互认。
- 双写策略：先读写写两套系统（旧 + 新），让用户首次登录时触发密码升级。
- 回滚方案：准备一个「自动降级到旧系统验证」的 fallback 机制。
我的策略：在 CI 里加一个「密码迁移模式」开关。刚切换时所有用户密码都走旧系统验证，登录成功后异步更新为新哈希。等全部活跃用户都更新了，再关掉旧系统。整个过程用户无感知。
迁移时还要注意用户元数据，比如密码重置时间、失败尝试次数、锁定状态。我曾经漏了锁定标志，结果有人用旧密码无限尝试也没被锁——安全审核直接亮了红灯。
下面这张图把三种场景的核心关系画出来了：
好了，以上三种场景基本覆盖了大多数密码迁移需求。你想想看，数据库迁移是搬砖，配置文件迁移是收拾屋子，用户系统迁移是换锁——都不难，但细节决定成败。我每次做迁移前都会推演一遍回滚方案，毕竟密码这东西，一错就是安全事故。