目前，我们后台的函数要开发这个match_user 匹配函数。
在开发这个复杂的函数之前，我们先概要设计下，这个函数要做些什么事？
-
确定前端要的最终格式
-
从数据库拿出所有需要的数据
-
循环异性数据，并代入到分值计算函数，得到所有异性的最终匹配得分
-
把数据按总分从高到低排列，塞进最终格式返回体中。
-
返回给前端
所以，我们这个函数其实中间是需要一个具体计算各个属性匹配得分的纯算法函数。
这个match_user只作为view视图逻辑上的处理。独立出来的那个算法函数就算为业务层。
好，我们开始按步骤实现。
首先确定最终格式，最终格式我们要根据前端展示效果来决定设计：
我们设计这个最终返回体格式为列表内嵌字典的方案，因为列表是有顺序的，所以正好符合我们的排序需求，然后就是内部的字典，也符合我们的几个字段填充需求。
设计如下：
[{"probability":"","Iscore":"","Oscore":"","weChat":"","Ouid":""}]
注意到，这里面字段中，前三个都需要我们实际计算才知道。
前端Result组件再次修改成,使用这几种字段的代码。
目前因为没有假数据，所以我们后台要先弄一批假数据来进行mock测试。
然后启动前后端服务，测试展示情况：
经过测试，我们发现了一个小情况，就是数据虽然成功传递给了前端的父组件，但是并没有成功传递给子组件Result.vue。
那么这个解决办法很多，很流行的解决方案是在子组件中监听这个数据的变化，只要发现数据变化，就重新刷新这个数据。
当重新刷新最新值后，页面才会有对应的变化：
这里我们注意到 排名居然是从0开始了，这个问题是因为我们在遍历整个列表时直接使用index下标了，下标自然是从0开始的，解决也很简单，给它加1即可：
效果如下：
不过前端我们并没有完全写完，因为还要写这个查看详情按钮呢~
因为避免昵称/wechat过长，所以我在按钮中取消了显示文案，并且加上了一个点击事件：show_detail
下面我们来写这个show_detail函数
这个功能很简单，就是弹出该会员的所有信息：
但是呢，这些信息我们仍然需要调取后台函数来获取：
所以写成这样：
然后快速实现这个功能！
urls.py：
views.py：
这里的逻辑并不复杂，只是用id取出来数据后，稍微按照字符串的方式进行了拼接。
前端测试点击查看详情结果：
滑动下:
试试雏田：
一切正常！
好了本节课结束，我们成功的打通了前后端匹配结果数据的流转和显示。
下节课我们要正式去写match_user匹配函数喽~
