企业官网建设流程全解析

每年一到毕设开题，电影院票务系统就会成为Java方向出现频率最高的题目之一。我在帮人调试毕设、评审代码的过程中，见过不少同学用Spring Boot + MySQL做完这个系统，有的做得干净利落能直接演示，有的磕磕绊绊到最后还在改表结构。这个题目为什么经久不衰？因为它本质上是一套典型的“用户端 + 管理端”信息管理系统，业务链路完整、技术栈主流、工作量适中，特别适合展现你对Java后端开发全流程的掌握程度。

这篇文章我就把这套系统的完整思路写下来，包括需求拆解、技术选型、数据库设计、核心代码实现、常见报错排查，以及答辩时怎么讲才能拿高分。不论你还在选题阶段，还是已经开题准备动工，按这条线走，能少踩不少坑。

1. 需求拆分：先别急着写代码，把业务捋清楚

1.1 两种角色，一条主线

电影院票务系统，说到底就两块人在用：

• 普通用户（买票的人）：注册登录、浏览电影、按场次选座、提交订单、模拟支付、查看订单记录。
• 管理员（影院运营人员）：维护电影信息、维护影厅与座位、排片（设置场次）、查看订单数据。

不要小看这两类角色，它们之间有严格的依赖关系。管理员先录入电影和影厅，然后基于电影和影厅排出场次，用户才能依据场次买票。很多同学上来就建表写登录，等写到买票环节才发现这个缺字段、那个没关联，最后推倒重来，非常浪费时间。

我把核心流程压缩成一句话：管理员排片，用户买票。所有功能都围绕这条主线展开，就不会跑偏。围绕这句话去设计用例、设计接口、设计页面，都是顺理成章的事。

1.2 什么人适合选这个题目

如果你满足下面任意一条，这个题都值得考虑：

• 主语言是Java，学过Spring Boot但没完整做过一个项目；
• 想在毕设里同时体现数据库设计、项目分层、业务逻辑和前端交互；
• 时间不算特别充裕，需要一个“框架成熟但又有得讲”的题目。

反过来，如果你打算在毕设里上高并发抢票、推荐算法、分布式架构这类深度内容，那经典电影院票务会显得偏单薄，建议换更有区分度的题目。但如果你是想稳妥通过答辩，同时把Java后端开发的底子打扎实，这个题非常合适。

1.3 动手之前，先想清楚三件事

第一，前后端是否分离。这个选择会影响整个工程结构，后面我会专门讲。

第二，支付怎么处理。毕设里不要真的对接支付平台，用模拟支付即可——用户点击“支付”，后端把订单状态从待支付改成已支付，记录支付时间。这一点在文档里要写清楚，不然评委容易较真。

第三，座位锁定策略。这是全系统最值得讲的部分，甚至可以作为答辩时的“项目亮点”。用户选了座位，这期间别人不能再选，具体怎么实现？后文我会给可直接落地的方案。

2. 技术选型：Spring Boot + MySQL是核心，ORM要想清楚

2.1 后端框架版本搭配

主流的毕设组合是：

JDK 1.8，Spring Boot 2.7.x，MySQL 5.7或8.0，ORM框架用MyBatis或MyBatis-Plus，工程构建用Maven。

这几个版本放在一起非常稳。Spring Boot 2.7还在维护窗口期内，JDK 1.8更是生产环境常青树。有些同学一上来就用Spring Boot 3.0 + JDK 17，结果发现第三方组件不兼容，白白浪费时间。如果你以“求稳”为目标，2.7非常合适；如果要用3.0，请先把所有依赖版本对齐，避免启动时一堆ClassNotFoundException。

ORM这块，我更推荐MyBatis-Plus，理由很实际：

• 单表CRUD不需要手写SQL，开发速度快；
• 自带分页插件，列表查询直接搞定；
• 有代码生成器，实体、Mapper、Service能一键生成；
• 核心概念不复杂，答辩时也容易讲清楚。

当然，用原生MyBatis也完全没问题，SQL手写更直观。就看你自己更熟悉哪一套。两种方式在本文核心逻辑上完全通用。

2.2 前端方案：Thymeleaf还是Vue

这是选题时就要定下来的事。两种方案各有利弊，我用一个表格说明：

