SpringBoot+Vue+MyBatis+MySQL铁路订票管理系统源码深度拆解

铁路订票管理系统，这个题目在毕业设计和Java学习者圈子里出现频率相当高。我不是第一次见这类项目，但说句实在话，能把一套基于SpringBoot + Vue + MyBatis + MySQL的完整源码写明白、讲清楚，让拿到代码的人不只是会跑起来，而是真正理解每一层在干什么，这样的内容反而不多。

这篇文章我就拿这个项目作为完整案例来拆解。适合什么人看？一是正在做毕业设计、需要一套能讲清楚原理的系统作为参考的同学；二是学过SSM或者SpringBoot基础、想搞明白前后端分离项目完整落地流程的Java学习者；三是打算接私活或者自己搭一套类似的预约/预订类系统的开发者。项目本身解决的是一个很典型的场景：车次信息管理、余票查询、在线订票、订单管理、后台数据维护——这类需求放到酒店预订、电影选座、自习室预约上，核心逻辑完全相通。所以别看是“铁路订票”，拆完之后你会发现，它其实是“预订类业务系统”的一个标准范本。

1. 项目架构拆解与技术选型思路

1.1 为什么是SpringBoot + Vue这对组合

先聊聊技术选型。很多人在做系统设计时会纠结到底用什么框架，其实只要想清楚项目的定位，选择就是顺理成章的事。这个项目定位是“中小型Web管理系统”，不是高并发分布式系统，也不是算法密集型平台，那么技术上就该围绕“开发效率高、结构清晰、容易部署、方便二次开发”这几个目标来选。

后端选SpringBoot，核心原因有三。第一，它解决了Spring早期版本XML配置地狱的问题，一个启动类加几个注解就能把项目跑起来，这对教学项目、毕业设计来说极其友好。第二，SpringBoot内嵌Tomcat，打包成jar就能直接跑，不像传统SSH项目还需要单独装Tomcat、配置一堆环境变量——我见过太多同学在环境配置上耗掉一整天，SpringBoot直接把这条弯路砍断了。第三，SpringBoot的自动装配机制和Starter体系非常成熟，MyBatis有mybatis-spring-boot-starter，MySQL有mysql-connector-j，几乎不需要手动管理依赖版本，这在项目初期的体验是非常舒服的。

前端选Vue，也有很实际的考量。Vue的渐进式特性意味着你不需要上来就掌握TypeScript、状态管理、路由守卫这些全套东西，用一个Vue 3的Composition API加Vue Router、Axios就足够支撑这个项目的界面开发。更重要的是，Vue的组件化开发方式天然适合“页面可以拆模块”的管理系统——车次查询是一个组件、订单列表是一个组件、后台表单是一个组件，各管各的，联调时谁出问题看哪里，清清楚楚。

这套组合在Java类Web项目里已经算是事实标准了。后台API层、前端页面层、数据库存储层，三层各司其职，职责边界非常明确。实际开发中，这种分层最大的好处不是代码量少了，而是出了问题你能迅速定位——接口报错直接查Controller和Service，页面不显示数据先看Network面板再查接口，脑子里有一条清晰的排查链。

1.2 数据持久层选型：MyBatis + MySQL的取舍

持久层为什么用MyBatis而不是Spring Data JPA，这个点我说说自己的看法。JPA用起来确实省事，定义一个实体类加注解，CRUD方法就自动给你生成好了，但它的代价是你得跟着它的约定走。对于“管理查询”需求比较重、SQL经常要自己控制的系统，MyBatis反而更顺手。比如查某个日期段的车次余票，要关联车次表、站点表、余票表，这种多表关联查询在MyBatis的XML里写起来，条件拼接、结果映射你都能精确控制，出了问题也方便调试。

MySQL的选择就更不用多解释了，开源、免费、资料多、社区活跃。对于这套系统的数据量级——几千用户、几百车次、几万订单——MySQL的性能完全足够，配合InnoDB引擎的事务支持，订票、退票这种强一致性操作也能稳稳守住。

