http://www.baidu.com/link?url=Aj_xhOM5Q6rpZXkTMBPq4o0UbCO4eLq0esX8B3K2v06bkRS8F8lC4k06rv-3uZARLLTEKJHMhwzI_cdcJiHfqK&wd=&eqid=904bc71f000181740000000356d7d9bf
https://www.zhihu.com/question/35818812/answer/66086727
知乎页面访问存在502 Bad Gateway问题，就将内容保存下来
知乎上的一个解答——DongLin，发呆工程师
著作权归作者所有。
商业转载请联系作者获得授权，非商业转载请注明出处。
作者：DongLin
链接：https://www.zhihu.com/question/35818812/answer/66086727
来源：知乎
商业转载请联系作者获得授权，非商业转载请注明出处。
作者：DongLin
链接：https://www.zhihu.com/question/35818812/answer/66086727
来源：知乎
模式一和模式二提供了两种不同的能力，适用于不同的场景，看商户具体的需求。
两种模式，在支付的流程中，有一定的共同的流程：
1，生成订单。
2，用户支付。
差别在于：
模式一，先扫码，再生成订单。
模式二，先生成订单，再扫码。
而 生成订单，代表着 本次支付给商户的金额是否是已经确定了。
在模式一中，用户扫描的二维码，此时可以还没有确定实际要支付的金额。
在模式二中，用户扫描的二维码，金额已经是确定的。
可以这么理解，模式一中的二维码，是商品的二维码。
模式二中的二维码，是 订单的二维码，也因为这个是订单的二维码，所以必须要有时效性。
那么这两个场景的玩法，可以有一个明显的差别，
模式一，更适合无人职守的自动售卖机。所有的商品都有一个固定的二维码，价格相对稳定，当用户使用微信支付扫描了二维码，微信再请求自动售卖机的服务提供商的 后台接口，注意，这个请求中，是包含了商品ID以及用户信息的，这样，商户系统就可以根据 商品ID，以及用户的身份，再来确定用户实际要支付的金额。
模式二，更适合有人职守的，支付金额非常不确定的场合。比如，你去饭馆吃饭，虽然每个菜的金额是固定的，但一桌子饭菜的金额不固定，甚至是你还可能使用饭馆事先发放的代金券。这个时候，就需要收银员，预先创建一个订单，确定好金额，然后你再来扫描这个二维码来支付。
当然，用模式二来实现无人值守的自动售卖机，也是可以的。只是这个自动售卖机的就要多承担一些交互以及业务逻辑，在生成二维码之前，创建订单。
两种模式，在支付的流程中，有一定的共同的流程：
1，生成订单。
2，用户支付。
差别在于：
模式一，先扫码，再生成订单。
模式二，先生成订单，再扫码。
而 生成订单，代表着 本次支付给商户的金额是否是已经确定了。
在模式一中，用户扫描的二维码，此时可以还没有确定实际要支付的金额。
在模式二中，用户扫描的二维码，金额已经是确定的。
可以这么理解，模式一中的二维码，是商品的二维码。
模式二中的二维码，是 订单的二维码，也因为这个是订单的二维码，所以必须要有时效性。
那么这两个场景的玩法，可以有一个明显的差别，
模式一，更适合无人职守的自动售卖机。所有的商品都有一个固定的二维码，价格相对稳定，当用户使用微信支付扫描了二维码，微信再请求自动售卖机的服务提供商的 后台接口，注意，这个请求中，是包含了商品ID以及用户信息的，这样，商户系统就可以根据 商品ID，以及用户的身份，再来确定用户实际要支付的金额。
模式二，更适合有人职守的，支付金额非常不确定的场合。比如，你去饭馆吃饭，虽然每个菜的金额是固定的，但一桌子饭菜的金额不固定，甚至是你还可能使用饭馆事先发放的代金券。这个时候，就需要收银员，预先创建一个订单，确定好金额，然后你再来扫描这个二维码来支付。
当然，用模式二来实现无人值守的自动售卖机，也是可以的。只是这个自动售卖机的就要多承担一些交互以及业务逻辑，在生成二维码之前，创建订单。
https://pay.weixin.qq.com/wiki/doc/api/native.php?chapter=6_4
业务流程时序图
https://pay.weixin.qq.com/wiki/doc/api/native.php?chapter=6_5
业务流程时序图
性能对比 测试 。 Servlet的性能应该是最好的，可以做为参考基准，其它测试都要向它看齐，参照...)
