第 21 章把「时间」本身当作游戏机制。玩家发起远征后立刻扣除体力与门票、锁定小队，两小时后由延迟任务触发结算，中途还可能弹出限时十分钟的分支事件。这套玩法对服务端提出的要求极其直白：任务不能丢、结算不能重复发奖、失败必须能对账修复。它几乎是分布式事务课的最小可运行切片，却长着一张游戏的脸。
本章定位
- 全集位置：第 21 章，属「异步与经济」层，是第 18 章城市经营的结算能力抽象化版本。
- 难度梯度：进阶。玩法极简，工程约束密集，是理解幂等与对账的最佳样本。
- 前置章节：第 10 章城格建造 mini-SLG（异步玩法基础），并可回看第 18 章城市经营的定时作业设计。
- 后续衔接：第 22 章公会建设的捐献与建造计时、第 23 章跨服战的奖励回流与最终一致性，都复用本章的结算账本思路。
核心验证目标
- 可靠延迟触发：支持 10 秒至 72 小时的 TTL，服务重启不丢任务，顺序可弱化但至少投递一次。
- 幂等结算：结算接口任意次重复调用都不重复发放，对经济系统的写入采用去重写模型。
- 可重试与对账：失败走退避重试，结算事件落入结算账本，支持离线对账修复账实差异。
- 远征状态机：草稿、进行中、待决策、到期、结算中、已结算、补偿中等状态清晰流转，补偿态由人工或自动修复收敛到已结算。
- 中途事件与分支：远征途中可插入限时分支决策，玩家选择或超时走默认分支，两条路径都必须进入同一结算账本。
- 全链路可观测：每个远征携带 trace_id，暴露延迟分布、重试率、重复投递率、幂等拦截率与账实差异五类指标。
技术栈建议
| 层次 | 推荐选型 | 说明 |
|---|---|---|
| 服务端 | Go、Java（Quarkus 或 Spring）或 Rust | 远征域与结算域解耦部署 |
| 调度 | 延迟队列 | Redis、Kafka、RabbitMQ、Quartz 或 Chronos 任一 |
| 协议 | HTTP 加 WebSocket | HTTP 发起与查询，WebSocket 推送进度 |
| 对账 | 事件总线加账本 | 两域通过事件总线对账，账本记录幂等键与增量 |
| 观测 | 分布式追踪加指标 | 以 trace_id 串联远征全生命周期 |
本章文章
| 文章 | 核心内容 |
|---|---|
| 在线联机原型全集：第 21 章 异步远征（Async Expedition）——延迟任务 / 幂等结算原型 | 延迟任务调度、可重试与去重、一次提交多端回执、最终一致性与幂等结算、远征状态机与结算账本 |
与相邻章节的关系
- 上一章：第 20 章 社交大厅 提供统一身份与入口，本章的远征单挂在同一账号体系下。
- 下一章：第 22 章 公会建设 把个人远征扩展为公会级的协作任务与捐献循环。
- 经济三环：与 第 18 章 城市经营、第 25 章 市场系统 共同覆盖生产、结算与流通三个环节。