企业官网建设流程全解析

从实际开发角度聊聊这个“Vue + Python 电影院购票选座系统 + 协同过滤算法”的项目。如果你正好在做类似的课设、毕业设计，或者想给自己积累一个完整的全栈项目经验，这篇文章基本上可以当作一份参照稿来看。有人可能会觉得电影院购票系统太常见了，没什么技术含量，但实际上当你真正动手做的时候会发现，选座状态同步、并发锁、推荐算法怎么落地、前后端怎么配合，每一样都能挖出不少坑。我带着“从零搭完整项目”的视角，把整个设计和实现过程拆开讲清楚，顺便把我在实际开发中踩过的坑、补过的逻辑都整理出来。

1. 项目需求拆解与技术选型分析

1.1 业务需求与功能模块划分

先把需求捋一下。电影院购票选座系统，表面上看起来就是“用户选一部电影、选一个场次、挑几个座位、下单付款”，但实际上完整一点至少应该包含两个端：用户端和管理端。用户端要有的功能包括：浏览电影列表、查看电影详情（海报、简介、时长、评分）、选择场次、选座、提交订单、查看订单记录、个人中心。管理端要有的功能包括：电影信息管理（增删改查）、场次排片管理、座位价格策略管理、订单查询和管理。如果再加点交互上的要求，最好还能有基于协同过滤的个性化电影推荐——这也是标题里特别提到“协同过滤算法”的原因。

做项目之前一定要先把功能模块画清楚，否则写代码的时候容易边写边补，最后代码结构一团乱。我这样的模块划分方式比较适合常规课程设计或者个人项目展示：

• 用户模块：注册登录、个人信息维护
• 电影模块：电影列表、电影详情、搜索
• 场次模块：按电影查场次、按影院查场次、剩余座位数显示
• 选座模块：可视化座位图、已售/锁定/可选状态区分
• 订单模块：创建订单、座位锁定、支付状态模拟、取消订单
• 推荐模块：基于协同过滤给用户生成个性化电影推荐列表
• 管理端模块：电影、场次、订单的管理操作

这里有个很容易忽略的点：座位锁定状态和订单状态是强关联的。用户选了座位不付款，不能一直占着位置。我当时是把订单设置成一个“待支付”的中间态，在这个中间态下锁定座位，并设置一个倒计时。一旦超时未支付，就释放座位。这个逻辑看着简单，真正实现的时候要考虑数据库字段设计，还要考虑并发下同一时刻两个人同时选同一个座位的情况，后面专门会讲。

1.2 为什么选 Vue + Python 这套技术组合

选型这事，没有绝对的正确，但一定要有合理的理由。Vue + Python 组合在校园项目、个人全栈练习、中小企业内部系统里非常常见，几乎可以称为“标准配置”。

前端选了 Vue，说几个理由。第一，Vue 的上手门槛确实低，像选座这种富交互界面，核心其实就是“数据驱动视图”。你只需要用一个 seatList 数组维护每个座位的状态，页面上的座位格子会自动跟着变化，不需要像原生 JavaScript 那样手动操作大量 DOM。第二，Vue 生态的组件化非常成熟，可以把“座位图”“电影卡片”“订单流程”拆成独立的组件，每个人负责一部分也能并行开发。第三，Vuex 或 Pinia 做全局状态管理，在选座这种需要跨组件传递数据的场景下非常合适。比如你点了座位，选座组件要更新座位图，同时订单摘要组件要显示票价总金额，你还要在跳转页面的时候带上选座信息，如果没有全局状态管理，光是传参就能让人写到崩溃。

后端选了 Python，我心里是这么权衡的：Python 在 Web 开发里的框架非常成熟，Django 和 Flask 都是极为可靠的选项。Django 自带 ORM、Admin 后台、认证系统，适合快速搭建业务比较标准的系统，管理端甚至可以直接用 Django Admin 改一改。而 Flask 更轻量灵活，适合想完全掌控代码结构的学习场景。我做这个项目时选的 Django REST Framework，理由很简单：我不仅要写业务接口，还要写协同过滤算法，Django 的 ORM 在做数据处理时很方便，DRF 写接口也高效，一个 ViewSet 配一个 Serializer，CRUD 基本就完成了。如果只是用 Flask 自己写路由，管理端好多增删改查要手动实现，开发效率会低一些。

