@shanghai1943

1. 如果支付方有取消接口，那么发起第二次支付前，就可以提醒用户有一个支付还在进行中，是继续之前的支付还是重新发起。后者则取消之前的支付再重新发起。
2. 如果没有取消接口，那么也提醒用户，用户非得支付两次这谁也阻止不了。不过基本上支付成功后，是可以检查订单是否支付，如果是多次支付，自动或手动提醒客服然后调用支付 API 撤销一笔自动返款的。
3. 其实还有更极端的情况，比如首次支付实际上完成了，但因为支付接口有问题甚至是支付方与银行有问题没有及时正更新，那么还是会导致重复支付。这种也是需要走上面那种流程。

不管怎样，支付成功后有异步流程去处理订单，如果此时已经有其他支付成功了的话，需要进入异常处理流程。完美避免重复支付也是不现实的。

订单保存正在使用的支付 ID ，其他想支付必须先取消这个支付请求。

@pcmgr456
这里不是除了 mac 就是 iPhone 么（ doge ）

只玩抖音微信是不是苹果更适合？起码不会乱安装 app 。

@chaoyebugao
国内应用很多都偏向复杂，所以我才说 Xamarin 不适合。尤其是对 UI 细节的把握简直不要太麻烦，如果只是注重功能实现，第三方对接不多，界面还可以就行，那么 Xamarin 无问题。

润的方式很多，对于我这边（新西兰）来说，就是取得合法进入本地并可以工作的机会，找到 IT 类的工作基本上就可以了。WHV 签证可能是最省事儿的方式，再不济就是留学，成本会高一些。

@chaoyebugao
我也折腾，但我做的是管理类 App ，人和用户都在海外。国内用户环境可能使用 Xamarin 会力不从心。.NET 老人可以考虑润啊，比 Java 润容易太多了。像澳新，.NET 为主。

@bobo2
这都什么年代了日志任然需要依赖纯文件？结构化日志中间件了解一下： https://datalust.co/seq

@Routeros
@evam

真不错，有这么多免费服务。

这边建议做一个网页呢

OP 你再想像一下如果医疗和养老也没压力后会怎样。这就是很多高福利的国家的情况。

@Bingchunmoli
我赞同你的说法，200 是可预见可处理的，其他都是意外，可以统一处理或不处理（系统异常）。

不管用不用 200 ，建议返回值格式统一：
{
"result" : 0, // 0 表示成功，其他表示失败，具体失败描述看 massage
"message" : "操作成功",
"data" : {} // 可以是任意类型，取决于你要返回什么数据
}

URL 我个人建议全部小写。

@bobo2
错误日志 Debug 日志，都有日志层统一处理，各开发语言都有这样的框架。你不能指望错误日志去 Nginx 的 Log 看吧？

@equationl
我之前就知道了但还是返回 200 ，因为简单可控，post 可以传任意复杂的数据。你完全 rest 了，然后第一件事情就是仔细选好你的 code ，这对业务并没什么帮助。

@sjdhome
严格遵守必有所失。比如下单前检查是否能下，是不是应该使用 get ？那么多参数对象数组嵌套你非用 get 折腾？某些场景允许 404 ，你非给我返回错误码，一堆可以接受的 404 不会给运维带来麻烦？

http 传输层错误和业务层错误分开，有那么不堪一击吗？

op 你竟然在 200 返回错误，小心隔壁来怼

@adoal #58
很是赞同。业务是业务，http 服务是 http 服务。业务监控自有各种监控中间件。否则哪天不用 http 了或者需要兼容另外一种协议，就完犊子了。

我是一律 200+Post ，虽然有点不规范但省了很多事情