回滚依赖结构化操作日志与幂等还原逻辑，而非简单撤销；需事务内双写业务变更与日志，按operation_type策略执行反向操作，并保障权限隔离与索引优化。
回滚不是靠“撤销按钮”，而是靠操作日志+幂等还原逻辑
PHP 本身没有内置的“操作回滚”机制，$_SESSION 或数据库事务只能管住当前请求或单次数据库写入，无法覆盖用户点击“删除订单”“修改价格”“批量启用会员”这类业务动作。真要支持一键撤销，必须在执行操作时同步记录可逆的动作快照，并确保每个动作能被原样重放或反向执行。
常见错误是只记 log_message 文本日志（比如“张三把商品A价格改成59.9”），这种日志人类可读，但机器没法自动还原——你没法从字符串里解析出旧价格、商品ID、操作前状态。真正可用的日志得是结构化数据，包含：操作类型、目标资源 ID、关键字段变更前后值、执行人、时间戳。
- 用
json_encode()存变更明细，别存自然语言描述 - 每条日志必须带
operation_type（如"update_product_price"）、resource_id（如"prod_123"）、before和after数组 - 避免记录敏感字段（如密码、手机号），日志表加
is_sensitive标记位方便脱敏查询
用数据库事务 + 操作日志双写保障一致性
很多人以为只要把日志写进数据库就安全了，但没考虑事务失败时日志已落盘、业务未生效的情况——这会导致“有日志无变更”，一按撤销就报错找不到原始状态。正确做法是把业务变更和日志插入放在同一个 PDO::beginTransaction() 里，且日志表必须和业务表同库同引擎（InnoDB）。
典型场景：管理员后台修改用户等级。不能先改 users.level 再 insert 日志；也不能用异步队列写日志（可能丢消息）。必须：
立即学习“PHP免费学习笔记（深入）”；
- 开启事务：
$pdo->beginTransaction() - 更新用户表：
$stmt->execute(['level' => 5, 'id' => 888]) - 插入日志：
$logStmt->execute(['op_type' => 'update_user_level', 'resource_id' => 888, 'before' => '{"level":3}', 'after' => '{"level":5}', ...]) - 统一
commit()或rollback()
漏掉任何一步，都可能让日志和实际状态脱节。MySQL 8.0+ 可用 SAVEPOINT 做更细粒度控制，但对大多数业务，简单事务已够用。
撤销操作本质是“反向执行”，不是删日志
用户点“撤销”，系统不是把那条日志删掉，而是根据 operation_type 查到对应还原函数，把 before 值重新写回去。比如 update_product_price 的还原逻辑就是把 price 设为日志里的 before.price 值。
容易踩的坑是硬编码还原逻辑，导致新增操作类型时忘记补撤销分支。推荐用策略模式注册处理器：
return [
'update_product_price' => function ($log) {
$stmt = $pdo->prepare('UPDATE products SET price = ? WHERE id = ?');
$stmt->execute([$log['before']['price'], $log['resource_id']]);
},
'delete_order' => function ($log) {
// 把 deleted_at 设为 NULL，而不是 INSERT 回原表
$stmt = $pdo->prepare('UPDATE orders SET deleted_at = NULL WHERE id = ?');
$stmt->execute([$log['resource_id']]);
}
];
注意：删除类操作不建议物理删，一律软删（加 deleted_at 字段），否则撤销时无法恢复关联数据（如订单商品、支付记录）。如果真用了物理删，撤销就得依赖备份表或 binlog 回滚——这已超出 PHP 应用层能力范围。
性能与权限边界比功能本身更关键
日志表会随操作量线性增长，不做限制很快变慢。别等查不动了才加索引——resource_id、operation_type、created_at 这三个字段必须联合索引，且按查询频次排序（比如按用户查操作历史，resource_id 就该放最左）。
另一个常被忽略的是权限隔离：用户 A 的操作日志，用户 B 不该看到，更不该能撤销。所以每次撤销前必须校验：log.user_id === current_user_id 或 current_user.hasPermission('undo_any')。别图省事在前端隐藏“撤销”按钮——后端接口照样能被绕过调用。
复杂点在于跨服务操作（比如 PHP 调用 Python 计算服务后更新结果），这时日志得包含外部系统返回的 trace_id，方便定位和协同回滚。单体应用可以靠事务兜底，微服务下就得靠 Saga 模式或补偿事务，PHP 层只负责记录和触发，不保证原子性。
