我在做这个功能支付的时候，一共是涉及到三个主体之间的通信，现在分享给家人们，分别是我们的客户端，我们自己的服务器，以及三方的支付宝服务器；我们前端做的就是头和尾两个部分，在头上呢我会跟我们自己的服务器进行交付，我会发起一个请求，我用的是一个web组件模拟了一个get请求发送，在发送请求过程中呢，我会把当前想要支付的订单id发给我们自己的服务器，然后自己的服务器呢，它呢拿到订单id它会去跟三方的支付宝服务进行交互。然后呢用这个订单id去进行一个付钱的操作，等到付钱完毕以后，支付宝这边会先把响应结果返给我们自己的服务器，我自己的服务器存储一下当前的这个到底是支付成功还是失败，这些相关信息先存到数据库层面，不能让它把这个状态丢了，那接着，我自己的服务器呢，会相应一个结果给我的客户端，也就是这个web组件，这是整个的一个核心流程；
等到web组件拿到支付结果之后，我用这个支付结果做了一个信息的展示，这里面值得一说的是拿结果的过程我们采取了一个监听的方式，因为它在整个过程中呢会不断的有url地址的变化，然后我们约定了一个什么时候算是支付成功了，那就是那个包含了一个叫payResult的这个标识，就代表当前要显示结果了，然后我们从这个响应结果里面，url地址里面解析出来他的一个参数，我写了一个解析方法把它进行一个参数解析，拿到payResult这个参数以后我们做了一个支付结果的展示，这就是我用自己的描述一下这个过程里面大概是怎么样的一个玩法，
- 接下来我们来看一下头和尾，这是需要重点关注的
- -web组件模拟一个get发起支付请求`web({src:`xxxxxxx`, controller:this.controller})
`
- web发起虚拟请求之后，后续的事看不见但是得清楚，它事实上web组件发送支付请求是发给我们自己的服务器的
- 我们自己的服务器拿到自己的请求之后，它会自动跟三方(支付宝服务)进行交互，所以我们可以看到打开了三方的支付的网页，这是有本地服务器和三方服务器交互打开的，
- 等到我们后续输入账号一系列操作它会响应出来这个结果，响应结果之后呢，咱说了，要去监听它唯一的一个标识
- web组件的onInterceptRequest这个方法就是监听它整个url的一个变化，它会有很多的url，直到我们看到/pay/redirect这样一个标识，那就证明它呢以及支付完成了，返回我们的支付结果，所以在这方法里面拿到这个标识以后做判断，直到拿到这个标识以后，我才有资格去后面做后面的事情
- 然后就是展示支付结果，我们需要去解析它的参数，然后拿到参数之后去做后续的逻辑展示，
- parseUrl(url)拿到参数以后，携带参数跳转去支付成功或者失败页面，这一步需要做的就是拿到参数的是一个字符串，所以再跳转过去的结果写的初始值都是一个字符串，
- 简单的模拟一下，无非就是一个条件渲染，拿到payResult之后，在后面呢把对应的UI视图显示一下就完事了，这是一个整个的流程
- - - 总结：整个核心流程(使用哪三部分完成的)；前端重点做了哪些事情头跟尾，头上做了什么事儿，尾上做了什么事儿；然后就是在整过程中需要注意的细节是什么
- - - 最后注意事项
- - - 我遇到的坑点：onInterceptRequest方法里不写return null 它会加载不出来页面，它会变成白的，那你一说这个地方需要return null才行，这是我踩的一个坑