委托单缓存
一些交易所没有查询完结委托单或者所有委托单的方法，它们只提供了
fetchOpenOrders访问端结点，有时也会大方地提供fetchOrder端结点。
这意味着它们没有提供查询委托单历史的方法。ccxt库将尝试模拟委托单历史，
方法是使用交易所对象的.orders属性来记录所有的委托单。
任何时候当用户创建一个新的委托单，或者取消一个已有的敞口委托单，或者
进行了其他可能修改委托单状态的操作，ccxt库就会在缓存中记录整个委托单
信息。在后续的对fetchOrder, fetchOrders或 fetchClosedOrders方法
调用时，交易所实例会发送一个对fetchOpenOrders的请求，然后对比当前获取
的敞口委托单和之前缓存的委托单。ccxt库检查每个缓存的委托单，然后尝试
匹配对应的获取到的敞口委托单。当缓存的委托单不在获取到的敞口委托单中
时，ccxt库会将这个缓存的委托单标记为已完结。对fetchOrder, fetchOrders, fetchClosedOrders
的调用将返回.orders缓存中更新过的委托单。
这个逻辑简单点说就是：如果一个缓存的委托单没有在获取到的敞口委托单中出现， 那么它就不再是敞口单了，因此，就是完结单。
大多数情况下，.orders缓存的工作对用户而言是透明的。更常见的是交易所
本身提供了足够的方法。然而，由于某些交易所没有提供完整的API，.orders
缓存有以下已知的局限性：
- 如果用户没有在程序运行之间保存
.orders缓存，而且也没有在重新运行时 进行恢复，那么.orders缓存就会丢失。因此在下一次运行程序时对fetchClosedOrders的调用，交易所实例将返回一个空的委托单列表。 没有正确的恢复缓存，交易所没有办法了解委托单是完结还是取消。 - 如果API密钥对在多个交易所实例间共享，一个实例没法了解其他实例
创建或取消的委托单。这意味着
.orders缓存不是共享的。因此API密钥对 不要在多个实例间共享，否则会有不可预料的副作用。 - 如果从ccxt库的外部创建或取消委托单，那么新委托单的状态不会到达 缓存，ccxt库也没有办法在之后正确的返回。
- 如果一个委托单的取消请求跳过了ccxt，那么ccxt库将无法从
fetchOpenOrders返回的敞口订单中找到该委托单，因此ccxt会将其标注为完结。这是错误的。 - 如果
fetchOrder(id)是模拟的，那么ccxt库没有办法返回特定的委托单。 - 如果一个未处理的错误导致应用的崩溃，那么
.orders缓存就不会保存以及再次 重启时恢复，缓存就会丢失。
注意：委托单缓存功能目前还在调整当中。