bridge-timeout-layering-simulation

1. 实验目标

用纯 Java CLI 仿真「桥接调用超时分层」（对应 docs/05-bridge-hybrid/11）：

• 把超时拆成四件不同的事：运输层就绪等待 / 单次 RPC 超时 / 用户操作 UI 超时 / HTTP 读超时
• 演示 waitForBridge 超时仍 resolve（绝不卡死页面）
• 演示「用户操作类通道」（支付、选图）必须关闭 Web 侧计时，否则会把「用户正在操作」误判成失败

2. 工程要点

• 四层超时语义数值上不可合并：它们驱动不同行为
• 每通道独立超时表：弱网慢操作（上传）给长超时；用户操作通道关闭 Web 侧计时
• 阶梯冷却 backoff：[1s, 2s, 4s]

3. 关键实现速览

// 四层超时语义（数值不可合并）
static final long TRANSPORT_READY_MS = 3000;        // waitForBridge：超时仍 resolve，防卡死
static final long SINGLE_RPC_MS = 15000;            // 单次 RPC 默认
static final long USER_OP_DISABLE_WEB_TIMER = -1;   // 依赖用户操作：Web 侧不计时
static final long HTTP_READ_MS = 120000;            // 上传等多图弱网慢操作

// 用户操作通道关闭 Web 侧计时
static Map<String, Long> channelTimeout = Map.of(
    "getDeviceInfo", SINGLE_RPC_MS,
    "requestPayment", USER_OP_DISABLE_WEB_TIMER,
    "openGallery", USER_OP_DISABLE_WEB_TIMER,
    "appUploadOss", HTTP_READ_MS);

为什么看这段：超时不是「一个数」。transport-ready、单次 RPC、用户操作 UI、HTTP 读是四件事，必须分别建模，否则要么误杀正常操作，要么卡死页面。

4. 运行方式

cd labs/java/bridge-hybrid/bridge-timeout-layering-simulation
javac -d out src/BridgeTimeoutLayeringSimulation.java
java -cp out BridgeTimeoutLayeringSimulation

5. 预期控制台输出

=== 四层超时分离 ===
  TRANSPORT_READY(waitForBridge) = 3000ms，超时仍 resolve（防卡死页面）
  SINGLE_RPC 默认 = 15000ms
  USER_OP 通道：Web 侧关闭计时（requestPayment/openGallery）
  HTTP_READ(appUploadOss) = 120000ms（多图压缩+OSS 弱网慢）
=== 场景1：waitForBridge 超时仍 resolve ===
  桥未就绪，但 waitForBridge 返回: resolved=true（页面继续跑，不因桥缺失卡死）
=== 场景2：用户操作通道关闭 Web 侧计时 ===
  requestPayment Web 侧计时=关闭（等用户操作/Native 关页）
  若 Web 侧强行计时 15s：用户正在选支付方式 → 15s 到点误判失败 ❌
  正确：Web 侧不计时，由 Native 界面关闭事件结束 ✅
=== 场景3：阶梯冷却 backoff ===
  重试冷却 1000ms
  重试冷却 2000ms
  重试冷却 4000ms
=== 结论 ===
  · 运输层就绪 / 单次 RPC / 用户操作 UI / HTTP 读超时 是四件事，必须分层建模
  · 用户操作通道禁用 Web 侧计时，否则会把『用户正在操作』误判成超时失败

6. 常见误区

误区	实际情况
桥调用给一个全局 15s 超时就行	会误杀用户操作（支付/选图依赖人操作时长）与弱网慢上传
waitForBridge 超时应该 reject 报错	超时仍要 resolve，否则桥未就绪时整个 H5 页面卡死
重试间隔固定就好	固定间隔在弱网会雪崩；用阶梯 backoff 退让

7. 对应知识库文档

• 理论主文档：桥接调用超时分层与就绪竞态

8. 完整源码

• BridgeTimeoutLayeringSimulation.java