同图传送安全等待

同图（无缝）传送的收尾条件从「等待超过 15 秒就当作完成」改成「落点地面真的能站人」。 改造后客户端不再设安全等待的退出上限，改为每 100 秒打一次红色告警； 异常分支只记录日志，不再把玩家退回登录——原来的失败恢复整段已删除。 本页说明新顺序、告警口径、卡住时会发生什么、没被改动的部分，以及这次改造踩到的框架事实。

1. 为什么要改：15 秒兜底是「伪成功」

原实现里 TeleportSelfFallbackTimeoutMs = 15000 是「收到 15512 起，到同关卡传送完成」的整体兜底。 它到点做三件事：强制结束等待、上报当前版本的 LoadDone、清理移动锁与遮罩。 问题出在第一件事和第二件事的组合上。

2. 新的收尾顺序

顺序集中在 TeleportSameSceneFlow.StartLevelStreamingFromSnapshot 的结果回调里。 每一步之间都插了 FlowGeneration（流程代次）复查，任一步发现代次变了（被新请求或 Clear() 作废）就立刻退出，不再往下推进。

整段包在 try / catch 里：回调里抛异常只打一条 传送-安全完成处理异常，不会把流程推进到别的状态。

3. 安全等待：不设上限，只打告警

3.1 两个常量

3.2 告警里带什么

告警只有一条，但一行里带 7 个诊断字段，目的是一眼看出卡在哪一段：

Log.Error(ELogModule.Debug, ELogAuthor.ZZB,
    '传送-安全等待超时告警（不设客户端上限，仅告警不退出）',
    ['已等待毫秒', ...],        // 累计已等待时长
    ['安全等待中', ...],        // IsWaitingForSafety
    ['地形流送中', ...],        // IsStreamingLevel
    ['等相机朝向', ...],        // WaitingForCameraDirAfterTeleport
    ['执行器状态', ...],        // ActiveExecutor.State（None 表示执行器已摘除）
    ['ServerMove监听中', ...],  // 是否还在等 15512 对应的移动应用
    ['普通场景加载中', ...]);     // GameModeModel.IsLoadingAnyScene

3.3 地面没就绪时先单独报一条

WaitForGroundReady 首次 3×3 检查没通过时，先打一条 Log.Error 再进入 50ms 轮询—— 这样既不会让重试把日志刷爆，又能一眼看到卡在地面这一段：

Log.Error(ELogModule.Debug, ELogAuthor.ZZB,
    '传送-找不到合适的地面，九点探地未通过，继续等待',
    ['targetX', ...], ['targetY', ...], ['targetZ', ...]);

带出来的是服务器下发的目标坐标。配合 §7.1 的两个条件， 可以区分「地形还在加载」（再等就会好）和「这个落点本来就过不了」（等多久都一样）。

4. 卡住与异常：只记录，不退登

这次改造同时把失败退登整段删掉了：原来的 RecoverFromLoadingFailure、失败遮罩 TeleportSafetyFailure、IsRecoveringFromFailure 门面拦截和 BackLoginView 都不再存在。 所有异常分支现在的动作都只有一件事——打日志，然后让等待维持原样：

4.1 谁来解除等待

等待并非无人接管，出口只有三个：

1. 新请求接管：收到新的 15512 时先 CancelCurrentRequest()——FlowGeneration += 1、摘本地移动监听、停安全等待告警、停 LoadDone 重试、停地面轮询、CommandBail() 掉执行器、EndActiveCache('Cancel')，然后进入新的等待。代次 +1 放在最前面，是为了让在途的旧异步回调全部作废。
2. 交接给别人：跨图（IsLoadingAnyScene）、复活（SERVER_MOVE_REASON_REVIVE）、执行器 Bail 三种情况走 HandoverCurrentRequest——取消本次并解移动锁、关无缝遮罩，把请求交回对应链路。
3. 流程清理：Clear() 走同一套取消，再清空字段。

4.2 安全等待期间被拦住的调用

IsSafetyWaitPending（就是 IsWaitingForSafety 的 getter）只做一件事： 挡住「安全还没确认就抢先动」的调用，共 8 处——门面 3 处、过场编排 4 处、V2 流程 1 处：

这些 guard 只挡调用、不改状态；真正的收尾始终只由 §2 的顺序里那个「安全条件就绪」回调完成。

5. 这次没动的部分

6. 关键发现：命令超时不是兜底

改造过程中一度打算「把客户端上限去掉，反正 SceneWrapCommand 自己有 90 秒超时能兜底」。 读代码后这条路被否掉了，记在这里免得下次再想一遍：

// CommandExecutor.Init 的两个收尾参数默认都是 false
public Init(context, name = '', logDetail = false,
    expireTime = CommandExecutorConstants.DefaultExpireTime,
    rollbackOnTimeout = false,
    triggerCallbackOnTimeout = false): boolean

// 场景加载侧建链时只传了前四个参数
executor.Init(context, 'SceneWrapCommand', true, TimerSystemConstants.MaxTime);

同一份事实在 场景加载命令链里已经记过一次： 链上所有 executor 都等于没有超时兜底，任何新加的等待节点必须自带放行条件。

7. 已知代价与待验证项

7.1 地面判据本身的风险（已知，未修复）

九点探地既然是唯一的完成条件，它自己也可能对某些落点永远给不出结果。两个成因：

1. 探的是服务器下发的目标坐标，不是角色实际位置。角色被落地修正挪走以后，检测还在查原来那点， 而每一根射线只向下探 GroundReadyTraceVerticalDist = 200——原坐标与角色实际高度的落差超过这个值就永远打不到。
2. 九点采样跨 ±132cm。GroundReadyTraceHorizontalDist = 132，外围八点落在窄平台 / 斜坡边缘之外时， 那几个位置本来就没有地面，射线再等也不会通过。

结果是：这类落点会一路重试到玩家自己重登。目前不改判据，只在首次未通过时打一条 §3.3 的 传送-找不到合适的地面（带目标坐标），便于先收集实际发生的落点样本。 这条风险在 §8 里也留了排查入口。

8. 排查速查