ThinkPHP 8.0软删除恢复需先用onlyTrashed()获取实例再调restore()；binlog回滚禁用--database参数，须用position或datetime精准定位；binlog2sql -B仅支持ROW格式且需FULL row_image；关联软删数据须手动恢复。
ThinkPHP 8.0 软删除恢复失败，先查 onlyTrashed() 是否真能查到记录
很多人一删就慌，直接写 UserModel::where('id', 123)->restore()，结果报错“Call to undefined method”——restore() 是实例方法，不是静态查询构造器支持的方法。必须先用 onlyTrashed() 显式拉出软删状态的模型实例。
常见错误现象：
-
UserModel::where('id', 123)->onlyTrashed()->find()返回 null：因为onlyTrashed()必须放在链式调用最前端，否则被忽略 -
UserModel::onlyTrashed()->find(123)返回 null：说明该记录根本没进软删（可能已被物理删、字段非 NULL、或$deleteTime配错） -
$user->restore()返回false却无提示：静默失败，不抛异常，需手动判断返回值
实操建议：
- 确认模型启用
use SoftDelete;，且声明protected $deleteTime = 'delete_time';（字段名必须与数据库一致） - 检查数据库字段类型：
delete_time DATETIME NULL，不能带DEFAULT CURRENT_TIMESTAMP或NOT NULL - 执行前加判断：
$user = UserModel::onlyTrashed()->find(123); if ($user && false === $user->restore()) { /* 记录日志并中止 */ }
Binlog 回滚恢复时，--database 参数会丢事务，别用
在 MySQL 命令行里执行 mysqlbinlog --database=xxx 恢复单库数据，控制台立刻弹出警告：WARNING: The option --database has been used. It may filter parts of transactions——这不是提醒，是明确告诉你：这个参数会让跨库事务断裂，INSERT 和 DELETE 可能被拆开，导致回放后数据错乱。
立即学习“PHP免费学习笔记（深入）”；
真实影响：
- 一个事务里先改
user表再改order表，--database=user会只取前半段，后半段被过滤掉 - GTID 仍保留，但事件不完整，
binlog2sql解析后生成的反向 SQL 缺关键行 - 即使你只操作一个库，只要 binlog 中存在其他库的 DDL（如
CREATE TEMPORARY TABLE），--database就可能误判并截断
实操建议：
- 放弃
--database，改用--start-position和--stop-position精确框定事务边界（从# at 12345到下一个# at前） - 若时间更可控，用
--start-datetime/--stop-datetime，但务必配合mysqlbinlog --base64-output=DECODE-ROWS -v看清实际事件范围 - 解析输出后，人工 grep
### DELETE FROM `user`，确认整块事务（含 BEGIN/COMMIT）完整落入选区
binlog2sql 生成回滚语句必须加 -B，且只对 ROW 格式有效
binlog2sql 不是万能翻译器，它依赖 binlog 的格式和内容完整性。如果你的 MySQL 是 STATEMENT 或 MIXED 格式，运行 python binlog2sql.py ... -B 很可能输出空或语法错误的 INSERT——因为 STATEMENT 不记录行变更细节，binlog2sql 没法还原原始值。
关键限制：
-
-B参数表示 “generate rollback SQL”，但它只解析ROW格式中的### INSERT INTO/### DELETE FROM/### UPDATE块，每行带### SET字段值 - 如果 binlog 中该事务缺失前镜像（比如
binlog_row_image=MINIMAL），DELETE无法转成INSERT，binlog2sql直接跳过该事件 - DDL 操作（
DROP TABLE,TRUNCATE）永远不支持回滚，binlog2sql -B对它们无输出
实操建议：
- 恢复前先验证：
SHOW VARIABLES LIKE 'binlog_format';必须为ROW，SHOW VARIABLES LIKE 'binlog_row_image';必须为FULL - 命令示例：
python binlog2sql.py -h127.0.0.1 -P3306 -uadmin -p'xxx' -dtest -tt1 --start-file='binlog.000012' --start-pos=12345 --stop-pos=12999 -B - 生成的 SQL 务必先导入测试库验证：检查主键冲突、字段类型、NULL 约束是否兼容，别直接上生产
软删除恢复不级联，关联表得手动处理
ThinkPHP 的 $user->restore() 只清 user 表的 delete_time，订单、地址、日志这些哪怕也启用了 SoftDelete，也不会自动跟着恢复——框架没提供级联开关，这是设计使然，不是 bug。
容易踩的坑：
- 用
$user->with(['orders'])->restore()：无效。with()默认过滤软删记录，$user->orders查不到任何数据 - 在
restored事件里直接调$this->orders()->restore()：失败，因为orders()关联查询默认不含软删数据，需显式加onlyTrashed() - 批量恢复时用
UserModel::onlyTrashed()->chunk(...)，但忘了对每个用户单独查其软删订单
实操建议：
- 恢复主模型后，立即查其软删关联：
$user->orders()->onlyTrashed()->select()，再遍历调$order->restore() - 量大时改用 Db 直写：
Db::name('order')->where('user_id', $user->id)->whereNotNull('delete_time')->update(['delete_time' => null])，但跳过事件 - 若需事件，把关联恢复逻辑放进
afterRestore钩子，并确保钩子里用$this->orders()->onlyTrashed()而不是$this->orders()
恢复动作本身不难，难的是判断哪一层出了问题：是软删字段配置错了？还是 binlog 格式不支持反向生成？又或者你以为的“事务完整”其实被 --database 截断了。每一步都得有验证点，不能靠直觉推进。