还需要一个数据库。业务数据用 MySQL 或者 PostgreSQL 都可以，我习惯用 MySQL，简单稳定。而协同过滤算法里会用到用户对电影的评分数据——注意，这个系统的评分数据哪里来是个关键问题，后面会详细讲。推荐结果可以实时算，场次多、用户少的时候没问题，如果在生产环境，一般会做成离线计算 + 在线缓存，用 Redis 存每个人的推荐结果。

2. 数据库设计与核心表结构

2.1 几张核心表的设计思路

数据库设计是这种业务系统的地基。地基不稳，后面写什么功能都会觉得别扭。我当时设计了这几张表：用户表、电影表、场次表、座位表、订单表，外加一张用户评分行为表。

用户表没什么特殊，就是常规的 id、用户名、密码哈希、手机号、注册时间。密码记得不要用明文，用 Django 自带的 make_password 做哈希存储，这是安全底线。

电影表，核心字段是标题、海报URL、导演、主演、简介、时长、上映日期、类型。其中“类型”字段对推荐模块非常关键，做基于内容的过滤时直接用到。另外要加一个“综合评分”字段，可以用平均评分来维护。

场次表是连接电影和影厅的枢纽。字段包括：所属电影 id、影厅名称、放映时间、语言版本、票价。一个常识性坑是：同一时间同一个影厅只能有一个场次，这个约束虽然数据库层面不好直接做，但在新增场次的时候一定要去重校验。

座位表，这个的字段设计要看你怎么维护座位的状态。我选择的是“每个座位一行记录”的方式，包含：场次 id、排号、列号、座位状态。座位状态是核心，我用 0 表示可选，1 表示已锁定（即有人正在下单但还没支付），2 表示已售出。锁定状态是关键，它天然起到“预占”的作用，可以防止两个人同时下单时重复购买。

订单表，字段包括：订单号、用户 id、场次 id、座位 id（多对多，一张订单可以买多个座位，所以订单和座位之间用一个中间表或者存 JSON，看你的需求）、总金额、状态。订单状态我分了：待支付、已支付、已取消、已退款。其中待支付状态下座位是锁定状态。

最后一张是评分行为表。这挺有意思的——购票系统本身不是视频网站，用户看完电影很少会顺手打分。那协同过滤的数据从哪里来？我当时采用的方案是：**用户每次购买某部电影后，可以主动为该电影评分，前端的“我的观影记录”里出现“评分”按钮。**另外可以做隐式评分，把“看过的电影”当作评分 1，没看过的记为 0。这样虽然简单，但确实能凑出协同过滤所需的“用户—物品”矩阵。如果是演示项目，还可以在管理端写个小脚本批量生成一批模拟用户和评分数据，让算法效果看起来更明显。

2.2 座位状态与订单状态的联动设计

前面提到座位状态和订单状态是强关联的，现在具体展开。一个完整的购票流程是这样的：

1. 用户选场次，看到座位图。此时座位表中该场次的座位状态全部为 0。
2. 用户点了几个座位，点击“确认选座”。
3. 后端收到选座请求，创建一条状态为“待支付”的订单，同时把对应座位的状态改成 1（锁定）。
4. 用户支付成功后，订单状态改为“已支付”，座位状态改为 2（已售出）。
5. 如果用户一直不支付，超过 15 分钟，系统自动取消订单，座位状态改回 0。

这个流程里最容易出的问题是：用户 A 和用户 B 同时选了同一个座位。如果代码不加控制，可能出现两个人各自生成一条订单，座位状态都是锁定，最后两个人都付款了。票务系统里这叫超卖。解决方式后面会专门讲，包括数据库行锁、Redis 分布式锁等手段。

还要注意：如果座位表只记录“每个场次 + 座位”，订单表存的是 JSON 格式的座位列表，那么联动逻辑写起来会比较麻烦。我当时选的是“一张订单对应多个座位记录”的中间表方式，也就是 order_seat 表，里面是 order_id 和 seat_id 的多对多关系。这样座位和订单的关系是明确的，查“某个场次哪些座位已售出”这样的需求也很容易实现。

2.3 索引设计与查询优化心得