我的建议是：时间够、想学更多东西，就走Vue前后端分离；图省事、想把精力放在后端与数据库上，就用Thymeleaf。下面我按Thymeleaf方案讲核心实现，因为这样覆盖的知识点最直接；但接口设计和业务逻辑是通用的，分离方案同样适用。

2.3 环境版本建议

一个常见问题是环境版本乱配，导致别人帮你调试都调不动。我建议统一为：

Java 8，Maven 3.6.3，Spring Boot 2.7.14，MySQL 8.0，数据库管理工具用Navicat或Workbench，IDEA版本2021年以后都行。

不要为了追求新特性而用太新的版本，毕设求的是稳。正式开发前先用一个Hello World级别的工程把Maven和JDK配置跑通，再开始写业务代码，能省掉很多启动阶段的环境折腾。

3. 数据库设计：表结构决定你后面写代码是顺还是拧巴

3.1 至少需要这几张表

我见过有同学把座位信息直接塞进订单表，后面越写越乱。老老实实按业务划分表，至少需要这些核心表：

seat表这里有一个设计细节。很多人第一反应是给每个影厅维护固定座位集合，然后通过场次和状态去控制锁定与售卖。但如果seat表上没有session_id，同一个影厅的不同场次之间座位状态会互相干扰，A场次卖了座位，B场次也显示被占。

正确做法是：seat表直接记录“场次+座位坐标+状态”，也就是每个场次生成一份座位副本。status用数字表示：0可售、1锁定、2已售。这样才能做到不同场次的座位状态互不干扰。方案落地后，每个场次下都会有几行到几十行不等的座位记录，查询时按session_id过滤即可。

3.2 关键字段设计细节

密码字段不能存明文。用MD5或者Spring Security自带的BCrypt做加密，答辩时这一点是基础分。order_no订单号用时间戳加随机数生成，比如20250521103012001，同时加唯一索引，防止重复。

金额字段用decimal(10,2)，不要用float或double，否则金额精度会出问题。这个细节在答辩时主动讲出来很加分，说明你理解浮点数的二进制表示缺陷。

movie表里用status区分“上映中”和“已下架”，前端只展示上映中的电影。不要物理删除电影，一个状态位就够了。session表的start_time用datetime，end_time不要单独填，查电影时长后计算得到，避免管理员重复录入。这也是一个体现思考的小设计。

3.3 表关系说明

user和orders是一对多；orders和session是多对一；session和movie是多对一；session和hall是多对一；session和seat是一对多。核心关系都围绕“场次”展开，session表就是整个系统里绝对的中枢。

关于外键，我的建议是不用物理外键，用逻辑外键就够了。物理外键在插入、更新时会有额外校验，分页、批量操作时性能也不好。表关系通过SQL的join体现，这是业界主流做法。被评委问到时也不虚：“外键约束放在应用层控制，保证灵活性和扩展性”。把这句话理解透，答辩时能从容很多。

3.4 索引怎么设

核心查询场景有两个：查电影列表、查场次下的座位。movie表的status和release_date建议建联合索引；session表的movie_id、start_time建组合索引；seat表的session_id必须建索引；orders表的user_id建索引，order_no建唯一索引。

索引不用多，够用就行。很多同学喜欢给所有字段都加索引，结果写入变慢、占用空间，反而被老师问住。你在文档里写清楚“索引是为了解决哪个查询”，这比堆几个索引名有价值得多。

4. 后端核心代码实现：分层清晰，业务逻辑放Service层

4.1 项目目录结构

用Spring Boot标准分层：

src/main/java/com/example/cinema

• controller // 接收请求、参数校验、返回结果
• service // 业务逻辑、事务控制
• mapper // 数据访问接口
• entity // 实体类
• config // 配置类、拦截器注册
• common // 通用返回结果封装、统一异常处理
• util // 工具类

resources下放mapper XML（如果用XML方式）、templates（Thymeleaf模板）、static（css/js）、application.yml。

代码包不要堆成一团。Controller里写几百行SQL，或者直接把Mapper放到Controller里，这种代码答辩基本经不起问。标准做法是：Controller只做参数接收和结果返回，业务放Service，数据访问放Mapper。这样也好测试，也好讲。

4.2 application.yml配置

关键配置示例：

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/cinema_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 thymeleaf: cache: false mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl mapper-locations: classpath*:mapper/**/*.xml

url里必须带serverTimezone=Asia/Shanghai，不配就可能碰到时区报错。characterEncoding=utf8是为了防中文乱码，这两个参数几乎是每次排查必查项。开发时把SQL日志打开，方便定位问题。上线后再关掉。

