我做这种“毕设求助”的活儿已经很多回了，每次聊到“音乐厅订票系统”，脑子里都会自动蹦出一套固定组合：Spring Boot 做后端、Vue 做前端页面、MySQL 存数据。只要这三样安排扎实，一个演示流畅、逻辑完整的教务管理系统基本就能立起来。最近帮人梳理了一个“阳光音乐厅订票系统管理平台”，我觉得它的定位特别适合两类人：一类是正在为毕设选题发愁的学生，另一类是刚学完 Java Web、想找个全栈项目练手的新手。今天我就把这个项目的整体思路、表结构设计、关键接口、前端联调注意事项，以及我实际跑代码时踩过的坑，一次性拆开讲清楚。
1. 项目整体拆解：音乐厅订票系统为什么经久不衰
1.1 业务链路简单，但覆盖的技术点足够广
音乐厅订票系统的核心链路其实并不复杂：管理员维护演出信息，用户在页面上浏览演出、选座、下单，后台处理订单和基础统计。这个链路没有电商那种复杂的促销规则，也没有库存扣减的多仓协同问题，但它完整覆盖了一个 Web 系统该有的东西：
| 场景 | 涉及功能 | 对应技术点 |
|---|---|---|
| 用户进入系统 | 注册、登录、退出 | 表单校验、JWT 或 Session |
| 用户浏览演出 | 演出列表、详情、搜索 | 分页查询、条件查询 |
| 用户选座下单 | 座位图、锁定座位、生成订单 | 状态机、事务 |
| 用户查看订单 | 待支付、已支付、退票 | 订单状态流转 |
| 管理员维护 | 演出上架、场地管理、价格设置 | 后台 CRUD |
| 统计报表 | 订单数、营收、热门演出 | 聚合查询、图表展示 |
这六个场景做下来，Spring Boot 的 Controller/Service/Mapper 分层、Vue 的组件化开发、MySQL 的表关系和索引设计，全部都能过一遍。老师答辩时问“你这个项目有什么难度”，你也拿得出东西来。
1.2 双角色权限设计，演示效果拉满
这个项目最出效果的地方是角色区分。用户端和管理员端虽然可以做成同一个系统，但界面上一定要分开。我的建议是做成两套布局：用户端走简洁购票风格，管理员端走表格密集风格。
用户端页面一般是：
- 首页 Banner + 热门演出推荐；
- 演出列表页（支持按时间、场馆筛选）；
- 演出详情页（演出简介、场次时间）；
- 选座页（核心页面，座位图点选）；
- 订单确认页和支付结果页；
- 个人中心（订单列表、退票操作）。
管理员端页面一般是：
- 登录后进入 Dashboard，显示今日订单量、总营收、用户总数；
- 场馆管理：维护音乐厅的座位排布，比如 A 区 10 排每排 20 座；
- 演出管理：新建演出场次，关联场馆，设置开售时间；
- 订单管理：查看所有订单，标记已入场或处理退票；
- 票价管理：按区域设置不同价位，比如 VIP 区 580 元、普通区 280 元。
把这两个角色分开后，演示的时候先以普通用户注册账号买一张票，再切管理员登录看到订单数据，整个闭环就通了。
2. 技术选型背后：为什么偏偏是 Spring Boot + Vue + MySQL
2.1 后端选 Spring Boot，不是因为它花哨，而是因为省心
很多同学在 Spring Boot 和 Spring MVC 之间纠结过。我的看法很直接：如果你的项目已经决定用 Java，那就直接上 Spring Boot。它内置 Tomcat，打包成 jar 后一条命令就能启动，省去了传统 Web 项目配置 Tomcat、配置各种 XML 的麻烦。这对毕设来说太重要了，因为你在答辩现场最怕的就是环境起不来。
再配合 MyBatis-Plus，单表的 CRUD 几乎不需要写 SQL。你只要定义一个实体类对应数据库表，继承一个 BaseMapper，分页查询、条件查询、逻辑删除这些方法就都有了。对我来说，这能把开发时间压缩掉三分之一，剩下的时间去打磨前端页面和答辩 PPT，比什么都值。
2.2 前端选 Vue，根本原因是“组件化开发”真的香
我最早做管理系统用的是 JSP + Bootstrap，每个页面都是独立的 JSP，公共导航栏复制粘贴，改一个菜单要在十个文件里同步。后来换成 Vue，才算体会到什么叫“写一次，处处用”。
比如音乐厅的座位图，最适合做成一个独立的 Vue 组件。你只要给它传入场馆的排数和列数，它就渲染出整个座位矩阵；用户点击某个座位，组件内部自己维护选中状态；组件再把选中的座位信息抛给父页面。这种解耦方式让代码清晰很多。
另一个实际好处是，Vue 生态里有 Element Plus 这种现成的 UI 组件库，表格、分页、表单、弹窗都封装好了。学生不需要有很强的 CSS 功底，也能做出一个看起来很专业的后台界面。这个优势对于时间紧的毕设来说，是实打实的。
2.3 MySQL 在这个量级下是最稳的选择
音乐厅订票系统本质上是一个并发量很低的管理系统，MySQL 完全够用。对于学生项目来说，MySQL 最友好的地方是资料多，遇到问题一搜就有答案。数据库客户端我推荐先用 Navicat 或 DBeaver，图形化操作建表建库，直观且出错少。
如果你的版本选的是 MySQL 8.x，有一点要特别提一下：8.x 默认的认证插件是 caching_sha2_password，一些老版本的连接驱动和它不兼容。Spring Boot 2.7 之后自带的 mysql-connector-java 已经兼容了，但如果你用了非常老的项目模板，连接数据库时报 “Public Key Retrieval is not allowed” 或者 “Unable to load authentication plugin”，优先想到的就是认证插件问题。
3. 数据库表和业务状态：把核心模型一次想清楚
3.1 五张核心表的设计思路
我见过很多学生一上来就建十几张表，看起来工程量很大，实际上很多表之间根本没有关联，纯粹是堆字段。真正的音乐厅订票系统，核心就五张表。
第一张是用户表sys_user：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| username | varchar(50) | 登录账号 |
| password | varchar(100) | BCrypt 加密后的密码 |
| role | tinyint | 0 普通用户，1 管理员 |
| nickname | varchar(50) | 显示昵称 |
| phone | varchar(20) | 手机号 |
| create_time | datetime | 注册时间 |
密码这里我会特别强调一点：千万不要明文存储。哪怕课程设计要求不高，答辩老师问到“你的系统安全吗”的时候，你拿出 BCrypt 加密，就是加分项。Spring Security 里自带 BCryptPasswordEncoder，不用它白不用。
第二张是场馆表venue：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| name | varchar(100) | 场馆名称 |
| address | varchar(255) | 场馆地址 |
| seat_rows | int | 总排数 |
| seat_cols | int | 总列数 |
| create_time | datetime | 创建时间 |
第三张是演出场次表show，注意它和场馆是多对一的关系：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| venue_id | bigint | 关联场馆 |
| show_name | varchar(200) | 演出名称 |
| start_time | datetime | 演出开始时间 |
| status | tinyint | 0 未上架，1 售卖中，2 已结束 |
| cover_url | varchar(255) | 封面图地址 |
| description | text | 演出简介 |
第四张是座位表seat，这是整个系统的灵魂。我不建议用“剩余票数”这种模式来做座位管理，因为音乐厅的座位是一个个具体的物理座位，你需要精确到“第几排第几列”，所以座位表要单独建：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| show_id | bigint | 关联演出场次 |
| row_no | int | 排号 |
| col_no | int | 列号 |
| seat_type | varchar(20) | VIP / 普通 / 经济 |
| price | decimal(10,2) | 对应票价 |
| status | tinyint | 0 可售，1 锁定，2 已售 |
这里有个设计差异要说清楚：同一场演出，每个座位就是一条记录。比如一个场馆有 10 排每排 20 座，那这场演出就有 200 条座席记录。场次上架时，系统根据场馆的排布自动批量生成座席。这种做法最大的好处是，每张票天然就是一个原子座位，不会出现“库存减了但座位冲突”的问题。
第五张是订单表order_info：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| order_no | varchar(32) | 订单编号 |
| user_id | bigint | 下单用户 |
| show_id | bigint | 演出场次 |
| ticket_ids | varchar(255) | 购买的多张座席 ID，逗号分隔 |
| total_amount | decimal(10,2) | 总金额 |
| status | tinyint | 0 待支付，1 已支付，2 已取消，3 已退票 |
| create_time | datetime | 下单时间 |
| pay_time | datetime | 支付时间 |
很多同学会纠结一个订单对应多个座位，那要不要拆成订单主表和订单明细表？我的建议是：对于毕设项目，不需要。你直接用ticket_ids字段存一个逗号分隔的字符串，逻辑简单，查询也方便。如果你要把项目写得更“企业级”，再考虑拆order_info和order_detail一对多结构，但那是锦上添花，不是必需。
3.2 订单状态机和座位状态如何联动
座位状态是整个系统的核心状态机。用户选座时，前端把座位 ID 传到后端，后端需要在一个事务里完成两件事：
- 把座位的状态从“可售”改成“锁定”；
- 创建一个“待支付”的订单。
如果用户一直不支付，订单超时后要释放座位，把座位状态从“锁定”改回“可售”。很多学生的项目里没有做超时释放，结果就是用户下了单不付款，座位永远被占着。我的建议是加一个定时任务，每五分钟扫描一次待支付订单，超过 15 分钟未支付的就自动取消、释放座位。Spring Boot 里用@Scheduled注解很简单，演示的时候也可以主动介绍一下这个设计，老师会觉得你考虑得很周全。
订单的支付动作本身也不需要真的接支付宝或微信，做一个模拟支付按钮就行——点击支付，把订单状态改成“已支付”，座位状态改成“已售”。如果要做真实支付，那个复杂度就上去了，需要商户号、回调地址、签名验签，对学生项目来说没必要。
3.3 防超卖的关键：条件更新而不是先查再改
讲到并发问题，我多说一句。选座场景下，两个用户同时点击同一个座位，理论上可能都创建订单。最简单可靠的办法是用一条带条件的 UPDATE 语句：
UPDATE seat SET status = 1 WHERE id = ? AND status = 0;如果这条 SQL 影响的行数为 0，说明座位已经被别人抢占了，后端直接返回“座位已被选”。这种方式在数据库层面保证了原子性，不需要复杂的分布式锁。你先查一次再 update 的写法，中间有并发窗口，容易出问题，哪怕在本地测不出来，答辩时也要注意别给自己挖坑。
4. 后端代码组织与关键接口实现
4.1 包结构这样建，先赢一半
很多学生建项目时包名乱起，controller、service、dao混在一起。我推荐的标准结构是这样：
com.example.sunnymusic ├── common // 统一返回结果、全局异常 ├── config // 跨域配置、MyBatis-Plus配置 ├── controller // 接口层 ├── service │ └── impl ├── mapper // 数据访问层 ├── entity // 实体类 ├── utils // JWT工具类 └── MusicApplication.javacommon包下要放一个统一返回类，比如Result<T>，包含 code、msg、data 三个字段。不管接口成功还是失败，返回结构都保持统一。前端 Axios 拦截器只需要根据 code 判断后端的处理结果就行。这个习惯你在校招面试的时候写项目也会用到，属于职业级的基本功。
4.2 JWT 登录认证怎么落地
用户登录成功后，后端生成一个 JWT token 返回给前端。前端的 Axios 拦截器把 token 放到请求头的Authorization字段里。后端写一个拦截器，判断非白名单路径的请求是否携带合法 token。
白名单一般包括：
/api/user/login/api/user/register/api/show/list/api/show/detail
拦截器的逻辑很简单：
public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (StringUtils.isBlank(token)) { throw new BusinessException("未登录"); } if (!JwtUtil.verify(token)) { throw new BusinessException("登录已过期"); } return true; } }然后在 WebConfig 里注册这个拦截器，设置excludePathPatterns排除登录注册和演出列表这些公开接口。
还要配套一个全局异常处理器@RestControllerAdvice，把 BusinessException 里的中文信息直接返回给前端。这样前端弹窗提示也方便，后端也不会有满屏的堆栈错误。
4.3 演出列表页的分页与条件查询
演出列表页通常要支持按“演出名称”模糊搜索、按“演出状态”筛选、按“演出时间”排序。用 MyBatis-Plus 的分页插件，写出来大概是：
Page<Show> page = new Page<>(current, size); LambdaQueryWrapper<Show> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.isNotBlank(keyword), Show::getShowName, keyword) .eq(status != null, Show::getStatus, status) .orderByDesc(Show::getStartTime); Page<Show> result = showMapper.selectPage(page, wrapper);注意like的写法，第一个参数是条件，条件不成立就不会拼这个 SQL，不会出现参数为空时查不到数据的问题。后端返回给前端的时候，把total、records两个字段带上，前端分页组件直接消费。
4.4 选座下单的事务控制
下单接口我建议放在OrderService里，用@Transactional注解控制事务：
@Transactional(rollbackFor = Exception.class) public Result createOrder(Long userId, Long showId, List<Long> seatIds) { // 1. 锁定座位，如果任何一个锁定失败，直接回滚 for (Long seatId : seatIds) { int rows = seatMapper.lockSeat(seatId); if (rows == 0) { throw new BusinessException("座位已被锁定"); } } // 2. 计算总价 // 3. 创建订单 // 4. 返回订单号 }这里一定要加rollbackFor = Exception.class。如果不加，默认只有 RuntimeException 才会回滚，某些受检异常可能不会触发事务回滚，会导致座位锁定了但订单没创建成功，这个 bug 特别隐蔽，属于经典坑。
5. 前端 Vue 工程的关键交互点
5.1 路由规划和页面骨架
Vue 工程里我习惯把页面分成两块布局：UserLayout 和 AdminLayout。路由用懒加载方式引入页面组件，减少首屏包体积。
{ path: '/admin', component: AdminLayout, meta: { requiresAuth: true, role: 'admin' }, children: [ { path: 'dashboard', component: () => import('@/views/admin/Dashboard.vue') }, { path: 'show', component: () => import('@/views/admin/ShowManage.vue') }, { path: 'order', component: () => import('@/views/admin/OrderManage.vue') } ] }路由守卫里处理登录判断：
router.beforeEach((to, from, next) => { if (to.meta.requiresAuth && !localStorage.getItem('token')) { next('/login') } else { next() } })配合路由守卫，管理员的菜单就能和用户端分开。这也是前端架构里值得在答辩中展开讲一下的部分。
5.2 Axios 拦截器：统一处理 token 和错误提示
前端封装 request.js 时，拦截器的价值很大。请求拦截器把 token 塞进 header，响应拦截器统一处理业务码和网络错误：
axios.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = 'Bearer ' + token } return config }) axios.interceptors.response.use( res => { if (res.data.code === 401) { localStorage.removeItem('token') router.push('/login') } return res.data }, err => { ElMessage.error(err.response?.data?.msg || '网络异常') return Promise.reject(err) } )这里有个细节：后端响应如果统一是{ code, msg, data }，前端就可以在响应拦截器里直接return res.data，各个接口拿到的直接就是业务数据，不用在每个页面里再套一层res.data.data。少写一层是一层，代码整体会清爽很多。
5.3 座位组件怎么写
座位图是前端最复杂的部分，我用一个SeatMap.vue组件来承载。组件接收showId和场馆排数列数，进入页面后调用接口拉取该场次的全部座席状态。
渲染核心逻辑是双层循环：
<div v-for="row in seatRows" :key="row.rowNo" class="seat-row"> <div v-for="col in row.seats" :key="col.id" class="seat" :class="seatClass(col)" @click="toggleSeat(col)" > {{ col.rowNo }}排{{ col.colNo }}座 </div> </div>座位的三种状态对应三种样式：
- status=0，可售：灰白色，点击后可选中；
- 选中状态：蓝色，记录在组件的 selectedSeats 数组里；
- status=1 或 2，锁定或已售：灰色禁止点击，加叉号。
组件把选中座位事件通过this.$emit('change', selectedSeats)抛给父页面，父页面在底部展示“已选 X 个座位，合计 Y 元”。
这里有一个经验点：底部结算栏最好固定或者吸底，不然用户选了十几个座位之后还要往上滚动才能看到付款按钮，体验会很差。Element Plus 的布局加上一个position: sticky就能解决。
5.4 时间格式化的通病
后端返回的时间一般是"2025-06-18T20:00:00"这种格式，直接显示在页面上又长又不友好。前端统一用 dayjs 格式化：
import dayjs from 'dayjs' dayjs(value).format('YYYY-MM-DD HH:mm')我建议在 utils 里封装一个全局格式化函数，避免每个页面都写一遍。还有一个细节，后端如果返回的是时间戳，前端要new Date(timestamp)之后再传给 dayjs，否则在部分环境会报格式错误。
6. 本地跑起来全过程与踩过的具体坑
6.1 环境要求清单
我的建议配置如下：
| 组件 | 版本建议 | 说明 |
|---|---|---|
| JDK | 1.8 或 17 | 二选一，不要用 19/21 这种太新的版本 |
| Maven | 3.6+ | 配置阿里云镜像，否则下载依赖要等很久 |
| Node.js | 16+ | 推荐 16 或 18，Vue3 工程用 14 也凑合 |
| MySQL | 5.7 或 8.0 | 建议 8.0，但对字符集和认证方式注意 |
| IDE | IDEA + VS Code | 后端用 IDEA，前端用 VS Code |
如果你的 Spring Boot 版本选的是 2.7.x，那配合 JDK 8 最稳妥。选 3.x 版本的话，JDK 必须是 17+，这个对应关系一定要提前确认，我见过好几个同学拿着 Spring Boot 3 的项目配 JDK 8，启动直接报错。
6.2 启动顺序和配置细节
第一步，启动 MySQL 服务，创建一个数据库，注意字符集选 utf8mb4，不然有些生僻字符或 emoji 存入会报错。
第二步，后端 application.yml 配置：
server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/sunny_music?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: yourpassword mybatis-plus: configuration: map-underscore-to-camel-case: truemap-underscore-to-camel-case这个配置要打开，数据库字段create_time就可以自动映射成 Java 实体里的createTime，不用每个字段写 @TableField 注解。
第三步，启动后端，看到 Spring Boot 的启动日志，没有报错就说明接口层通了。
第四步，前端目录下执行：
npm install npm run devVite 默认端口是 5173，但如果你后端端口是 8080，前后端联调时要处理跨域问题。跨域有两个方案：
一种是在后端加全局跨域配置：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowCredentials(true) .maxAge(3600); } }另一种是在前端 Vite 配置 proxy：
server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }实际开发里我更推荐第二种，配置在前端，后端不用放开跨域，部署到生产也不容易出问题。但要注意，如果开发阶段用代理，axios 的 baseURL 要写成/api，不要写完整域名。
6.3 我印象深刻的几个报错
先说前端最常见的：Failed to load tsconfig '@vue/tsconfig/tsconfig.web.json'。这个一般是因为工程模板里引用了@vue/tsconfig包，但你本地没有安装或者版本不对。解决办法是在前端工程目录里执行一次npm install -D @vue/tsconfig，或者干脆新建项目时直接用 Vite 官方模板，别用 GitHub 上那种老工程的配置。
再说后端最常见的：启动时提示数据库连接失败，十有八九是serverTimezone没配，或者 MySQL 服务没启动。Windows 下 MySQL 服务名一般叫mysql，用管理员权限进入 CMD 执行：
net start mysql如果是 MySQL 8.x 还报Public Key Retrieval is not allowed，在 JDBC URL 后面拼上allowPublicKeyRetrieval=true就行。
还有一个频率很高的坑，是前端 npm install 报权限错误。Windows 上直接报EPERM的话，把 node_modules 目录删掉重装，或者用管理员身份运行终端。npm 下载太慢的，就换淘宝镜像：
npm config set registry https://registry.npmmirror.com6.4 打包部署的注意点
开发环境跑通了之后，毕设演示往往还要打个包。后端用 Maven 打包：
mvn clean package -DskipTests打出来的 jar 包在 target 目录下，直接java -jar xxx.jar就能启动。前端打包：
npm run build生成 dist 目录后，有两种部署方式：一种是由 Nginx 托管 dist 目录，把/api反向代理到后端端口；另一种是直接把 dist 目录放到后端 Spring Boot 的static目录下，让后端同时提供接口和页面。对于毕设演示，第二种最省事，一个 jar 全搞定。
但要注意，如果前端路由用的是 history 模式，刷新页面时会 404。解决办法要么改成 hash 模式，要么在 Nginx 里配置 try_files。我一般直接推荐改 hash 模式，毕设场景下不用纠结。
7. 答辩时怎么讲解这些内容，以及后续还能怎么扩展
7.1 答辩中会被追问的几个问题
每年答辩，老师问的问题来来去去就那么几个。提前做好准备，现场就不会慌。
第一个问题：“为什么选前后端分离？”回答思路是：前端通过接口获取数据，不依赖后端模板渲染，职责更清晰；开发和部署可以独立进行；Vue 组件化让前端代码可维护性更好；页面交互体验优于传统 JSP。
第二个问题：“座位抢购时怎么防止超卖？”回答思路是：座席表的每一行代表一个具体的座位，下单时先用一条条件 UPDATE 锁定座位，WHERE id = ? AND status = 0，影响行数为零就说明座位已被人抢走。这是数据库层面的原子操作，不依赖分布式锁。
第三个问题：“订单超时没支付怎么办？”回答思路是：用了 Spring Boot 的@Scheduled定时任务，定期扫描待支付订单，超过 15 分钟自动取消并释放座位。如果老师继续追问大规模下怎么做，你可以说生产环境会用延迟队列，比如 RabbitMQ 的 TTL 加死信队列，但当前项目通过定时任务已解决目标场景。
第四个问题：“密码怎么保证安全？”回答思路是：BCrypt 加盐哈希，明文密码不落库。BCrypt 每次加密结果不同，即使两个用户密码相同，密文也不一样；即使数据库泄露，密文也无法直接还原。
7.2 后续扩展方向
如果你的毕设想做出亮点，我推荐三个扩展点。
第一个是数据统计可视化。Dashboard 页面用 ECharts 画一个折线图展示近七天的售票趋势、用饼图展示不同区域票价的销售占比。ECharts 和 Vue 组合非常成熟，图表出来的效果直接拉满。
第二个是二维码电子票。支付完成后生成一个带订单号的二维码，入口检票时扫码核销。这个功能用 HUTool 的二维码工具类就能生成，实现成本不高，但演示效果很直观，也贴近真实场景。
第三个是定时释放座位。前面提到的@Scheduled加上一个@EnableScheduling，五分钟扫描一次待支付订单，就能把资源释放逻辑补完整。这个点虽然小，但体现了你对业务的完整思考。
7.3 我的最后一点实在话
做毕设或者课设，最忌讳的是把项目想得太大。音乐厅订票系统的核心就是演出管理、座位管理、订单管理，你把这三件事做扎实，把表结构设计清楚，把前后端接口联调顺畅，就已经是一个能拿得出手的完整项目。反而是那些东加一个聊天功能、西加一个推荐算法的项目，到最后往往哪块都没做完。
我实际操作下来最大的感受是：先从后端接口开始，把五个表的 CRUD 和两个核心接口（锁定座位、创建订单）跑通，再去做前端页面。前端和后端一起写很容易互相干扰，尤其是你还不熟的时候，一旦接口报错就分不清是前端的问题还是后端的问题。先把后端用 Postman 全部验证过一遍，再去写 Vue 页面，整个人会轻松很多。
这个项目做完之后，你对 Spring Boot 的分层结构、Vue 的组件通信、MySQL 的表设计，都会有自己的真实体感，而不是只停留在看教程的阶段。后面如果再想挑战更大的项目，比如秒杀系统或者后台管理系统全家桶，这个项目打下的底子也够你起跳了。