表结构搭好之后，索引设计不能忽略。这个系统的核心查询是：根据场次查座位列表、根据用户查订单、根据电影查场次。所以我在 seat 表上建了 (session_id, seat_row, seat_col) 的联合唯一索引，保证同一个场次下不会出现完全相同的两条座位记录；在 order 表上建了 (user_id, status) 联合索引，方便查询用户订单列表；在 schedule 表上建了 (movie_id, show_time) 联合索引，查排片的时候直接走索引。

实际上开发阶段数据量很小，查多慢都看不出来，但索引这个东西是习惯问题，建好了以后放到有真实数据的服务器上也不会出大问题。千万不要觉得自己是演示项目就不建索引，真到了答辩或者演示的时候，数据一多，全表扫描半天才返回，场面是很尴尬的。

3. 协同过滤推荐算法落地的实现细节

3.1 相似度计算：从业务角度理解公式

标题里的“协同过滤算法”是整个项目的亮点，也是容易被敷衍过去的部分。很多人看了几篇教程就直接把 MovieLens 经典代码抄过来，但跟自己的业务数据完全对不上。我们先简单回顾协同过滤的本质。

协同过滤分两种：基于用户（User-Based CF）和基于物品（Item-Based CF）。基于用户的思路是：找到和你口味相似的一批用户，把他们喜欢的、而你没看过的电影推荐给你。基于物品的思路是：找到和你曾经看过的电影相似的电影推荐给你。

不管哪种，核心绕不开“相似度计算”。最常见的相似度计算方式有：余弦相似度、皮尔逊相关系数、杰卡德相似系数。余弦相似度公式长这样：

similarity = (A·B) / (|A| × |B|)

A 和 B 是两个向量。拿电影评分来说，假设有 5 部电影，用户 A 的评分向量是 [5, 3, 0, 4, 0]，用户 B 的评分向量是 [4, 3, 0, 5, 1]，余弦相似度算出来就是两个向量的夹角的余弦值。数值越接近 1，说明方向越一致，口味越相似。

但在购票场景里，大部分用户看过的电影很少，评分向量会非常稀疏，甚至两个用户之间没有共同看过的电影。所以纯余弦相似度会有问题。建议用修正余弦相似度，也就是在计算的时候考虑每个用户的平均评分，相当于先把每个用户的评分向量中心化再求相似度，能减少用户打分手势松紧带来的偏差。

3.2 基于用户的协同过滤实现步骤

我实际落地时，基于用户的协同过滤推荐流程是这样的：

第一步，从数据库读取所有用户的历史评分数据，整理成一个 user_movie_ratings 字典，结构大概是：

user_ratings = { 1: {101: 5, 102: 3, 103: 4}, 2: {101: 4, 103: 5, 104: 2}, }

这里 101、102 代表电影 id，5 和 3 代表评分。

第二步，计算目标用户和其他用户之间的相似度。这里要考虑一件事情：如果两个用户之间没有共同评分的电影，相似度直接设为 0，不用参与后续计算。如果有共同评分，就用修正余弦相似度公式计算。

第三步，找到最相似的 K 个用户，K 一般取 5 到 10。然后把这 K 个用户有评分而目标用户没有看过的电影收集起来。每部候选电影的推荐分数，就是根据相似度加权求和。

第四步，按推荐分数降序排序，取前 N 部电影作为推荐结果，N 一般取 8 到 10。

核心代码大概长这样：

from math import sqrt def compute_similarity(user_a_ratings, user_b_ratings): common_movies = set(user_a_ratings.keys()) & set(user_b_ratings.keys()) if not common_movies: return 0.0 avg_a = sum(user_a_ratings.values()) / len(user_a_ratings) avg_b = sum(user_b_ratings.values()) / len(user_b_ratings) numerator = 0.0 denom_a = 0.0 denom_b = 0.0 for movie_id in common_movies: a_diff = user_a_ratings[movie_id] - avg_a b_diff = user_b_ratings[movie_id] - avg_b numerator += a_diff * b_diff denom_a += a_diff ** 2 denom_b += b_diff ** 2 if denom_a == 0 or denom_b == 0: return 0.0 return numerator / (sqrt(denom_a) * sqrt(denom_b))

这段代码是推荐系统里很核心的一小段。后来我把用户 id 换成整数，方便查字典；电影 id 也统一用整数。如果你从数据库里取出来的是字符串，要注意类型一致，否则 set 取交集的时候会莫名出问题。

3.3 基于物品的协同过滤和混合策略