4.3 登录与权限拦截

Thymeleaf方案用Session比较简单。用户登录成功后把用户信息放进Session，再用拦截器拦截需要登录的路径。拦截器示例：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } return true; } }

然后在WebMvcConfigurer里注册，并放行登录页、注册页、电影列表、场次列表，以及/css/**、/js/**等静态资源。管理员接口还要再校验role字段，单独写一个AdminInterceptor或者直接在Controller里判断，避免普通用户访问管理接口。

如果是前后端分离方案，就用JWT + 拦截器，前端请求头带token。原理是类似的，只是凭证形式不同。核心思路都是“先认证，后放行”。

4.4 电影列表与场次查询

电影列表用MyBatis-Plus分页查询非常简单：

Page<Movie> page = movieMapper.selectPage(new Page<>(current, size), new LambdaQueryWrapper<Movie>() .eq(Movie::getStatus, 1) .orderByDesc(Movie::getReleaseDate));

场次查询要注意过滤掉已过期的场次，否则用户会点进一个已经开演很久的场次。SQL大致是这样：

select s.*, h.hall_name from session s left join hall h on s.hall_id = h.id where s.movie_id = #{movieId} and s.start_time > now() order by s.start_time

这里用left join是为了带出影厅名称，避免再查一次数据库。

4.5 选座、锁座、下单：全系统最核心的流程

用户选座到下单的链路是：

1. 进入选座页，根据session_id查座位列表；
2. 前端渲染座位矩阵，不可售的座位置灰；
3. 用户点选座位，点击“立即购票”；
4. 后端接收session_id和座位ID列表，先校验座位状态；
5. 校验通过后，生成订单，同时把座位状态改为“锁定”；
6. 用户模拟支付，支付成功后座位改为“已售”，订单改为“已支付”；
7. 如果长时间不支付，超过设定时间后释放座位，订单作废。

第5步是整个系统的核心。如果不加控制，两个用户同时点同一个座位，两边都能生成订单，座位就超卖了。最简单的方案是用乐观更新，生成订单时在事务里先update座位状态，再插入订单：

@Transactional public boolean createOrder(Long userId, Long sessionId, List<Long> seatIds) { // 1. 把选中的座位批量更新为“锁定” // 使用乐观条件：只有当前状态为0（可售）才能更新成功 int updated = seatMapper.updateStatus( seatIds, 1, // 新状态锁定 0 // 旧状态可售 ); if (updated != seatIds.size()) { throw new RuntimeException("座位已被锁定，请重新选择"); } // 2. 创建订单 // 3. 返回订单信息 }

update影响行数不等于选座数量，说明至少有一个座位已经被别人抢走，直接抛出异常回滚事务。这比“先select余额再判断”安全得多，也不需要引入Redis。答辩时主动说“我用乐观更新防止并发超卖”，评委基本都会认可。

座位锁定的超时释放，可以写一个定时任务，每两分钟扫描一次超过锁定时限的订单，把对应座位恢复成可售。用Spring自带的@Scheduled就行，启动类上加上@EnableScheduling。注意订单状态用数字状态码：0待支付、1已支付、2已取消、3已退款，统一在常量类定义，不要散落字符串到处判断。

5. 前端页面与交互实现：重点在选座和状态反馈

5.1 页面清单

Thymeleaf方案下，模板大致有：

• 登录页、注册页
• 电影列表页、电影详情页
• 场次列表页、选座页、订单确认页、我的订单页
• 管理端：电影管理、电影新增编辑、影厅管理、排片管理、订单列表

页面不多，但已经能覆盖完整的业务闭环。界面是第一印象，建议用现成的CSS框架把基础样式做好，再在电影列表和选座页上多花一点精力，这两页最容易出效果。

5.2 选座页怎么画

选座页用表格或者格子布局来渲染座位，每个座位是一个可点击的div。座位数据从后端返回，带上行列和状态。渲染逻辑大致是：

• status=0：可售，绿色，可点击；
• status=1：锁定，灰色，不可点击；
• status=2：已售，深色，不可点击。

用户点击座位后记录已选数量，前端实时计算总价。提交时把座位ID列表传到后端。注意不要在用户一选座位就调后端锁座，而是提交订单时再锁，否则大量用户只是看看就把座位占了，真实场景下体验会很差。

5.3 前后端联调的细节

Thymeleaf方案有两个高频坑：一是模板缓存，改了页面没效果。开发时在application.yml里加spring.thymeleaf.cache=false，改完页面重新编译一下。二是静态资源路径，要用@{/css/style.css}而不是写死相对路径，否则页面层级深了样式容易丢。

前后端分离方案下，跨域是绕不开的。后端加一个CorsConfig，允许前端地址跨域即可。注意不要把allowedOriginPatterns写成*，尤其在用Cookie的时候，否则Session或Token会失效。这也是联调时最常见的坑之一。

6. 调试记录：这些报错我基本都见过

6.1 项目启动不了，端口被占用

Spring Boot默认8080，如果本机其他服务占用了端口，启动日志会提示“Port 8080 was already in use”。解决办法是找到占用进程结束掉，或者在application.yml里改端口：

server: port: 8081

端口一旦改动，所有访问地址都要同步改。我习惯本地开发统一用8080，避免接口地址在不同环境下乱七八糟。

6.2 数据库连接失败

最常见的报错是Access denied for user 'root'@'localhost'，或者Communications link failure。前者是账号或密码不匹配，查看连接串里用户名密码和实际数据库是否一致；后者多半是MySQL服务没启动，或者连接串端口不对。MySQL 8.0下要确认驱动是com.mysql.cj.jdbc.Driver，老驱动在8.0下连不上。

这里有个更隐蔽的坑：如果密码里包含特殊字符，比如@、#、:，在JDBC连接串里直接写会被解析错，需要对特殊字符做转义或者改成用环境变量注入。毕设里密码一般很简单，但如果遇到诡异连接失败，可以从这里排查。

6.3 时间日期相关报错

两类高频问题：一是serverTimezone没配置，启动或第一次查询时报时区错误；二是LocalDateTime在模板页面显示格式不好看。前者配置一行解决，后者可以加全局配置：

spring.jackson.date-format: yyyy-MM-dd HH:mm:ss spring.jackson.time-zone: Asia/Shanghai

对于数据库datetime字段，Java实体用LocalDateTime类型，配合MyBatis-Plus基本不会出问题。不要图省事用字符串接收日期，否则后续排序、比较都要重新解析，非常麻烦。

6.4 并发抢票导致数据不一致

本地测试时，开两个浏览器窗口登录不同账号，同时点同一个座位，如果两边都下单成功，说明代码里没有做好状态控制。最常见的错误写法是：先select座位状态，再判断是否符合条件，最后update。在高并发下，两次查询之间没有任何锁，数据必错。

正确做法是按前面的乐观更新SQL，把状态判断和更新放在一条update语句里，再根据影响行数判断是否成功。这条SQL本身是原子操作，天然防止并发覆盖。测试成功后，把测试过程截图放进毕设文档，答辩时可以直接展示“我是怎么验证并发安全的”。

7. 答辩准备：把讲解重点放在“为什么”上

7.1 评委常问的问题

答辩时评委通常不逐行看代码，而是围绕几个核心问题展开：

• 角色权限是怎么控制的？
• 场次和座位的关系如何设计？
• 并发购票怎么防止超卖？
• 为什么不用数据库外键？
• 密码是怎么存储的？

这些在前面都能找到答案。只要真正理解了，用大白话讲出来，比背PPT强得多。特别建议把“选座+锁座+超时释放”这条链路当成答辩主线，因为它把事务、并发控制、状态机串起来了，是整套系统里最有含金量的部分。

7.2 低成本的可扩展方向

如果想在基础功能上做出一点差异化，可以考虑：

• 在选座页按区域设置不同票价，比如中间区域贵、旁边区域便宜；
• 用ECharts给管理员做每日票房统计；
• 增加短评功能，用户看完电影可以打分留言；
• 管理员端增加一键上下架功能，直接切换电影状态。

这些功能都不需要动核心表结构，只是增量开发，但对提升系统完整度和答辩观感很有帮助。

做这套系统下来，我最大的体会是：毕设能不能做好，不取决于你写了多少行代码，而取决于动手前有没有把业务和表结构想清楚。表设计对了，后面写代码就是往兜里装东西；表设计错了，越写越拧巴。调试过程中最反复的往往不是代码语法，而是业务状态没有理顺。卡住的时候，先拿张纸把角色、流程、状态变化画出来，理清了，代码自然就顺了。