这里有个容易被忽略的点：数据库的字符集和排序规则一定要在建库时选好。我的习惯是字符集用utf8mb4，排序规则用utf8mb4_general_ci，别问为什么不用utf8——因为utf8在MySQL里存不了emoji和一些特殊字符，虽然车次信息里不一定有emoji，但用户填写的备注信息就不好说了，直接用utf8mb4一步到位，避免后面数据写入报错。

1.3 项目整体目录结构与工程规划

拿到一套完整源码，先别急着点运行，第一步要看懂工程结构。这个项目的后端标准Maven结构大致是这样的：

railway-ticket-backend ├── pom.xml ├── src/main/java/com/railway │ ├── controller # 控制层，接收前端请求 │ ├── service # 业务层，处理核心业务逻辑 │ ├── mapper # MyBatis数据访问接口层 │ ├── entity # 实体类 │ ├── common # 通用返回结果、异常处理 │ └── config # 配置类，比如CORS配置、拦截器配置 ├── src/main/resources │ ├── mapper # MyBatis XML文件存放目录 │ ├── application.yml │ └── static

前端工程结构一般是Vue CLI或Vite创建的标准结构，核心目录是src/api（接口请求统一封装）、src/router（路由配置）、src/views（页面组件）、src/components（公共组件）。我在接手别人的项目时，有个习惯动作：先看application.yml，再看pom.xml，然后看数据库脚本文件。这三样东西能让你在最短时间内搞清楚项目用了什么依赖、连的什么库、有哪些表——比一头扎进代码里逐个文件看效率高太多了。

2. 系统的核心功能模块与数据库设计

2.1 用户端和管理端的功能边界划分

一个完整的铁路订票系统，功能上分两条线：用户端操作和管理端维护。划分功能边界的价值在于，你写代码的时候知道哪些Controller是给前台用户用的，哪些是给管理员用的，避免权限和接口混在一起。

用户端核心功能包括：用户注册与登录、车次查询（按出发地、目的地、出发日期筛选）、在线订票、我的订单列表、订单详情查看、退票操作。管理端核心功能包括：管理员登录、车次信息管理（增删改查）、站点信息管理、用户订单管理（查看、统计）、基础数据看板（比如订单量趋势、热门车次排行）。