基于用户的协同过滤实现简单，也符合直觉，它有个问题是：每次给用户推荐，都要实时计算该用户和其他所有用户的相似度。用户数一多，计算量很大。而且新用户几乎没有行为数据，很难找到相似用户。

基于物品的协同过滤解决了一部分问题，因为它的核心假设是“喜欢物品 A 的用户也倾向于喜欢物品 B”，它计算的是电影之间的相似度，而不是用户之间的相似度。电影数量比用户数量稳定得多，相似度矩阵可以离线算好存起来。我当时是两者混着用的：冷启动或行为数据很少的用户走基于物品的推荐，行为数据丰富的用户走基于用户的推荐。实际效果测试下来，混合策略确实比单用其中一种更稳。

基于物品的协同过滤，代码的核心是构造“电影 → 用户评分列表”的倒排表，然后计算电影之间的相似度。具体实现网上有很多模板，但一定要理解倒排表的含义：每个电影对应一个字典，键是用户 id，值是评分，这样两个电影之间共同评分的用户就是两个字典键的交集。

3.4 冷启动问题，怎么处理才像正经项目

冷启动是推荐系统绕不开的问题。再怎么宣传协同过滤多厉害，刚注册的新用户就是没有任何行为数据，算法根本没法推荐。

我采取的方案是分三层：

1. 新用户没有评分数据：推荐模块直接回退到基于内容的推荐，也就是根据电影的“类型”字段匹配。比如用户注册时在偏好页面选择了“科幻、动作”，就推荐这两个类型下综合评分最高的电影。
2. 新电影没有评分数据：因为协同过滤算相似度时需要评分，新电影没评分就谁都不会推荐它。所以要做一个兜底策略：最近上映的、没有评分的新电影，用时间因素加一点热度加权，让它们出现在“新片推荐”区域。
3. 系统整体数据稀疏：初始化时通过管理端批量生成模拟用户数据和评分行为，让推荐模块不至于空转。在项目演示和答辩场景下，这一步非常重要。

其实做推荐系统的关键不在于算法多高深，而在于你如何设计一个完整可用的链路：数据从哪来、算法怎么算、算完结果怎么展示、数据不足时怎么兜底。把这些想清楚，就已经超过大多数只会套公式的做法了。

4. 选座核心逻辑与前后端实现难点

4.1 选座状态机与并发控制

选座这个功能，页面交互很简单，真正的难点全在并发控制上。两个用户同时看到同一个座位是可选状态，同时点击购买，这时候后端的处理方式决定了系统会不会出问题。

最保守、最稳妥的方案是：下单时使用数据库事务 + 行级锁。具体说，在创建订单之前，对选中的座位记录执行SELECT ... FOR UPDATE，把这个场次下这些座位的行锁住。Django ORM 里可以这样做：

from django.db import transaction with transaction.atomic(): rows = Seat.objects.select_for_update().filter( session_id=session_id, seat_id__in=selected_seat_ids, status=0 ) if len(rows) != len(selected_seat_ids): return error_response("座位已被选走") rows.update(status=1) order = Order.objects.create(...)

这段代码的关键在于：select_for_update 获取行锁之后的 update 是原子性的，同一个时刻只可能有一个事务能把这些座位从 status=0 改成 status=1。即使两个人同时提交请求，后执行的一个人会在等锁，等锁结束之后发现 status 已经不是 0 了，所以查询结果条数不够，直接返回“座位已被选走”。

如果项目里用了 Redis，还可以用分布式锁做一层前置保护。锁的 key 设计成lock:seat:{session_id}:{seat_id}，获取锁成功再去查库更新。用 Redis 的好处是：不占用数据库连接资源，对数据库的压力小。但注意 Redis 锁有超时时间的设置，锁超时时间一定要大于下单事务的处理时间，否则锁提前失效会出双卖。

选座的状态机，我在代码里定义成常量，避免到处写魔法数字：

class SeatStatus: AVAILABLE = 0 LOCKED = 1 SOLD = 2

前端座位图根据后端返回的 seat status 来判断显示颜色：可选是灰色、锁定是黄色、已售是红色、当前选中是绿色。注意前端只是展示，真正放不放行购买全得以后端为准。

4.2 Vue 前端选座组件的设计与实现

前端选座是整个系统里交互最复杂的部分。我的做法是用一个二维数组来表示座位图，每一行是一个排，每一列是一个座位号。组件接收一个layout数组，比如：

