ThinkPHP没有内置撤销机制，“取消”需业务层自定义补偿逻辑；Model::delete()仅删数据，不还原状态或外部副作用；真取消须用Db::transaction()包裹正向操作与幂等逆向补偿，并避免依赖事件钩子或软删除。
ThinkPHP 没有内置“取消操作”或“撤销事件”的机制，所谓“取消”，本质是业务逻辑层面的补偿动作，不是框架自动提供的功能。你得自己定义什么算“取消”，再写对应的回退逻辑。
为什么 Model::delete() 不等于“取消”
很多人以为调用 delete() 就是把刚做的操作“撤回去”，其实不是：
– 它只是删数据，不还原状态、不恢复关联资源、不通知第三方；
– 如果之前发了短信、扣了余额、生成了订单号，这些都不会被自动抹掉；
– delete() 是单向物理操作，没有上下文快照，也没法反向推导“原来值是什么”。
用 Db::transaction() 包住“操作 + 补偿”才叫真取消
真正可控的取消，必须显式构造“正向操作”和“逆向补偿”两个步骤，并放在同一事务里：
– 正向：比如创建订单、扣库存、写日志；
– 逆向：比如恢复库存、标记订单为已取消、删日志（或改状态）；
– 两者必须在 Db::transaction() 闭包中完成，且逆向逻辑要能捕获异常并主动执行。
- 别依赖
try-catch后只rollback()：它只能回滚数据库，不能撤回 Redis 缓存、HTTP 请求、文件写入等外部副作用 - 补偿逻辑要幂等：同一笔取消请求可能重试，
update ... set status = 'canceled'比status = status - 1更安全 - 如果正向操作已提交（比如异步发消息），取消就只能走“通知下游作废”，而不是本地回滚
软删除字段不是“取消开关”，只是状态标记
soft_delete 配置启用后，delete() 只是更新 delete_time 字段，不是撤销——它连数据库行都没删，更谈不上业务语义上的“取消”。
立即学习“PHP免费学习笔记（深入）”；
- 用户看到“已取消订单”，其实是查
where delete_time is null的结果，不是系统真的倒带了 - 如果你靠
forceDelete()来“彻底取消”，那只是把软删变硬删，反而让后续审计、对账更困难 - 真正需要取消时，应该加一个
cancel_reason字段和cancel_at时间戳，保留完整链路
事件钩子（deleting/deleted）不适合做取消逻辑
deleting/deleted）不适合做取消逻辑这些钩子是被动响应，不是控制流开关。你在 deleting 里 throw Exception 并不能阻止删除发生（PDO 已发语句），只会让事务失败——但失败 ≠ 取消，尤其当事务外还有其他操作时。
- 想拦截删除，得在控制器或服务层提前判断：
if ($order->status !== 'pending') throw new Exception('不可取消') -
deleting适合做清理（如删附件），不适合做决策（如“该不该删”） - 事件里调用
Db::rollback()是危险操作：它会破坏当前事务边界，尤其在嵌套事务或命令行任务中容易误伤
实际取消动作永远要落在具体业务场景里：订单取消、退款回调、工单撤回……每个都需要独立设计补偿路径，没有通用方案。别指望框架替你记住“刚才做了什么”。
