场景：
在APP端扫码展示扫码结果
前提描述：
原来设计的是在扫码页面，扫描之后如果出现网络/服务请求的异常情况，直接在扫码页面进行toast报错提示，但是后来开发说在本页面处理不成，必须在新的结果页来报错这些异常。
后来自己想了一下其中请求过程，又朋友探讨了一下为什么开发会这样说？
在扫码页面，APP原生端通过扫描之后获取到一串字符串，但是没有一个动作可以让他们借助去请求后台接口，就比如说我们要在一个页面做一个弹窗展示，需要一个按钮这个动作辅助才能弹窗。再回来扫码问题上，开发需要借助跳转至新的页面这个动作才能请求后台接口，完成请求结果这样一个动作。
扫码页面就是一个纯处理扫码这一个逻辑的页面，相当于是扫二维码是工具页，处理我们想要的业务逻辑需要在另外一个页面来处理发生。
但是，
难道就不能在扫码界面完成报错提示吗？有时候可能会考虑用户体验，需要在扫码页面报错异常信息，而不是跳转至新的页面才能给出错误提示。
和朋友探讨的是可以处理解决，把朋友的原话粘贴在这里，
跳进页面的时候带进来一个要请求的接口是哪个的标记，然后扫码dialog跑接口，出来数据以后有错直接报错，没错拿着数据跳转页面.
这样以后不同接口扫条码都走这个工厂
要么就是你们开发说的那种，业务和扫码分离，扫码就是扫出来字符串，然后跳转页面去跑自己的接口.
从你的A页面跳转到扫公用的扫二维码页面，带上一个标记，说我这次扫的二维码要请求A接口,然后扫出来跑A接口，跑到的数据报错或这继续走A的这个后续业务逻辑,
然后你以后加了B业务，B页面跳二维码页，带着tagB
处理方式大概就是这样子吧，中间具体的实现逻辑我不完全懂，大概明白为什么会这样，写出来分享给需要的朋友，有什么不对的地方也可以留言我们探讨一下。
对于产品来说设计的时候，1、要考虑自己的产品设计需求；2、和开发探讨他们的实现方式，是可以在扫码页面处理，还是工具页和业务页分离了，需要设计新的异常处理页面。 如果我们用户体验很重要，那就强势一些去沟通吧_