data() { return { selectedSeats: [], layout: [ { row: 1, seats: [{id: 1, status: 0}, ...] }, { row: 2, seats: [{id: 10, status: 0}, ...] }, ] } }

模板里用两个嵌套的 v-for 渲染整个座位图，每个座位是一个 div，class 根据 status 和是否被选中动态绑定。选座组件里有个局部变量 selectedSeats，用来记录当前用户点选的所有座位 id。每次点击座位，判断这个座位是否可选，可选则切换选中状态，不可选则给出提示。

座位图通常要区分“过道”和“普通排”，过道的位置在 layout 里用一个type字段标记，渲染的时候留空即可。这个细节看起来很琐碎，但真的影响页面美观度。可以给座位图加一个“屏幕”视觉元素，比如一个有渐变背景的横条，观众会知道屏幕在哪个方位，这也是真实影院选座的常见交互语言。

4.3 下单流程与前端路由参数传递

选座确认后，进入订单确认页。这里有几种做法：把座位数据存到 Vuex 里；把座位数据放到路由 query 上；把座位数据存在 sessionStorage 里。我建议用 Vuex 或者 sessionStorage。路由 query 容易被用户手动改掉，也可能因为 URL 过长导致难以处理。用 Vuex 管理，订单确认页刷新后数据会丢失，这个要靠 sessionStorage 做持久化兜底。

下单接口的调用流程是：前端拿到选中的座位 id 列表，调用后端/api/orders/创建订单接口；后端按前面说的锁座位方式创建订单；创建成功后返回订单号和剩余支付时间；前端跳转到支付页面，展示一个倒计时。倒计时结束后如果用户没有支付，前端要主动查询一次订单状态，把界面变成“订单已取消”。我当时在支付页用setInterval倒计时，同时监听页面的 beforeunload 事件，避免用户关掉页面后计时器还在跑的错觉。

4.4 Django REST Framework 的接口设计

接口设计直接按 RESTful 风格来。核心是下面这套路由，项目结构比想象中清爽很多：

• POST /api/auth/register/用户注册
• POST /api/auth/login/用户登录
• GET /api/movies/电影列表
• GET /api/movies/{id}/电影详情
• GET /api/schedules/?movie_id=1按电影查场次
• GET /api/sessions/{id}/seats/查询场次座位状态
• POST /api/orders/创建订单
• POST /api/orders/{id}/pay/模拟支付
• GET /api/recommendations/获取推荐电影

登录认证我用了 DRF 自带的 TokenAuthentication，登录后前端把 token 存在 localStorage 里，每次请求在 header 里带上Authorization: Token xxx。没有 token 的请求如果要访问受保护的接口，后端返回 401。

权限控制这里说一个细节：管理端的接口和用户端的接口一定要分开。Django 的IsAdminUser权限类可以快速实现，如果你懒得分，很可能出现一个普通用户直接调用接口创建场次的情况，这在答辩演示现场是非常尴尬的。

5. 常见问题排查与性能优化实录

5.1 并发选座超卖问题的排查过程

这个问题我印象最深。起初我对 seat 状态更新没有加任何锁，代码是“先查状态，如果可选就创建订单，再更新座位状态”。测试的时候单用户操作一切正常，直到我用并发测试脚本同时起了 20 个线程抢同一个座位。

结果毫无疑问，有好几笔订单都创建成功了，座位状态也乱了。当时分析了一下根因：查状态和更新状态是两步操作，中间穿插了其他请求，导致多个请求同时看到 status=0 然后同时创建订单。

修复方案就是前面提到的事务 + select_for_update 行锁。加上锁之后，我又跑了一遍并发测试脚本，20 个线程抢同一个座位，最终只有 1 个请求创建订单成功，其他全部返回“座位已被选走”。这里有一个点要注意：加锁后要把“查询座位状态”和“更新座位状态”放在同一个事务里。如果先查后改但不在一个事务里，行锁会在事务提交后释放，就会出现两个事务分别查到 status=0 的情况。

5.2 推荐结果不理想的排查思路

推荐模块跑通了，不等于推荐效果好。我当时遇到的问题是：用户已经给 5 部电影打了高分，推荐列表里出现的却是完全无关的电影。排查半天发现是相似度计算时把没有共同评分的用户也算进去了，导致相似度一水的 0 反而成了主要分母。加了“共同评分数量必须大于等于 2”的过滤条件之后，推荐结果才稍微像样。

