这个评论也说到痛点：

Actually yes, that would let them pre install any rogue app and no one will know because of the privileges it would have

事实上，是的，这样他们就可以预装任何流氓应用，而且没有人会知道，因为它会有特权

我感觉 QQ 的截图挺好用的呀 长截图也支持 滚动模式截长度

基本没啥补助 除了报销常规费用就是 只有 50 块每天餐补了

任何灵感与想法都值得尊重与尝试
即使真就是重复造轮子 其意义也不在于轮子 而是其制造过程

楼主之前怼过产品么 对产品有意见么？ 换位思考下 就知道该注意什么了

这么典型的场景 如果是确实要做好 肯定要单独抽个订单服务，APP 和 PC 两个接口，内部对于创建订单进行抽象，提供一些公共的操作，APP 和 PC 各自集成 处理自己那部分特殊业务与处理

如果只是为了完成功能 那就 CV 呗

@lovepplforever 客气了 其实 斩 赤红之瞳 并不是温馨系的 和楼主开个玩笑哈 不过温馨治愈系的 我强推 夏目友人帐

那我推荐 斩 赤红之瞳 非常温馨治愈

其实昨天那个帖子我也看了 都没敢说话 怕被喷，。。我们系统就是 get post ，只要进行了业务代码一定返回的 200,返回固定的格式
{"code","","msg":"","data":""}
我也是个实在派，感觉 api 是给开发人员用的，在都能满足功能且扩展性都差不多的情况下，我会优先选择简洁的方案。

1.我们只是把 http 当做一个传输协议，不参与任何业务逻辑，所有业务信息都已接口返回的内容为准，统一口径，这点就和 tcp/ip 一样，返回的包里才是具体的业务数据，就和虽然 tcp/ip 预留了可自定义的数据位置，但实际情况几乎不会有人去使用这个（不要杠 http 协议和 tcp 协议不再一层。。。我只是举个例子，非完全严谨，，瑟瑟发抖。。）

2.比如我们系统是前后端分离，外部传入的数据都要做防御性校验，比如参数必填，有错误，逻辑校验不过的情况，在我看来都是参数验证不过，返回一个固定的业务码，再返回一个实际具体的错误

3.我也对接过很多大厂的 api 某度 某宝 某信 尤其支付这块，业务情况实在是太多，如果不使用自定义的业务码，只返回错误 msg 不论是提工单还是检索问题，或者系统内部进行错误判定都不是太合适，假设是 http 状态码+错误 msg 那么在 http 码非 200 的情况下 就只能通过字符串消息进行错误判定，这样总感觉给人一种不严谨的感觉，因为错误码不会变，但是具体的错误文案可是会变得

4.200 一把梭 前端拦截也比较简单，只需要拦截非 200 且错误码不是成功的就行，也就是先 http 状态拦截，再 code 的拦截，只要返回 200 就能保证这个请求一定是到了业务里，其他情况一定就是出在了 http 协议上

5.而且返回具体的业务码可以前端可以根据不同的错误码 进行业务处理，例如：登录时账号密码错误 返回 1 那超过 5 次返回 2 那前端就会给出个提示 60 秒后在尝试，这种业务控制。当然这个功能不依赖后端也能完成，但是当这个逻辑作为业务的硬性逻辑时 那必须就得由后端控制，即使你直接访问 api 我也会有这段逻辑

以上仅是我们系统是这样做的，不代表任何群体，任何观点，我只是陈述我们系统是怎么做的而已。。。

存在即合理，没有绝对的正确与绝对的错误，没有最好的设计，只有最合适的设计。。。。。

如果看完你不认同这个 一定淡定 淡定 不要喷我。。。。。

@nyfwan123 嗯 就是 win 下面的那个软件 很久之前见过的东西 但是一直没有用过 刚才特意看了下现在支持挺多功能了 比如 云采集 自然语言处理 预制模板等等 不过楼主定位于他些许不一样 适用人群也有差别 不能算完全同质产品

由于第三方支付需要业务号，此业务号不可重复，如楼主所说，如果使用订单号做支付业务号，那么只能处理一种支付方法，如果使用订单号对应多个业务支付订单的话可以支持多支付方式，但是处理重复支付比较麻烦。。。

综上所述。。。如果重复支付了，那就申请退一笔呗。。。这种情况应该比较少，除非有人就故意这么搞，
复杂问题简单处理。。。。。

和八爪鱼挺像的功能 目的都是减少爬虫开发工作量

你已经很厉害了 我上午写的 下午就忘了 别人问我逻辑 我还得去翻翻代码 - -