背景
公司的原上报平台准备下线，因此要将上报迁移到新上报平台，上报字段不变，仅替换上报url，我负责小程序的上报迁移
What happened
过渡期采用双上报形式，发现新上报的数据比老上报多约15%
问题排查
观察上报详细数据，发现用户量上整体相差不大（uv相差在2%以内），部分冷门字段相差极大（新上报可达到旧上报的几十倍）。 代码中只有export一个上报方法，在这个方法中对两处进行上报，因此可以排出不同字段使用的上报方法不同这个因素。
观察异常字段上报的其他附带信息，发现大量（在新上报中可达到99%以上）机型为iPhone6的上报，这是明显不合理的现象。翻阅老代码的逻辑，发现获取信息是通过微信小程序提供的API，并且没有default为iPhone6，因此排除这些iPhone6实际为未识别的机型这个可能。而在老上报中，这类异常数据明显少很多。
请数据中心的同事帮忙根据机型做了新上报和旧上报的统计表，发现新上报所多的15%数据其中12%是来自iPhone6的上报，此时认定这些异常上报是导致数据差异的罪魁祸首（除了iPhone6，还有一些差异明显的机型，它们刚好组成剩下的3%）。
已经确定存在15%异常上报，那么为什么只有新上报系统接收到了？对小程序真机调试，不断切换tabbar触发expose类型上报，发现总是新上报请求完了，才开始发送旧上报的请求，这是一个不合理的现象，因为上报只是简单调用wx.request，而wx.request的并发限制是10，按理说不会出现先后请求的情况，这个时候没有再纠结为什么真机抓包出现了这种情况，直接在代码里调整了上报顺序，发现实际请求顺序依然没有变，表现出的情况依然是新上报阻塞了旧上报，猜测和url有关，没有深究。在代码中把新上报干掉，这时候期望旧上报能够表现出之前新上报的数据；但是跑了一段时间后发现旧上报数据变化情况不大。
这时候可以确定新上报并没有阻塞旧上报，但是为什么在抓包时表现出了阻塞，我不得而知。
最后我给自己的结论是老上报能够识别阻塞异常上报，而新上报不行。
怎么交差呢
华哥告诉我，其实数据中心的同事根本不想知道到底是什么导致了这个差异，他们只关心能不能保持一致，如果不能保持一致，又该以哪个为准？这个时候问题已经变成了，怎么把这个锅甩的干干净净呢？
老上报已经准备下线了，显然，那边已经几乎没有同事在维护了，因此把锅扣在他们身上最合适，即使他们很优秀地过滤了异常上报。所以最终对数据中心的同事的解释是 原先的上报漏了一部分现在认为是正常上报的数据，现在的数据才是准确的
这样一来，我们的pv多了15%，皆大欢喜
