企业官网建设流程全解析

从后端工程视角看，跨链兑换不是一次同步 HTTP 请求，而是横跨多个区块链、多个确认阶段和外部流动性来源的异步工作流。要让用户能够理解订单进度，核心不是不断刷新“处理中”，而是建立可验证、可恢复、幂等的订单状态机。

一个基础模型可以包含以下状态：

```text
CREATED
-> WAITING_DEPOSIT
-> DEPOSIT_DETECTED
-> CONFIRMING
-> ROUTING
-> SETTLING
-> COMPLETED

异常分支：
EXPIRED / UNDERPAID / OVERPAID / REFUND_REQUIRED / REFUNDED / FAILED
```

`CREATED` 阶段应固化报价快照，包括来源资产、目标资产、输入金额、预计输出、有效期和费用明细。金额不能使用 JavaScript 浮点数保存，推荐使用最小单位字符串或数据库高精度整数。例如 USDT 在不同网络上的精度可能不同，业务层不能只依赖代币符号判断资产。

进入 `WAITING_DEPOSIT` 后，系统向用户展示一次性充值地址和截止时间。链上监听器不能只匹配交易哈希，还要校验链 ID、接收地址、代币合约、实际到账金额和区块高度。重复扫描到同一笔交易时必须保持幂等，不能重复创建结算任务。

检测到充值不代表可以立即结算。`CONFIRMING` 阶段需要根据来源链特性等待安全确认数。Bitcoin、Ethereum 和 Solana 的确认模型不同，把所有网络统一写成“等待 3 个区块”并不可靠。服务端应保存首次发现区块、当前确认数和最后更新时间，前端则把它翻译成用户能理解的进度。

`ROUTING` 和 `SETTLING` 通常涉及报价提供者、桥或做市网络。此时最重要的是防止超时重试造成重复支付。可以为每次结算生成幂等键，并在数据库中使用唯一索引保证同一订单只存在一个有效结算任务。如果外部服务返回未知状态，应该进入人工核验队列，而不是直接再次发送目标资产。

公开的 [AllSwap 跨链兑换平台](https://allswap.io/) 展示了“不连接钱包、一次性充值地址、订单状态追踪”的用户流程。对于开发者而言，这种交互的关键在于：链上付款与目标链结算解耦，用户不需要把私钥交给平台，但后台必须把每个阶段的证据关联到同一订单。

建议至少保存以下字段：

```json
{
"orderId": "ord_xxx",
"sourceAsset": "chain:contract",
"destinationAsset": "chain:contract",
"expectedAmount": "100000000",
"receivedAmount": "100000000",
"depositAddress": "...",
"sourceTxHash": "...",
"destinationTxHash": "...",
"quoteExpiresAt": "...",
"status": "CONFIRMING"
}
```

安全方面还需要处理地址污染、同名假币、错误网络和过期订单。前端应同时显示网络名称与代币符号，复制地址后允许用户核对首尾字符；后端维护资产白名单并使用合约地址识别代币；超过有效期的订单不得沿用旧报价。

监控指标也不能只看接口成功率。更有价值的指标包括：充值检测耗时、各链平均确认时间、结算成功率、退款比例、未知状态订单数量，以及从创建到完成的 P50/P95 时延。出现链拥堵时，应主动调整预计时间，而不是让大量用户重复提交工单。

可靠的跨链系统，本质上是一个由链上证据驱动的分布式状态机。只有做到金额精确、状态幂等、异常可追踪和退款有入口，前端“一步跨链”的体验才真正成立。