Memory 伙伴匹配系统-开发文档
本文最后更新于:8 个月前
前端项目初始化
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
数据库表设计
1 |
|
1 |
|
后端接口开发
根据标签查询
1 |
|
1 |
|
1 |
|
前端整合路由
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
路由整合完成了呢
差点忘记了, 这里有个非常恶心的BUG, 我配完vue-router配置后, 启动服务显示页面为空白, 怎么搞都没反应, 结果把自定义路由那儿的 “/“ 删了改成 “/index”后, 就他妈有页面了, 我他妈给改回去后, 既然能正常显示了?!真奶奶的无语, 还好老子聪明机智哈哈哈, 差点栽这儿出不来了
前端页面开发
- 路由整合完毕之后,接下来就要开发我们的搜索页面了:
搜索页面
- 开发页面之前,我们先把搜索页面的路由配置好吧 (src/config/route.ts)
1 |
|
1 |
|
- 去找到合适的组件,完成页面开发
1 |
|
1 |
|
1 |
|
1 |
|
- 在脚本里编写一些逻辑,最终达成了:
搜索栏可以筛选标签列表里的标签
选中标签列表后可以把标签整合成json字符串,将来可以发送json字符串实现根据标签搜索用户
注:这块逻辑比较难,可以多加理解消化,这里不做过多介绍了(因为我自己也看懵了,照着人家的代码写下来的)
展示一下搜索页最终代码和实现效果吧
1 |
|
用户信息页
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
用户信息修改页
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
Swagger + knif4j 自动生成接口文档
第一步:创建Spring Boot项目并且在pom.xml中引入Knife4j的依赖包,代码如下:
1 |
|
1 |
|
然后启动项目即可
访问 http://localhost:8081/api/doc.html 成功自动生成接口文档!
如果springBoot版本高于2.6,可能会有报错,这是因为 knif4j 不兼容现今高版本的springBoot,这里有两种解决办法:
1 |
|
1 |
|
1 |
|
抓取网页信息
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
根据标签搜索用户
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
根据标签查询(补充)
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
简单介绍一下运作原理
钩子函数不用多废话了
引入我们的myAxios,发送请求,语法要熟悉
引入 userRoute,拿到searchPage页携带的标签列表,语法要熟悉
然后就是引入 qs , 可以正确地在axios请求中携带数组参数发送到后端,详情还需去百度了解
这里我还踩了两个坑,补充说明一下吧:
axios配置baseURL时,我给配成了 “https://localhost:8081/api",把http写成了https,导致响应状态码一直是500,唉
然后就是 qs 了,坑死我了,先介绍一下 qs 引入流程:
1 |
|
1 |
|
打通前后端查询用户
1 |
|
1 |
|
1 |
|
Session共享实现
1 |
|
1 |
|
1 |
|
1 |
|
修改 spring-session 存储配置
spring.session.store-type
默认是 none,表示存储在单台服务器
store-type: redis,表示从 redis 读写 session
1 |
|
接下来就要实现用户登录、用户信息展示、修改用户信息,但涉及到了跨域问题
这块login后,后端种下了session,但axios发送请求时,老是携带不到cookie,getCurrentUser()获取不到当前用户登录态
先做后边的功能吧,这一块儿我再研究研究,这个跨域携带cookie好像挺难搞定
axios不能成功携带cookie的话,上面的需求都做不了
三天后老子回来了,爷爷解决问题了!那么接下来,就让我捋一捋这个周末都学到了些什么吧!
后端接口开发
修改用户信息
1 |
|
1 |
|
1 |
|
1 |
|
顺带的,我们整理了所有的 controller层 和 service层的代码,最终呈现出统一格式:
controller 层负责:简单校验参数 —> 调用service层的接口代码 —>通用返回结果
service 层负责:实现全部的业务逻辑代码
整个项目结构就变得很清晰了,那我们简单展示一下现在的 项目结构 和 代码规范 吧:
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
展示当前用户信息
1 |
|
1 |
|
1 |
|
1 |
|
发送修改信息请求
1 |
|
打通前后端?
axios 发送请求时,默认不会携带cookie,这就导致了:你登录成功了,你的登录态也在后端写进cookie了,但是之后axios发送请求获取当前登录用户信息,由于没有cookie,是拿不到的
拿不到当前登录用户信息,剩下的用户信息展示、信息修改就都是扯淡了
这是为什么呢?因为我们前后端分离,虽然前后端服务器都在本地,但前端端口号:7070 后端端口号:8081
两个相同域名 但不同端口的服务器 在请求响应,这就是浏览器上的跨域问题:解决跨域问题引起的axios无法正确携带cookie
如何解决?这里有最简单的解决方法
前端 MyAxios.ts 加一行代码 —— withCredentials: true
1 |
|
1 |
|
到这里正常来讲问题就应该解决了,但如果这时你发现你前端所有的请求都报错的话,那说明:前端axios是允许携带cookie了,但后端服务器不接受
@CrossOrigin没有起作用
那就试试第二种解决方案吧:
config/WebConfig 下编写拦截器
1 |
|
1 |
|
好!这样问题就完美解决了!
但是我这边还有问题,前端请求仍然报错,最终我怀疑是我的前端域名有问题
我的域名一直是http://127.0.0.1:7070,于是我这样干了:
vite.config.ts下:
1 |
|
成功把域名修改为http://localhost:7070了,于是一切都成功了
当然我也试过这么改,没什么用
1 |
|
好了,以上就是跨域axios携带cookie的解决办法
最后还有个小BUG,就是后端接收到前端发送的id时,由于id是long型,在传输过程中可能会有精度丢失,导致前后端的id不一致,这里的解决办法在之前的raggie_take_out里也用过,那便是:
提供对象转换器JacksonObjectMapper common 基于Jackson进行Java到json数据的转换
1 |
|
1 |
|
导入用户数据
第一种:Export data to file导出数据(CSV格式),再Export data from file导入数据 适用于快速导入少量的数据
第二种就是用编程的方式批量插入数据了
先简单地写下代码实现方法吧:
在once/InsertUser下编写:
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
后端接口开发
查询全部用户
1 |
|
1 |
|
1 |
|
前端页面开发
主页页面开发
1 |
|
1 |
|
这块儿逻辑注释已经写得很清楚了,不过还是简单介绍一下吧:
axios请求,携带currentPage和pageSize发送至后端,响应到对应用户列表
之前MyAxios封装过返回值:response.data
需注意到,我们使用了vant的分页组件
1 |
|
有了这个组件,通过change方法,可以很方便地改变当前页码currentPage,同时执行查询,可以查到每页数据
组件其他属性也都标明了,可以控制总记录数、每页记录数
这里我们使用response.data?.records、response.data?.size、response.data?.total可分别获取:每页数据记录、每页数据容量、总记录数
当然,组件上的总记录数total就可以拿到了,pageSize这边是固定死的,每页10条,暂不支持灵活改变每页显示数
以上是对这段逻辑实现的粗略介绍,如有疑问还请研读代码,实现过程是十分清晰的
Redis缓存
之前我们给数据库批量插入了大量数据,并且在主页根据展示出所有用户信息
为了提高查询效率,我们还采用了分页查询的方式
但这种解决办法并不彻底,频繁查询数据库还是很低效,所以我们使用Redis技术来解决查询效率低下的问题
Redis的引入和测试
1 |
|
1 |
|
1 |
|
增删改查没有问题
这里存在这样的问题:RedisTemplate 底层的序列化方式,会导致存入的序列化后的value值成为乱码
StringRedisTemplate 继承了 RedisTemplate 有效解决了这个问题,但只能存放<String,String>
综上,我们在使用Redis缓存技术时,可以自己自定义(封装一个)RedisTemplate
自定义 RedisTemplate<String, Object> (config/RedisTemplateConfig)
1 |
|
1 |
|
1 |
|
分布式锁
问题来了,在实际工作中,我们面对的往往是集群服务器,难道在某一刻每台服务器都要执行预热缓存用户吗?
显然不需要。我们只需要一台服务器成功缓存到用户就行了。
要控制定时任务在同一时间只有 1 个服务器能执行。(怎么做?)
分离定时任务程序和主程序,只在 1 个服务器运行定时任务。成本太大
写死配置,每个服务器都执行定时任务,但是只有 ip 符合配置的服务器才真实执行业务逻辑,其他的直接返回。成本最低;但是我们的 IP 可能是不固定的,把 IP 写的太死了
动态配置,配置是可以轻松的、很方便地更新的(代码无需重启),但是只有 ip 符合配置的服务器才真实执行业务逻辑。问题:服务器多了、IP 不可控还是很麻烦,还是要人工修改
- 数据库
- Redis
- 配置中心(Nacos、Apollo、Spring Cloud Config)
分布式锁,只有抢到锁的服务器才能执行业务逻辑。坏处:增加成本;好处:不用手动配置,多少个服务器都一样。
单机就会存在单点故障。
多的概念在这里不再赘述,可以去看鱼皮的项目笔记,分布式锁实现原理以及注意事项讲的很清楚
Redisson 实现分布式锁
Redisson 是一个 java 操作 Redis 的客户端
提供了大量的分布式数据集来简化对 Redis 的操作和使用,可以让开发者像使用本地集合一样使用 Redis,完全感知不到 Redis 的存在。
那我们就使用redission来快速实现分布式锁控制吧
导入相关依赖
1 |
|
1 |
|
1 |
|
1 |
|
组队功能
后端开发
1 |
|
1 |
|
新增队伍
1 |
|
1 |
|
1 |
|
1 |
|
阶段性问题
使用 Swagger 接口文档快速测试,这里访问文档还报错了,在启动类上加了 @EnableSwagger2WebMvc 就解决了
奶奶的想启动个前端登陆一下还他妈报错启动失败,看了一下是我的node没了(鬼删的?)导致npm环境变量没配好
看了眼环境变量,真几把乱,我就纳闷了我记得很整洁来着,很快就搞好了
重新捋了一遍通用返回对象,新增了新的异常对象(ErrorCode errorCode,String description)
实现思路可以看下通用返回对象.Xmind,具体代码还请跳转至用户中心-开发文档,内容已同步更新
改了下npm环境变量还手贱删除了nodejs,俺的个人博客都被搞垮啦,之后会总结个人博客部署流程的
team表添加了join_num字段,存储当前队伍已加人数,记得同步修改更新xml、mapper、domain
查询队伍
1 |
|
逻辑还是很简单的,前端传param参数,后端接口封装一个队伍查询信息类,再依次对每个字段校验,最后分页查询实现
这里还遇到一个问题,我写成这样:QueryWrapper
tqw = new QueryWrapper<>(team) 它的SQL查询语句就默认自带了 where name = ? 导致 twq.like(“name”, name) 失效了,搞了半天才发现 controller层
1 |
|
修改队伍
1 |
|
1 |
|
1 |
|
1 |
|
阶段性问题
注意到我们查询队伍接收param参数,新增队伍和修改队伍接收JSON参数,记得封装的参数类要实现每个成员属性的get、set方法
体会到封装参数接受类request的好处,还是那句话,前后端联调更加方便 –> BeanUtils的用法
优化了相关业务的代码,更加简洁易懂了
这里应该捋一捋我对相关业务流程的理解的,放到明天啦~
业务流程梳理
1 |
|
1 |
|
1 |
|
用户加入队伍
1 |
|
1 |
|
1 |
|
1 |
|
用户退出队伍
1 |
|
1 |
|
1 |
|
1 |
|
思考
队长解散队伍
1 |
|
1 |
|
1 |
|
1 |
|
获取当前队伍信息
service层
1 |
|
controller层
1 |
|
前端开发
展示用户已创建队伍
展示用户已加入队伍
1 |
|
1 |
|
1 |
|
阶段性问题
首先这一段逻辑很简单:登录用户的id做参数,拿到其已加入的队伍
一如既往地使用 Card 商品组件
我写这一段还是挺轻松的,虽然不熟练,写的慢,但是很轻松快乐哈
需要注意的点有这些:
van-card 的属性使用方法:<template #buttom> 等
对了,像咱们这种表单页,还得微调内边距啥的,自己看着用最简单的HTML+CSS做就可以凑合实现
奶奶的,打算趁热打铁开发修改队伍页面的,发现这个表单写起来还挺生疏,就先开发新增队伍页面吧
新增队伍
1 |
|
1 |
|
他奶奶的,这个页面还真不好搞定呢,踩了无数坑,前后拖了3天可算完成了,我简单总结一番:
首先就是把那form表单合适的、好用的拿过来,先别管那些数据交互
然后创建一个对象,成员属性跟表单作数据绑定
对这些表单的属性都必须有所了解,每个属性是干嘛的都得心知肚明
简单的比如label、placeholder、type,计步器的max、min,日期的展示逻辑:showPicker = true
日历的@confirm、@cancel实现逻辑,这些自个儿多写多练就能记住了
别的不多说了,再说几个注意点
阶段性问题
这里的对象要声明为响应式的,即:const teamAdd = ref({ …initTeam });,不然作数据绑定的时候会有问题
提交按钮不用写@click=”onSubmit”了,表单上写过了,否则会连续执行两次提交
POST请求这里参数我写错了,teamAdd.value写成teadAdd了,请求里的json数据一直请求不到接口
前端传回的empireTime是yyyy/MM/dd格式的,传到后端还接收不了了,奶奶的测试的时候好端端的
解决方法:修改后端empireTime字段的Date格式就可以:(暂时先这样解决)
1 |
|
修改队伍
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
阶段性问题
这里解决了之前提到的问题:用户加入和创建队伍还显示不正常,这不是浏览器问题
这是因为我删除了队伍team,却没有删除user_team对应记录,查询teamList时查到的队伍出现null值,前端渲染就出现了错误
还有teamUpdatePage.vue显示不正常,修改了下文件名为teamEditPage.vue就可以显示了,这浏览器真几把无语
整理了下数据库,删除了一些脏数据;整理了下队伍页面,都放进pages/team下了,修改包注意同步修改路由和对其他页面引用
思考
这里又明确了下前端axios请求接收到的的响应值response:首先axios封装了response,我们从后台传回的数据都封装在response.data下,这一点毋庸置疑。全局响应拦截器帮我们做了这一点,所以我们使用myAxios发送请求,响应值就是被封装好的response.data了,即后端封装的BaseResponse对象(code、data、message、description),理清这一点后,之后处理响应值的思路就很清晰了
退出队伍
1 |
|
1 |
|
阶段性问题
优化后端逻辑
1 |
|
1 |
|
优化前端逻辑
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
阶段性问题
解散队伍逻辑实现不了
就是前面提到的问题,队伍页面展示时team.status被硬修改了(0-“公开”,1-“私密”,2-“加密”),而在解散队伍的逻辑当中,需要获取队伍的status,导致请求参数错误。解决办法就是不要直接修改team的status,另找个变量。
现在这个问题解决了,改动挺多,听我娓娓道来~
这里另找个变量status不好实现,得遍历到所有team,得到的每个team对象中新增变量保存status修改后的状态。(设想这样是挺复杂的,可以实现,但感觉完全没必要)
另一个思路很直接,不变team.status,表单在作展示时可以调用一个函数,按(0-“公开”,1-“私密”,2-“加密”)转换显示
那我们就在service/function\getStatus.ts下实现一个函数,负责转换status
1 |
|
1 |
|
1 |
|
解散队伍
1 |
|
1 |
|
阶段性问题
1 |
|
1 |
|
还要注意这两个操作的后端逻辑校验,那就是:
退出队伍时,如果只剩最后一人,要解散队伍和队长直接解散队伍,一定要同时清楚team和user_team中的记录,这样不仅影响业务逻辑,还会在脏数据多的时候,前端队伍显示不正常,这问题你找都找不到
哎我真几把服了,还以为teamList1和teamList2没用了,把赋值语句删了。搞得队伍表单连数据都没有,怪不得突然就不显示队伍了
1 |
|
思考
1 |
|
1 |
|
数据基本恢复完成!之前的同步工作做的不够好,建个表不是少tags就是缺profile,小问题
顺便优化了join_num字段,默认为1,新增队伍时已加人数就默认置为1了
当然了,有了数据才解决了上面的解散队伍的问题
浅浅记录一下效果吧:
浅浅记录
想起来了,上次推送blog老是更新不成功,不知道这机子吃错药了还是,现在就没问题了
好几天没有更新内容了,这几天都去做毛概PPT和性交视频剪辑了,基本没精力完善这个(2023/05/18早)
今天就完成搜索队伍功能吧
搜索队伍
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
阶段性问题
开发搜索表单页面,就做好两点:搜索条件和搜索结果,把对应数据跟表单绑定好就成
注意到后端处理请求的业务逻辑需要变动,之前写的不好,要求为:有值且值正确,就去查询数据库
拿到响应数据后,注意分页查询返回的队伍列表是封装在data下的records中的
还有一个蛋疼的问题,就是浏览器不自动刷新了,只能重启前端服务才有效果,最后发现是TeamListPage.vue的路由里把Team小写了,服务启动没问题,但修改就有问题了,无语了
思考
随机匹配
开始搞随机匹配咯
编辑距离算法详解: https://blog.csdn.net/DBC_121/article/details/104198838
用户匹配
1 |
|
1 |
|
匹配用户接口
1 |
|
1 |
|
阶段性问题
这里的SortedMap是用来存储用户和匹配度的,且默认按key值升序排序,不允许重复key值,实现起来有点问题,改天看完鱼皮再试一试,先记着 (2023/05/20晚)
实现随机匹配的逻辑, 我们要优化两个点: 执行时长为多少? 是否能正确匹配?
首先优化执行时长, 有以下几点可以优化:
1 |
|
然后就是优化能否正确匹配了, 很显然, 昨晚的那个SortedMap并不能完成这个功能, 我就说嘛
SortedMap默认按key值升序排列, 把distance做value是不行的, 把distance做key值也不行, 因为SortedMap不允许重复key, 那样的话相同distance就被顶替了.
比较可行的方法是把用户和相应相似度存放进List中, 再按distance升序排序, 最后查出前num条
代码实现的话就明天写吧 (2023/05/21晚)
他妈的连抄带粘写完了, 先不详细解释了, 必做的优化点做到位了, 剩下的逻辑看着真恶心, 放下边慢慢体会吧:
1 |
|
匹配用户页面
- 之前写过的分页查询所有用户就先保留了
1 |
|
搭建图床
搭建过程就不多说了 收藏了好几个CSDN博客教程
最重要的是在PicGo里下一个插件 搭建一个Gitee图床 (不用GitHub图床是因为这玩意儿BUG太多了 尤其是网络原因)
两个图床的配置都放下面了 我用了Gitee图床
操他妈的上个厕所就能显示了
总之 图床可以正常使用了 现在把浏览器收藏夹整理一下先 (2023/05/23晚)
今天距伙伴匹配系统从零开发 整整俩个月了 简单纪念一下 但是今天不想编码了 干点儿别的吧 (2023/05/24晚)
持续优化
随机匹配优化1.0
1 |
|
1 |
|
页面标题优化
1 |
|
1 |
|
用户标签优化
1 |
|
1 |
|
阶段性问题
这里把getTeamStatus.ts也优化了下,结果给网页整空白了,卡了半天发现TeamListPage和TeamPage都调用了这个方法而前者我忘记改过来了,要注意一下
第一遍做的时候取了user的status,才反应过来user的是gender,又全改了一遍
然后发现数据库中的gender是varchar型,而status是int型,真几把服,谁设计的表,害我前端数据类型不对应,逻辑判断都有问题
今天就干到这吧(2023/05/26晚)
加入队伍
1 |
|
1 |
|
1 |
|
1 |
|
搜索队伍优化
1 |
|
1 |
|
退出队伍优化
1 |
|
搜索队伍优化2.0
1 |
|
1 |
|
1 |
|
当然,我们可以再次使用onSearchTeam来根据搜索表单筛选队伍,分两种情况:
公开页激活(active.value === 0)和加密页激活(active.value === 1)
根据页面激活情况发送相应请求即可,并将结果绑定到对应表单上
1 |
|
s
1 |
|
我们之前是这样实现的,本意是想筛选出>=maxNum的队伍,但MP的每个QueryWrapper后紧跟条件时,会自动使用and来拼接(懂吧,就是SQL中的where语句下的and拼接条件)。当最大人数筛选条件正确填写时,执行情况为:把.or()前的所有条件和.or()后的.eq(“max_num”, maxNum)条件用or连接去查询,结果显然不对,查到了多于预期的数据。
那为了实现查询>=maxNum的队伍,我们舍弃了.eq,把maxNum + 1就行了,逻辑上没有问题了
1 |
|
搜索队伍优化3.0
1 |
|
加入队伍优化
他妈的好多东西,明天再做吧嘿嘿嘿
实现申请加入加密队伍时,需要填写密码
这个功能基本实现了,但发现目前后端仅校验password的格式,并没有校验其正确与否,待明日优化完毕这个逻辑后再作记录吧(2023/05/31晚)
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
分页查询队伍优化
主页优化
1 |
|
阶段性问题
前两天给GiHub仓库上推送用户中心和伙伴匹配时,由于近期没有按时推送项目到Gitee上,操作的时候不小心把Gitee上的旧代码拉到本地了。最要命的是,还他妈把本地项目给覆盖了,还好一查发现GitHub仓库里的代码是最新的了,差点以为这几天白干了
以后更新项目要及时推送到Gitee和GitHub上(2023/06/08)
定时查询任务优化
给重点用户推荐用户:每天00:00定时缓存预热,并保存24小时(好像没啥卵用,给匹配相似用户加这个功能还不错)
这个定时查询使用了redisson实现分布式锁,完成了多台服务器中只能有一台抢锁成功并缓存预热的功能,目前这个定时任务只是预热了重点用户的查询用户,用处不大,仅学习定时任务和分布式锁,将来优化(2023/06/08)
随机匹配优化2.0
1 |
|
TODO优化
1 |
|
搜索队伍优化4.0
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
个人信息页优化
1 |
|
1 |
|
1 |
|
1 |
|
退出登录
1 |
|
1 |
|
1 |
|
验证码登录
前端开发
1 |
|
1 |
|
1 |
|
阶段性问题
后端开发
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
1 |
|
注册功能
前端开发
1 |
|
1 |
|
1 |
|
后端开发
1 |
|
1 |
|
阶段性问题
1 |
|
思考
浅浅记录一下,由于英语四六级和临近期末,伙伴匹配系统暂时开发。
但基础功能已经完备,这几天也正在了解云服务器领域的知识,为将来的项目的顺利部署打点基础,也要准备接下来项目的学习:API接口开放平台、微服务搜索、BI智能平台(2023/06/26午)
今天是个大喜的日子,Memory-伙伴匹配成功部署上线:http://120.55.62.195:7071/#/(2023/07/29晚)
轮播图
这功能简直不要太简单,加个组件,放两张图片不就搞定了
一个多月前,就已经有这个想法了,不过我想放几张我喜欢的图片,但存储在Gitee图床的图片好像有跨域处理,外界访问不到
于是这个想法就被搁置了
不过我开通了七牛云对象存储服务,当我的免费图床hhh
以下是轮播图的具体代码:(2023/07/31早)
1 |
|
1 |
|
搜索用户优化
TODO
新老值一样,无需修改(减少查询数据库)
根据队长id查询队伍——>根据队长姓名?(这个也可以不改的,可以把用户星球编号设置为队员id编号)
校验老三样:校验登录、校验用户(存在?权限?封号?)、校验队伍(存在?状态?)(√)
退出队伍,校验该用户是否为该队伍成员
解散加密队伍必须输入密码
获取当前用户创建的队伍(√)
获取当前用户加入的队伍(√)
分页查询用户信息的脱敏
分页查询队伍信息的脱敏
代码封装性不好,好多重复代码
代码思路很清晰,但有些许不整洁
user_team表join_time冗余字段 (收回这个问题,create_time与业务无关,不能替代join_time)
createTime、expireTime、updateTime传到前端显示不正常(√)
前端的pages、models等目录杂乱了,需要分包管理
前端关于页面跳转的问题,router.push()、router.replace()的使用
axios请求的返回值:response、response.data(√)
修改队伍还要扩展支持修改最大人数
获取队伍信息team/one我直接返回team了,没有脱敏,其实密码加密就行
根据标签搜索用户、根据队伍名、队伍描述等搜索队伍需要优化(√)
前端页面的标题 对应每个页面都应该显示对应的标题(√)
登录后页面跳转到原先页
搜索队伍分为公开和加密两栏,私有队伍不对外显示(√)
加入队伍功能,加入加密队伍需要输入密码(√)
分布式锁防止单用户加入两次队伍
项目打包上线
拿到加入队伍的所有队员的信息
前台的提示信息不够完善,比如登录时的用户名、密码校验提示,电话号码、验证码校验提示,新增、删除、加入队伍提示等等
支持用户上传头像
Memory 伙伴匹配系统-开发文档
http://example.com/2023/03/24/Memory 伙伴匹配系统-开发文档/