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

这么典型的场景 如果是确实要做好 肯定要单独抽个订单服务，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 张邀请码

这个需求我刚好做个一个服务能实现这种查询，只是最开始做这个服务的目的不是为了查询。
我做了一个元数据服务，也就是把数据表进行结构化，配置字段关系，字段类型等等，然后通过给定的查询条件自动生成 sql ，并且支持穿透查询，达到动态查询的目的。一个列表的结构也就是一个元数据，每个元数据的字段是后台配置的，只是根据需求返回指定的列或指定的条件数据而已

https://filehelper.weixin.qq.com/ 发到 web 上然后另存

有即时聊天功能，最好服务器在国外，制度稍微宽松一点

屠龙勇士 终成恶龙

怎么架构肯定是每个人都有自己的想法 我得想法就很简单在满足功能的前提下，尽可能通过架构设计与架构约定保证代码的可迭代，可维护，且能很好的支持可预见性的后续扩展，目的就是在业务的前提下（毕竟很多时候业务会直接影响架构）保证系统逻辑清晰简洁，模块清晰，各种场景处理尽量顺滑
至于 啥高性能，高可用，分布式 这些都是看具体业务场景是否需要着重考虑，不建议一来就搞得高大上，用不上还增加复杂度

应该要吧 鉴权中心连用户都不晓得 那鉴了个寂寞呀
至于说的整合不清楚是代码层面的整合还是远程调用用户服务
我们系统是鉴权服务远程调用用户服务查询用户信息 然后进行鉴权