字段变化定义：什么是字段变化，为什么需要记录字段变化
做密码迁移审计日志这事儿，我踩过不少坑。最早我接手一个银行核心系统迁移项目，日志只记录了「改了什么」，没记「改之前是什么」。结果迁移完发现一批用户登录失败，查日志根本不知道是哪个字段出了问题。说白了，字段变化就是记录一个字段从旧值变成新值的全过程。你不仅要告诉别人「变成了啥」，还得告诉他「原来是什么」，再加上谁变的、什么时候变的、为什么变。
什么是字段变化
一个字段变化，本质上是一个数据单元的状态转移。在密码迁移场景里，字段可以是用户密码哈希值、盐值、密码策略版本号、最后修改时间等等。举个例子：
- 旧密码哈希：
5d41402abc4b2a76b9719d911017c592 - 新密码哈希：
7c222fb2927d828af22f592134e89324 - 变更时间：2025-03-01 14:23:10
- 操作人：migration_batch_03
- 变更原因：密码哈希算法升级（SHA-1 → SHA-256）
看到没？字段变化不是单个值，而是一组关联信息。我之前遇到过一个项目，只记了旧值和新值，忘了记时间戳。后来审计要查三天前的变更，日志里全是乱序的，根本没法对账。从那以后我定了个规矩：字段变化必须包含时间戳，且时间戳要精确到毫秒。
字段变化的组成要素
一个完整的字段变化记录通常包含以下要素。我习惯把它们分成三类：标识类、状态类、溯源类。下面这个表格是我自己提炼的模板，你直接拿去用：
| 分类 | 字段 | 说明 | 示例 |
|---|---|---|---|
| 标识类 | audit_id | 全局唯一审计标识 | audit_0001_20250301142310 |
| 标识类 | target_field | 发生变化的字段名 | password_hash |
| 状态类 | old_value | 变更前的字段值 | 5d41402abc4b2a76... |
| 状态类 | new_value | 变更后的字段值 | 7c222fb2927d828a... |
| 状态类 | change_timestamp | 变更发生的时间点（UTC） | 2025-03-01T14:23:10.123Z |
| 溯源类 | operator | 引起变更的主体 | migration_batch_03 |
| 溯源类 | change_reason | 变更原因（如算法升级、策略调整） | hash_algo_upgrade |
| 溯源类 | checksum | 整条记录的校验和，防篡改 | sha256(audit_id+old+new+...) |
old_value 和 new_value 里存完整的字段内容，而不是只存差异部分。你想想看，如果只存 diff，一旦 diff 逻辑出 bug，整个审计日志就废了。完整内容虽然占空间，但换来的是的可靠性。
为什么需要记录字段变化
你可能会问：不就是用户密码换个值嘛，直接写进去不就行了？记这些“祖宗八代”的信息干嘛？说实话，我当年也这么想，直到出了两次故障才彻底改观。原因其实就四点：
- 合规审计：很多行业标准（如 PCI DSS、等保三级）明确要求记录密码相关字段的变更历史。不记就是违规，一查一个准。
- 故障回溯：迁移过程一旦出问题，你要能精准定位“到底是哪条记录、哪个字段改坏了”。没有旧值，根本没法回退。
- 数据一致性校验：迁移完成后，通常要对账。字段变化日志提供了“预期值”和“实际值”的对比依据，一秒就能扫出不一致的记录。
- 反欺诈侦查：如果有人在迁移后偷偷修改密码字段，审计日志能帮你揪出异常变更。我曾经遇到一个内部篡改案例，就是靠字段变化日志里的操作人字段发现的。
核心原则：记录字段变化，本质上是在为每一次变更“拍照”。拍照要拍全貌——旧照、新照、摄影师、拍摄时间、拍摄原因，缺一不可。
字段变化在密码迁移中的典型流程
为了让你直观理解，我画了一张字段变化审计日志的生成流程。你看这张图：
从图上你可以看到，变更不是一步到位的。先读旧值，再算新值，最后才组装日志。我在实际项目里还加了一步校验：写入审计日志前，先计算整条记录的 SHA-256 校验和，和日志一起存。这样就算有人改数据库，也能立马发现。
old_value 和 new_value 存在了同一个字段里。千万别省字段！每条变化独立记录，old_value 和 new_value 必须分列存放。否则一旦迁移多次，历史就全丢了。
什么时候该记录字段变化？
不是每个字段都需要记。我建议只看三类字段：
- 密码相关字段：
password_hash、password_salt、password_update_time - 策略相关字段：
password_policy_version、hash_algorithm - 状态相关字段：
account_status（锁定/正常/待迁移）、migration_completed_flag
至于 user_name、email 这些非密码字段，我建议只在迁移范围之外记录。你想想看，审计日志要是塞太多无关数据，光存储成本就能让你哭。