不能直接 new Memento($model)，因为ThinkPHP Model不是纯数据容器，它绑定事件监听器、关联预载入、自动时间戳、软删除钩子及数据库连接实例，序列化或克隆会触发PDO不可序列化错误、__sleep返回无效值，或在restore时意外触发before_update事件导致二次写库。
ThinkPHP 里直接套用标准备忘录模式（Originator/Memento/Caretaker）基本走不通——模型层太重、事件耦合太紧、软删除和关联关系会让快照逻辑失控。真要实现数据快照与撤销，得绕开模型、隔离事件、手动控制状态粒度。
为什么不能直接 new Memento($model)？
ThinkPHP 的 Model 不是纯数据容器：它绑着事件监听器、关联预载入、自动时间戳、软删除钩子，甚至可能持有一个 $this->db 连接实例。一旦你对模型对象调用 serialize() 或尝试深拷贝，大概率触发：Serialization of 'PDO' is not allowed、__sleep() method returned invalid values，或在 restore 时意外触发 before_update 事件导致二次写库。
- 模型的
toArray()看似安全，但会漏掉未获取的关联数据、被隐藏的字段（hidden）、以及原始 SQL 查询上下文 - 用
clone $model也不行：PHP 对象克隆是浅拷贝，$model->relation这类对象引用仍共享内存，改一个就影响另一个 - 标准 Memento 模式要求 Memento 类只暴露读接口，但在 ThinkPHP 中，你很难让一个“只读快照”参与后续的
Db::table()->where()->update()操作
ThinkPHP 6.x 快照写入必须关闭模型事件
写快照不是“保存模型”，而是“把当前有效字段值落库到快照表”。这一步必须跳过模型生命周期，否则 save() 或 update() 会重新触发一堆钩子，可能把快照表本身也当成业务表去加 delete_time、校验规则、甚至写进日志。
- ThinkPHP 6.1+：用
Model::event(false)临时关闭全局事件，写完再Model::event(true) - ThinkPHP 6.0：改静态属性
Model::$event = false（注意不是实例属性） - 绝对不要在快照逻辑里调用
$user->save()、$user->together()、$user->with()—— 这些都可能间接触发事件 - 快照数据统一走
Db::table('user_snapshot')->insert($data)，字段名、类型、NULL 性必须和原表严格对齐，否则后期JOIN查 diff 会出隐式转换
撤销恢复不能靠 restoreState()，得走业务 SQL 回滚
PHP 层的对象状态恢复（比如 $editor->restoreFromMemento($m)）在 Web 请求生命周期里意义有限：HTTP 是无状态的，用户点击“撤销”时，原始对象早就销毁了。真正的撤销，是数据库层面按快照 ID 把字段值刷回去。
立即学习“PHP免费学习笔记（深入）”；
- 撤销操作本质是：查出某条快照记录 → 构造
UPDATE user SET status = ?, updated_at = ? WHERE id = ?→ 执行 - 别试图把快照表里的整行反序列化成 Model 再
save()：又绕回事件陷阱，且无法控制更新哪些字段（比如你不该覆盖create_time） - 如果业务要求“仅还原部分字段”，快照表建议拆成 JSON 字段（如
diff_data），存变更过的键值对，而不是全量镜像 - 软删除字段
delete_time千万别加到快照表里——历史记录不该被“软删”，加了反而让查询逻辑变复杂
多级撤销要用 SplStack + 时间戳索引，别堆 Model 实例
想支持“Ctrl+Z 多步回退”？别把一堆 UserModel 实例塞进数组栈里。它们带连接、带事件、占内存，且 PHP 请求结束就销毁，根本没法跨请求复用。
- 用
SplStack存纯数组快照，例如：['id' => 123, 'status' => 'draft', 'updated_at' => '2026-04-30 18:22:01'] - 每次编辑前
$stack->push($this->captureCurrentState())，其中captureCurrentState()只取getDirty()或白名单字段，不碰关联、不调toArray() - 栈长度设硬上限（如 50），超限时用
$stack->shift()踢掉最早一条，防内存泄漏 - 真实生产环境的“多级撤销”往往需要持久化到 Redis 或数据库，此时快照记录必须带
user_id、session_id、created_at，否则不同用户操作会串
最易被忽略的一点：快照不是为“技术完整性”服务的，而是为“业务可追溯性”服务的。字段要不要进快照，不看它是不是 public，而看它是否参与核心业务决策——比如订单的 pay_status 必须记，但 view_count 就没必要。写快照时少想“怎么像设计模式”，多想“DBA 查这条记录时能不能一眼看出当时发生了什么”。
