创建、授权、执行
订单、取消、设置和提款都运行相同的流水线。创建
你发送交易场所、账户、操作类型及其参数。后端返回一个步骤数组。一次调用可能返回多个步骤：例如在下单前提高杠杆，会依次返回两个步骤。
授权
每个步骤恰好携带一个授权载荷，具体由该步骤的签名方式决定：可以由用户的钱包签署，也可以由 SDK 用它为该账户持有的凭证签署。
执行
已签名的步骤被送回，响应中每个步骤对应一条结果。成功时携带交易场所的标识符；失败时携带一个错误，通常还带有结构化的错误码。
最后一种是这个模式的例外。会话步骤永远不会进入执行阶段，因为插件会直接完成它。
谁来签名
每个操作都会声明由谁授权，答案只有两种。 用户授权任何授予某项能力或转出资金的操作：批准代理、存款、登录，以及部分交易场所上的提款。这些会调用钱包。 SDK 使用它为该账户在该交易场所持有的凭证来授权交易。这就是为什么下单流程不会弹出钱包——凭证是在设置阶段由用户的一次操作授予的。 有些操作会同时列出两者，因为协议需要双方各自贡献一部分。高层交易方法会自动处理由 SDK 签名的那一半，无需你手动请求；设置流程也是由单次调用端到端统一协调的，而不需要你为每个交易场所的方案分别编写脚本。凭证存放在哪里
每个交易场所的插件通过一个存储适配器持久化各自的交易凭证，该适配器是可替换的。 默认实现面向浏览器。值在写入本地存储前会被加密，而用于加密的密钥则作为一个不可导出的句柄保存在浏览器自身的密钥库中，而不是页面可以读回的一个值。如果运行环境缺少这两种能力中的任意一种，会回退到一个不持久化的会话，而不是以明文写出凭证。可以为某个交易场所的存储传入你自己的适配器，将凭证保存在别处。这是服务端或原生集成的推荐做法，此时浏览器的默认实现并不适用。
推送数据
行情和账户更新通过直接建立到交易场所本身（而非经过代理）的 WebSocket 连接送达。你为每个交易场所注册一个推送提供方，订阅会返回一个用于取消订阅的函数。 同一通道上的多个监听者共享同一条底层连接，因此各组件可以各自独立订阅，而不必每次都新开一条连接。每个交易场所底层都有自己的原生协议和速率限制，由插件将其映射到统一的通道名称上。失败处理
结果按步骤逐一返回，这意味着一个多步骤操作可能部分成功。例如在下单前先调整杠杆，可能出现杠杆调整已生效但订单被拒绝的情况；如果把整次调用当作整体失败处理，就会误报这一结果。 应该以结构化错误码作为分支判断的依据。插件也可能在结果传递给你之前就先做出反应，这也是为什么一个已被交易场所停止接受的凭证会在本地被自动清除，而不是导致后续每一笔订单都以相同方式失败。后续步骤
交易场所
每个交易场所如何实现设置、签名和提款。
快速开始
以上流水线对应的实际代码。
错误码
完整的错误码列表及其含义。
方法参考
每个方法的参数和返回结构。