Graphql Apollo又开始抽风了

最近在开发的时候，突然客服反馈了一个诡异的问题，说商户的订单列表中某一条订单的套餐显示不对，但是订单详情显示的套餐是对的。

订单列表

订单详情

因为这个数据是直接取后端的值，所以第一反应先去看看后端返回的数据是否正确

但是看完接口返回的数据之后我直接懵逼了，数据尽然是对的

👇是列表的接口数据（❌）

👇是详情的接口数据（✅）

这就奇怪了。

我开始在各个地方打印 发现数据都是错误的，甚至怀疑我的下拉刷新上拉加载组件出问题了，最后我在fetcher返回的数据打印，发现数据尽然是对的，数据经过了apollo的封装出问题了。

该不会是缓存问题吧，但是我的接口是定义了fetchPolicy: 'network-only'的，先排除了这个原因。

然后我开始分析后端返回的数据结构，我在想为啥只有这个接口出现问题，最主要的是客服反映在列表不做筛选的时候才会出现，如果在列表加了搜索之后就显示正确。

然后我在想只有name发生变化了吗，我看那里面整个数据都是变了的，包括id，这个数据是租赁商品下面的租赁套餐。我感觉像是其他数据把我这个数据污染了，我在当前页找了相同商品的订单（B订单），并且出问题的订单（A订单）套餐id也跟另一个订单一样，于是我去数据库将B订单的商品名称改了，结过A订单的商品名称也变了，但是接口返回的数据没变

B订单数据

A订单数据

这就有意思了，我又想起之前淘汰过的问题，缓存问题，难道是A订单用了B订单的缓存数据，那为啥其他的数据没问题，然后我发现这个订单列表里面只有这两个订单是同一个商品id，rentalProduct.id，所以说订单详情和订单列表搜索没有问题，因为他没有相同的商品id。

于是我将rentalProduct.id这个字段在graphql注释掉

注释之前

注释之后

最后惊奇的发现数据尽然显示正确了

太感动了

原因

大致方向还是缓存这块，我才测试因为apollo检测到对象的id相同，自然他的内容也相同，然后直接使用缓存的数据，具体apollo有没有提供配置还没有去研究，后续研究好了，我在补充更新。