thinkphp模型字段修改需手动实现历史版本记录，因原生不支持字段级快照；必须先find()查原始数据再比对变更字段，历史表应按字段拆行存储并建立联合索引提升查询效率。
ThinkPHP 模型字段修改如何自动记录历史版本
不能靠模型事件自动完成，必须手动干预保存逻辑。ThinkPHP 原生不提供字段级历史快照功能，save() 或 update() 本身不会触发旧值捕获，得在写入前主动读一次原始数据。
- 先用
find()查出当前数据库中的完整记录（注意：必须是主键查询，避免条件查询导致数据不一致） - 对比要修改的字段，只对变化的字段生成历史条目，别把没动过的字段也记一遍
- 历史表建议单独建，字段至少包含：
model_name、record_id、field_name、old_value、new_value、operator_id、created_at - 别在
beforeUpdate钩子里做全量历史记录——钩子拿不到原始值，除非你提前缓存或二次查库
用 getChangedData() 获取变更字段时的陷阱
这个方法看似省事，但只在模型使用 data() + isUpdate(true) 方式更新时才有效；直接传数组给 save() 或调用 allowField() 后的更新，getChangedData() 返回空数组。
- 必须确保模型已加载原数据（比如先
find()再data()->save()），否则getChangedData()没有参照物 -
getChangedData()不识别 JSON 字段的内部变化，比如config是 JSON 类型，改了里面一个 key，它仍认为整个字段“未变” - 如果用了
where()->update()这种静态方法，模型实例根本没参与，getChangedData()完全不可用
历史表怎么设计才能兼顾查询和写入效率
字段历史不是日志，不能堆成大文本 blob。按字段拆行（一行一字段变更）比一行存全部 JSON 更可控，也方便后续按 field_name 聚合统计。
-
old_value和new_value建议用text类型，别用varchar(255)——长文本、序列化内容、HTML 片段都可能超长 - 联合索引必须有：
(model_name, record_id, field_name, created_at)，否则按业务查某条记录的某个字段变更史会慢 - 不要给历史表加外键约束——高并发写入时锁表风险大，一致性靠代码逻辑保障更实际
- 定期归档老数据，比如保留 180 天，用
DELETE FROM history_table WHERE created_at ，别依赖 MySQL 分区
事务里写历史记录失败会导致主操作回滚吗
会，但前提是历史写入和主更新在同一个事务里。ThinkPHP 默认不开启事务，必须显式用 Db::transaction() 包裹。
- 主更新成功、历史写入失败 → 整个事务回滚，数据状态一致，这是理想情况
- 但如果历史表写入用的是另一个数据库连接（比如日志库分离），或用了异步队列，则无法保证原子性，得接受“主成功、历史丢”的可能性
- 线上环境建议加兜底：历史写入失败时，至少把变更摘要写进本地文件或 Redis，避免完全无痕
最麻烦的其实是嵌套更新场景——比如一个订单模型更新时连带更新多个关联模型，每个都要留痕，字段来源分散，这时候靠单一模型钩子根本不够用，得在 Service 层统一收口处理。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