另一个问题是评分矩阵太稀疏。电影院场景用户很少主动评分，所以推荐结果常常是空的。最后的解法是：管理端写了一个“模拟用户数据生成器”，生成 30 个模拟用户，每人随机看 5-20 部电影并打分。这样推荐模块在任何时候打开都有数据在跑，也方便演示。

还有一个容易被忽略的细节：推荐结果要排除用户已经看过的电影。如果一个人已经看过某部电影，你还推荐给他，体验非常差。做推荐的时候一定要记得把用户历史行为数据过滤掉。

5.3 前端座位图渲染性能优化

一个普通的影厅 10 排 12 列，也就 120 个座位。但如果影厅大一点，比如上有 IMAX 厅，座位数到 400，v-for 嵌套渲染就有点卡了。主要瓶颈不是 DOM 节点数量，而是每次点击座位都触发了整个座位的重新渲染。

我当时把选座组件做了一个优化：把座位状态判断拆成独立的子组件，每个座位格子的状态通过 props 传入。子组件内部只负责展示自己的状态，每次点击只更新自己的 class。Vue 的组件级更新粒度比整个大组件要细很多，实测交互流畅度明显提升。另外座位图渲染时加了一个v-memo指令（Vue 3），把固定的座位布局缓存起来，状态没有变化的座位不会重新渲染。

这里顺便提一下 Vue 版本选择。如果你做的是课程设计或者个人项目，建议直接用 Vue 3 + Vite，因为 Vite 冷启动速度极快，写完代码页面刷新几乎无感，开发体验比 Vue 2 + webpack 强太多。如果你的项目模板还是 Vue 2 的老项目，迁移成本也不高，但既然从零开始，就直接上新版。

5.4 部署与运行环境注意事项

项目做完总得部署给别人看，我这里踩过的一个坑是前后端跨域和静态资源路径。开发时我用 Vite 的代理把/api请求转发到 Django，生产环境里如果直接用 nginx 部署，要注意配置静态文件和 API 的反向代理路径。vue-router 如果用 history 模式，nginx 还需要把非文件请求 fallback 到 index.html，否则刷新页面就 404。

Python 后端这边比较隐蔽的坑是用了 Django 开发服务器跑生产环境。开发服务器是单线程的，并发一上来接口响应速度非常慢，选座时稍微多点请求就卡死。部署时至少要用 gunicorn 起多个 worker，比如gunicorn -w 4 -b 0.0.0.0:8000，四个 worker 同时处理请求，并发能力立刻好很多。

6. 复盘：这个项目值得改进的地方

做完整套系统，我自己最大的体会是：技术框架本身不难，难的是把业务逻辑想周全，以及如何在算法模块和业务模块之间做好衔接。这个项目能扩展的方向还有很多，比较实用的是这几个：

一是接入真实支付网关。现在的支付是模拟的，只要完整体验过一遍创建订单、超时取消订单的流程，接入真实的微信支付或者支付宝支付并没有本质难度，只是需要商户号和签名逻辑。做这一层能大幅提升项目的完成度。

二是增加优惠券和会员体系。影院购票业务里，会员折扣、积分抵扣、优惠券核销是很常见的需求，加进来之后订单模块的复杂度会明显提升，但也会让项目看起来更像一个商业系统，而不是课设。

三是把推荐模块从“离线计算”升级成“实时计算 + 缓存”。我目前的计算是每次请求推荐接口时实时跑一遍协同过滤。数据量小完全没问题，但真到上万用户的时候每个请求都要全量计算，性能会很难看。可以写一个定时任务，比如每天凌晨算一次所有用户的推荐结果，写入 Redis，接口直接从缓存读取。

回到最初的问题，如果你也想做一个 Vue + Python 的项目来锻炼全栈能力，电影院购票选座系统确实是一个综合性强、边界清晰、适合展示的选择。它不像纯后台管理系统那样单调，也不像大模型项目那样对算力有要求，前后端交互、数据一致性、算法落地都有涉及，做完一遍收获是很扎实的。我个人更建议你把“选座并发控制”和“协同过滤冷启动”这两个地方的实现细节想透，然后在答辩或者展示的时候主动讲出来，这比列出再多的页面截图都有说服力。