这两条线在数据库层面其实共用一套表，区别主要在接口的权限控制上。管理端的接口需要校验管理员身份，用户端接口需要校验登录状态。因此我在设计时会把管理员功能独立出一个AdminController包，跟用户的UserController分开，一方面代码组织更清晰，另一方面做权限过滤也方便——一个拦截器直接拦截/admin/**路径即可。

2.2 核心数据表设计与字段规划

数据库表的设计是整个系统最基础也最重要的部分。表设计得不好，后面写SQL时你会不停地骂自己。这个系统的核心表大概有六张：用户表、车次表、站点表、余票表、订单表、管理员表。

用户表重点关注的是：除了用户名密码，要存手机号和身份证号（订票系统这两项是必填的，因为购票实名制是业务硬性要求）。密码字段不建议明文存储，后面我会专门说加密方案。

车次表是最核心的表，字段大致是：车次编号（比如G1024）、始发站ID、终点站ID、发车时间、到达时间、运行时长、票价、车厢数、座位类型。这里有个细节要注意：出发站和到达站不应该直接存站名的字符串，而应该存站点表的ID，然后通过关联查询查出站名。为什么这么做？因为站名可能发生变化（比如站名调整），如果你在车次表里存的是“北京南”这个字符串，改一次站名你就要同步更新所有关联车次的数据，而存ID只需要更新站点表里那一条记录，其他不用动。

余票表的设计是关于“按日期”维度的：车次每天都有余票，所以一张余票记录要关联车次ID、乘车日期、座位类型、剩余票数。用(train_id, travel_date, seat_type)做唯一索引，防止同一车次同一天同一座位类型出现多条记录。这张表的命名我建议用train_stock（库存）而不是ticket，因为从业务语义上讲，它表示的是“可售票存量”，不是“已售出票”。

订单表设计有几个关键点：订单编号要唯一，建议用时间戳加随机数生成；订单状态字段用整数枚举表示，比如0待支付、1已支付、2已完成、3已退票、4已取消；一个订单要同时存下单用户ID、车次ID、乘车日期、座位类型、购票数量、总金额、下单时间。退票操作就是把这个订单状态改成已退票，同时把对应的余票加回去。

2.3 表关系梳理与外键处理的建议

表与表之间的关系，我在图上画出来大概是这样的：用户表（1）——（N）订单表（N）——（1）车次表，而余票表从属于车次表，站点表从属于车次表的出发站/到达站字段。

很多教材会建议在数据库物理层面建立外键约束，但我在实际项目里通常不这么干。原因很简单：外键约束会影响插入性能，并且在删除数据时容易引发连锁约束问题。项目里表之间的关联关系，通过应用程序的Service层来保障就够了。比如删除一个车次之前，先查一下这个车次下还有没有未完成订单，有就不让删——这种业务规则放在Service层来做，比数据库在物理层面强制约束更灵活，也更容易编写友好的错误提示信息。

提示：建表脚本建议把你设计的表结构、索引、初始测试数据全部写进一个init.sql，一步到位执行。重复执行同一份SQL是会报错的，建议在脚本里加上DROP TABLE IF EXISTS预处理，方便反复调试。

3. 关键业务逻辑与代码实现剖析

3.1 登录鉴权与密码加密方案

登录是整个系统的入口，代码实现上不难，但安全细节不能省。前端把用户名和密码通过POST请求传到后端，后端先按用户名查用户，再把查出来的密码跟用户传入的密码做比对。

但这里有一个绝对不能踩的坑：数据库里存的是明文密码。一旦数据库泄露，所有用户的密码就全暴露了。正确做法是加盐哈希加密，我用的是加盐的MD5。具体思路是这样：用户注册时，系统生成一个随机盐值（比如UUID的前8位），盐值加上密码拼成一个字符串，再对这个字符串做MD5哈希，把哈希结果和盐值都存进数据库。校验登录时，取出盐值把自己算出来的哈希跟库里存的比对。这样就算两个用户密码相同，因为盐值不同，最终的哈希结果也不同，能有效防止彩虹表反查。如果有更高的安全要求，可以用BCrypt，但作为毕业设计和中小型系统，加盐MD5已经够用。

登录成功之后，前后端需要维持会话状态。这里有两种常用方案：Session方案和Token方案。传统方案是用Session，简单直接，SpringBoot设置一个拦截器检查Session里有没有用户信息就行。但前后端分离情况下，跨域请求时Session的Cookie传递处理比较麻烦，有时候Session还容易失效，很多同学栽在这里。我建议用JWT Token方案：登录成功后后端生成一个包含用户ID和用户名的Token字符串返回给前端，前端把Token存在本地（localStorage或Pinia/Vuex），每次请求时放到请求头的Authorization字段里，后端通过拦截器解析Token来识别用户身份。这个方案无状态、跨域友好、前后端分离项目里的主流做法，评分和面试也都好讲。

3.2 余票查询与车次列表的实现细节

余票查询这个功能看起来简单，其实包含了本系统最核心的一段SQL逻辑。用户在前端输入出发城市、到达城市、出发日期，点击查询，前端调用后端接口/train/query，后端要根据这三个条件查出所有符合条件的车次，并附带当天余票情况。

SQL的设计上需要多表关联。车次表存了始发站ID和终点站ID，站点表存了站点名称，余票表要按日期过滤出当天该车次余票。我的实现方式类似下面这样，你可以根据自己的表结构调整：

<select id="queryTrains" resultType="com.railway.entity.TrainVO"> SELECT t.id, t.train_no, s1.station_name AS start_station, s2.station_name AS end_station, t.departure_time, t.arrival_time, t.duration, t.ticket_price, ts.seat_type, ts.remain_tickets FROM train t LEFT JOIN station s1 ON t.start_station_id = s1.id LEFT JOIN station s2 ON t.end_station_id = s2.id LEFT JOIN train_stock ts ON ts.train_id = t.id AND ts.travel_date = #{travelDate} <where> <if test="startStationId != null"> AND t.start_station_id = #{startStationId} </if> <if test="endStationId != null"> AND t.end_station_id = #{endStationId} </if> </where> ORDER BY t.departure_time ASC </select>

这里有几个关键点：第一，出发和到达的条件判断可能为空，所以要用<where>标签配合<if>做动态SQL，只传入有值的条件；第二，站点查询用LEFT JOIN，因为车次信息不会因为关联不到站点就丢掉；第三，余票条件不是硬性条件，所以不能用INNER JOIN否则没余票的车次就查不出来了。这个思维在处理所有“查询、带可选筛选条件”的场景中都通用，你以后写其他项目也能套用。

3.3 订票高并发场景下的数据一致性保障

订票是整个系统中技术含量最高的一个环节，我来仔细讲讲。用户提交订票请求时，后端要做这几件事：校验车次余票数量是否充足、扣减余票、生成订单、返回订单号。问题在于，如果两个用户同时购买同一车次同一日期同一座位类型的最后一张票，两个请求都通过了校验，都去扣减余票，就会造成超卖。

解决这个问题的核心思路是“让扣减余票的操作原子化，并且以数据库的行锁为最终保障”。我用的是SQL层面加上条件判断和数据库行锁的写法。先查一下余票是否大于等于购买数量，但单纯查是不行的，要用SELECT ... FOR UPDATE把查询的这行数据锁住。这样当第一个用户查到余票为2张，扣减1张变成1张并提交事务后，第二个用户的相同查询才会执行，他拿到就是扣减后的1张，再检查1张够不够，不够就提示余票不足。

事务的写法类似这样：

@Transactional(rollbackFor = Exception.class) public Order createOrder(OrderRequest request) { // 1. 锁定余票记录 TrainStock stock = trainStockMapper.selectForUpdate( request.getTrainId(), request.getTravelDate(), request.getSeatType()); // 2. 校验余票 if (stock == null || stock.getRemainTickets() < request.getTicketCount()) { throw new BusinessException("余票不足"); } // 3. 扣减余票 trainStockMapper.decreaseRemainTickets(stock.getId(), request.getTicketCount()); // 4. 创建订单 Order order = new Order(); // 此处生成订单号、设置金额、状态等字段 orderMapper.insert(order); return order; }

这里selectForUpdate对应SQL里的SELECT * FROM train_stock WHERE ... FOR UPDATE。它跟普通select的区别就在于加了行锁，同一个行在事务提交前不会被其他事务修改，也就从数据库层面堵死了超卖的可能性。

另外要注意锁的顺序。在这个代码里，我首先锁定余票记录，然后才去插入订单，最后整体提交。这个顺序很重要，如果反过来，先插入订单再锁余票，并发之下可能出现死锁问题（两个事务各持有一把锁，然后互相等待对方释放）。实际写这个逻辑时，建议先说明“这一步骤是通过数据库锁保证一致性”，再去写具体的插入语句，答辩和面试时逻辑也更顺。

3.4 退票与库存回补的联动处理

退票的业务逻辑相对简单，但容易出现“只改了订单状态忘记恢复余票”的遗漏。退票的操作是：用户发起退票请求，后端校验这个订单属于当前用户、状态是已支付，然后把订单状态改为已退票，同时执行余票表的自增操作。两个操作必须放在同一个事务里，否则要么库存改了订单没改，要么订单改了库存没加，数据就不一致了。

我在设计里让退票也走@Transactional，并在退票方法内部先修改订单状态，再增加库存。如果库存增加失败抛出异常，整个事务回滚，订单状态也不会被改掉。这里再提一个细节：退票退回的钱怎么处理。这个系统可以不接入真实支付，但是订单状态和时间要保留，方便统计。如果是商场积分、余额支付的系统，退票还要同步调用户账户的余额回补逻辑——这也是你将来扩展系统时最值得留意的扩展点。

4. 前端页面开发与联调要点

4.1 Vue项目创建与开发环境配置

前端部分，我以Vue 3 + Vite来讲解。创建项目的方式直接使用Vite官方脚手架：

npm create vite@latest railway-ticket-frontend -- --template vue cd railway-ticket-frontend npm install npm install vue-router axios element-plus

Element Plus这个UI组件库强烈建议引入。车次查询表格、订单状态标签、后台表单这些都用得上，做出来的界面远比手写的原生样式整洁，而且它有完善的表单校验，管理端的体验会舒服很多。

启动开发服务器之后，前端默认跑在5173端口，后端SpringBoot跑在8080端口，这就涉及跨域问题。跨域可不是小问题，我在调试中遇到的最常见的错误就是“请求发送成功但浏览器拦截了响应，Network里出现CORS error”——前端报错，后端日志却什么都没打。解决跨域我推荐在后端做全局配置，让后端同意前端的跨域请求，这样前端不用做太多特殊处理。一个简单的CORS配置类就能解决：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

如果你用的是JWT方案，allowCredentials(true)和头部设置Authorization要同时用，就会出现预检请求被拦截的问题。这一块配好后，前端就不再单独配代理，开发联调体验会好很多。

4.2 接口请求封装与路由权限控制

前端的Axios请求要统一封装，不要每个页面都直接写axios.get(...)。封装的目的是统一处理三个事情：请求头自动带Token、响应错误码统一提示、请求加载动画统一显示。我的推荐最小封装方案是这样的：

import axios from 'axios' import { ElMessage } from 'element-plus' const request = axios.create({ baseURL: 'http://localhost:8080/api', timeout: 10000 }) // 请求拦截器：自动附带token request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = token } return config }) // 响应拦截器：统一处理业务错误 request.interceptors.response.use( response => { return response.data }, error => { ElMessage.error(error.response?.data?.message || '网络异常') return Promise.reject(error) } ) export default request

然后每个模块对应的API接口单独整理到一个文件里，比如src/api/train.js里放车次相关的所有请求方法，src/api/order.js里放订单相关的。这样以后改接口地址就不用一个页面一个页面去翻代码，直接去对应的API文件改baseURL和参数即可。

路由权限控制这一块，很多人忽略。实际这个项目比较好实现的方式是：在路由配置里给管理端的路由加一个meta: { requiresAdmin: true }标记，然后在Vue Router的前置守卫里判断。如果用户访问的路径需要管理员权限，但当前登录用户的角色不是管理员，就跳转回登录页并提示“无权限”。这才是前后端分离项目的标准做法——前端控制“界面显示层面”的权限，后端控制“数据操作层面”的权限，两层都做才能安全。

4.3 页面对接联调时最容易翻车的三个地方

前端和后端联调，我自己踩过的坑都可以整理成一张清单了。拣三个最常见的说。

第一个是后端返回的时间字段格式问题。Java后端默认返回的日期格式是yyyy-MM-dd HH:mm:ss，但如果你配置了Jackson的默认格式不对，或者用了LocalDateTime没做格式化处理，前端拿到的可能是一串时间戳，渲染到页面上就是“1698400000000”这种谜之数字。处理方式是在application.yml里配好统一的日期格式，或者在后端实体类的日期字段上加上@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")。

第二个是前后端字段名不一致。比如后端实体类里是camelCase的trainNo，数据库列名是train_no，MyBatis的结果映射如果没开启驼峰映射，前端拿到的字段名就会带下划线。解决方式很简单，在application.yml里开启MyBatis的驼峰映射配置：

mybatis: configuration: map-underscore-to-camel-case: true

开启后，train_no自动映射到trainNo，不用再手写一堆resultMap了。

第三个是前端提交的数据类型不对。比如车次票价是个BigDecimal，前端input框里拿到的是字符串，如果你直接通过Axios发送到后端，后端接收时若没做好类型转换，就会出现类型不匹配的400错误。这类问题看后端日志里的异常信息就知道了。我的建议是前端筛选表单提交前先把数值型字段做一次转换，把可控性掌握在自己手中。

5. 项目部署运行与常见问题排查

5.1 本地快速启动完整流程

拿到这套源码后，本地启动其实就三步：装依赖、建数据库、启动前后端。我按顺序慢慢说，跟着操作就行。

第一步是环境准备。需要安装JDK 8及以上版本、Maven、Node.js。JDK版本不用追求最新，我用的是JDK 8配SpringBoot 2.x，稳定没坑。Node.js建议装16.x或18.x的LTS版本，防止新版本对老项目有兼容性问题。

第二步是初始化数据库。新建一个数据库，名字可以叫railway_db，然后执行项目里的init.sql脚本。MySQL连接信息要去后端工程的application.yml里改，重点检查三个地方：数据库地址、用户名、密码。我把配置写在下面做示范：

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/railway_db?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

这里特别说一下serverTimezone=Asia/Shanghai必须配置，否则MySQL 8配JDBC驱动时经常报时区错误。useSSL=false也很关键，如果你本地的MySQL没有配置SSL证书，这里开着SSL就会报SSL连接错误——这个错误在搜索热词里出现了，说明很多人在踩。如果还报了Public Key Retrieval is not allowed这个错，在url后面再加一个参数allowPublicKeyRetrieval=true。

第三步是启动后端。在项目根目录执行：

mvn spring-boot:run

看到类似Started Application in x.xxx seconds的日志就说明启动成功了。启动失败最常见的两个原因，一是8080端口被占用，改application.yml里的server.port即可；另一个是数据库连接失败，重点排查刚才配置的账号密码是否正确。

第四步是启动前端。先npm install装依赖，再npm run dev启动开发服务器。浏览器访问Vite打印出来的地址，即可进入系统首页。

5.2 常见问题速查表

我整理了项目运行中最高频的几个问题，都是曾经有同学反复问过的，放在一起方便对照排查：

5.3 从“能跑”到“有亮点”的项目扩展方向

如果你打算拿这套系统做毕业设计或者面试项目，我建议在原有功能之上做三件低成本高回报的扩展。第一件，增加图表统计。管理端首页加一个订单量趋势折线图和热门车次排行榜柱状图，前端用ECharts，后端加一个统计查询接口，难度不高但整体项目的表现力能上一个台阶。第二件，引入Redis做缓存。车次查询接口通常是高频接口，每次查数据库虽然数据量不大，但并发上来后还是会有压力。把热门线路的查询结果缓存在Redis里，设置缓存过期时间，能很好地体现你对性能优化的思考。第三件，增加通知功能。用户订票成功后，向用户发送一条站内信或模拟邮件通知，后端用Spring的事件机制，前端在页面右上角做一个未读消息角标——这个功能能侧面展示你对业务闭环的理解。

但这里有一个原则：扩展功能之前，先把主体业务的代码彻底看懂、能独立讲清楚，再去添加附加功能。我见过太多同学代码跑起来了，问他“订票为什么不会超卖”答不上来，问他“MyBatis的#{}和${}有什么区别”也答不上来。系统能跑只是结果，理解其中的原理才是你做完这个项目真正收获的东西。

5.4 答辩和求职面试中值得提前准备的追问

如果你拿这套系统去答辩或者面试，大概率会遇到几个追问，我提前列出来，你可以对着自测一下。

第一问：为什么用MyBatis而不是MyBatis-Plus或JPA？答“因为MyBatis灵活，SQL可控”还不够，建议补充一句：“在余票扣减这种需要精确控制SQL以使用行锁的场景下，MyBatis的XML能让我清晰知道最终执行的SQL长什么样，而框架自动生成的通常不够透明。”第二问：如果好多用户同时抢一张票，怎么保证不超卖？这个问题考察的是并发控制，你要答出行锁的思路，而不是只答“用synchronized锁住方法”——单机多线程场景下synchronized还有一定作用，但前后端分离部署多个实例时它就失效了，数据库行锁才是跨实例通用的最终防线。第三问：Cart和订单表为什么分开设计？答：车次信息不等于订单信息，车次是静态基础数据，订单是用户和车次发生交易行为的记录，它们变化频率不同、归属主体不同，分开设计更容易维护和扩展。

这三个追问如果你能对答如流，说明你已经不只是“会写代码”，而是真的理解了系统的设计逻辑。这也是做完整源码项目最有价值的部分——代码可以复制，理解需要自己沉淀。

我个人习惯是给每个核心模块都画一张简单的时序图（用文字或者UML工具画都行），从用户点击按钮开始，到前端请求、后端Controller接收、Service处理、Mapper操作数据库，再到逐层返回。你能把一条链路的每一步讲清楚，这个项目才真正变成你自己的东西。这套系统里订票链路、退票链路、登录鉴权链路，就是三条最值得画的链路。画完之后，无论答辩、面试还是将来做类似的预约系统，你都会游刃有余。