基本没啥补助 除了报销常规费用就是 只有 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 下面的那个软件 很久之前见过的东西 但是一直没有用过 刚才特意看了下现在支持挺多功能了 比如 云采集 自然语言处理 预制模板等等 不过楼主定位于他些许不一样 适用人群也有差别 不能算完全同质产品

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

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

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

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

楼主已经是个非常非常难得的人了，一直都在处理噪音的问题，为此还使用了很多方式。我楼上也很吵 2 个男孩 也上门沟通过很多次，但是毕竟小孩哪有那么听话，不可能时时刻刻都看着，对此我也很能理解。。。但是有时候

我们用的 nacos 注册中心与配置中心一体 方便部署 用起来也不错 与 seata 集成也很方便 目前没发现啥问题。。。就是如果配置集合会有坑 最好用字符串手动分割

电脑上不输入邀请码能进去 然后送我 2 张 然后 手机上 还是没有注册 然后使用电脑上送的邀请码在手机上成功注册 然后 又送 2 张邀请码