Spring Boot电影在线订票系统：选座并发锁与订单事务实战

简介面向具备一定Java基础、希望学习或从事电影票务管理系统开发的人员这份docx技术文档围绕基于Java与Spring Boot的在线订票选座系统展开可作为课程设计、毕业项目或企业票务平台需求梳理的参考。文档梳理普通用户、会员与管理员三类角色的功能边界涵盖注册登录、影片浏览、论坛交流、订单管理、会员折扣与积分、用户及影视信息管理、留言板监督、数据分析和资源管理等模块并说明IntelliJ IDEA、Maven、Spring Data JPA、Thymeleaf与MySQL的技术组合及编译运行流程。资源包仅含1个docx文件大小约34KB内容包括系统实现截图说明、核心代码片段、完整代码示例、开发步骤、未来改进方向与注意事项便于读者理解数据模型和业务流程逻辑。目前已有315人学习适合用作方案对照和功能设计参考。1. 影院排片表还挂在 Excel 上的时候这套系统解决了什么问题上个月帮一个做本地影院的朋友看他们那套排片表销售用 Excel 记场次前台拿打印的座位图用笔画勾晚上对账再人工核一遍收款记录。这种流程撑三五场还行热门片首映当天重座、错单、退票扯皮全来了。这套基于 Java 与 Spring Boot 的电影在线订票系统走的是 MySQL 存数据、Spring Data JPA 管持久层、Thymeleaf 直出页面、IntelliJ IDEA 加 Maven 构建的路子普通用户、会员、管理员三种角色各有各的入口。想学 Spring Boot 全栈落地的新手或者要给自家小影院搭一套轻量票务后台的开发者拿它当底子都合适。真正难的地方不在页面上有几个按钮而在于同一张椅子被两个人同时点下去的那一刻只能卖出去一次。2. 技术选型拆解Spring Boot JPA Thymeleaf 这套组合为什么够用一个票务系统到底该用前后端分离还是服务端渲染是很多人拿到源码后第一个要问的问题。这个项目选择了最朴素的单体结构Spring Boot 一个进程把 Web 层、业务层、模板渲染全包了没有 Node 工程、没有打包产物、没有跨域配置。看起来不新潮但它恰好匹配「小团队维护、部署在内网或一台小云主机上、改动频率以周计」这类真实场景。把这套技术栈拆开看每个选择背后都有它的理由也都有它的代价。2.1 四层分层controller / service / repository / entity 各自守住什么边界项目骨架是标准的四层结构。controller只干三件事接 HTTP 请求、做参数校验、决定返回 JSON 还是跳模板service承载业务规则和事务边界repository继承JpaRepository除了极少数复杂查询外基本不写实现entity与数据库表一一对应。这个划分听起来像教科书但它在订票场景里有一条非常硬的约束事务必须开在 service 层不能开在 controller 层。原因很实在。如果 controller 上挂Transactional事务的提交时机由 Spring 的 AOP 代理决定通常是在方法返回之后。而模板渲染、JSON 序列化发生在这之后一旦渲染阶段抛异常事务已经提交了数据回不去。订单落了库、座位标了已售、页面却报 500 —— 这是订票系统最忌讳的黑匣子故障用户拿着截图来找你你查日志只能看到一句模板解析失败。我一般把事务注解写在 service 的公有方法上方法内部只做纯业务动作不碰HttpServletRequest、不拼响应体。controller 拿到 service 返回的实体或 DTO 之后再决定怎么呈现。这样即使视图层炸了业务数据也保持在一个自洽的状态里。// controller 层只负责协议转换不在这里开事务 Controller RequestMapping(/movies) public class MoviePageController { private final MovieService movieService; public MoviePageController(MovieService movieService) { this.movieService movieService; } // 返回视图名由 Thymeleaf 解析 templates/movie/list.html GetMapping public String list(RequestParam(defaultValue 1) int page, Model model) { // service 内部完成查询、组装、分页controller 只把结果塞进 Model model.addAttribute(pageData, movieService.pageMovies(page, 12)); return movie/list; } }这段代码里有两个容易忽略的细节。第一是构造器注入而不是Autowired字段注入好处是单元测试可以直接 new 出来也不会有循环依赖时启动失败的玄学问题。第二是Controller而不是RestController这是新手最容易翻车的地方RestController会把返回的字符串当成响应体直接写出去浏览器上你就看到白底黑字一个movie/list。page参数用RequestParam(defaultValue 1)兜底避免用户手改 URL 传个空值进来导致NumberFormatException。pageData这种命名我在项目里统一用里面装content、totalPages、currentPage三个字段模板直接遍历不在模板里算分页逻辑。2.2 三种角色的权限模型USER、MEMBER、ADMIN 怎么落到一张表上项目正文里把功能分成了用户、会员、管理员三块但数据模型上它们并不需要三张表用一张t_user加一个Role枚举就够了。用户注册默认是USER在个人中心完成充值或开通之后升级成MEMBERADMIN由后台或者初始化 SQL 手动指定不开放注册入口。这种做法简单但也埋了一个坑会员身份是「状态」还是「角色」如果会员到期了你是把role改回USER还是保留MEMBER另外加一个expireAt字段我倾向于后者。因为会员等级和权限判断是两件事role决定你能进哪个后台expireAt决定你能不能享受折扣。混在一起写等到要加「黄金会员/白银会员」的时候就得重构。权限拦截这块项目里用HandlerInterceptor加 Session 就够了没必要上 Spring Security。一个拦截器校验登录态一个拦截器校验路径前缀Component public class AdminInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws IOException { User user (User) request.getSession().getAttribute(loginUser); // 未登录或不是管理员一律踢回登录页不做 403 页面 if (user null || user.getRole() ! Role.ADMIN) { response.sendRedirect(/login?redirect request.getRequestURI()); return false; } return true; } }注册拦截器的时候用addPathPatterns(/admin/**)限定范围千万别写成/**否则登录页自己也会被拦住形成无限重定向浏览器直接提示「重定向次数过多」。这个现象我见过不止一次排查的时候看 Network 面板里一长串 302 就明白了。redirect参数带上原路径是个小细节用户从收藏夹点进一个需要登录的页面登录完能回到原来那页体验差别很大。回跳之前记得校验一下参数只允许站内相对路径否则就是个开放重定向漏洞。2.3 Thymeleaf 服务端渲染为什么不做前后端分离这套系统的交互密度其实不高。首页看公告和推荐、列表页翻页、详情页看介绍和评论、选座页点几个座位、订单页确认支付。这类以「读」为主、写操作集中在少数几个流程的场景服务端渲染的收益很明显首屏没有白屏等待、不需要维护两套路由、不存在跨域和 Token 刷新那堆事。代价是选座这种强交互页面写起来会啰嗦一些。纯 Thymeleaf 只能靠表单提交点一个座位刷新一次页面体验很糟。项目里实际的做法是混合页面骨架和初始数据由 Thymeleaf 渲染座位点击、锁座、倒计时这些用原生 JS 加fetch调/api/**接口。这也解释了为什么代码里同时存在Controller和RestController两类控制器 —— 它们服务的是同一个页面的不同阶段。!-- templates/movie/list.html 片段分页条 -- div classpager th:if${pageData.totalPages 1} a th:href{/movies(page${pageData.currentPage - 1})} th:classappend${pageData.currentPage 1} ? disabled上一页/a !-- 用 #numbers.sequence 生成页码避免在模板里写 Java 循环 -- a th:eachi : ${#numbers.sequence(1, pageData.totalPages)} th:href{/movies(page${i})} th:text${i} th:classappend${i pageData.currentPage} ? active/a a th:href{/movies(page${pageData.currentPage 1})} th:classappend${pageData.currentPage pageData.totalPages} ? disabled下一页/a /div{/movies(page${i})}是 Thymeleaf 的链接表达式它会自动补上应用上下文路径将来把项目部署到/ticket这种子路径下也不会失效比手写href/movies?page1稳。th:classappend只追加 class 不覆盖原有 class配合 CSS 里的.disabled { pointer-events: none; }就能实现置灰不可点不需要额外的th:if判断。#numbers.sequence在页数很多的时候要截断比如只显示当前页前后各两页否则一次渲染几百个a标签页面会明显卡顿。这个项目单页 12 条、总数据量在千级暂时没做截断但这是个应该记住的扩展点。3. 目录与配置拿到源码先看 pom.xml 和 application.properties 这两处很多人拿到一份 Spring Boot 源码第一反应是从main方法点进去一路 F7结果半小时后迷失在 Spring 的自动配置里。我的习惯是先看三个地方pom.xml定版本、application.properties定环境、目录结构定职责。这三处看明白项目 70% 的骨架就清楚了剩下 30% 才是业务细节。3.1 目录结构逐层拆哪些包是骨架哪些是业务项目的 Maven 标准结构如下我在原基础上补全了实际开发中会出现的几个包movie-ticket-system/ ├── pom.xml ├── src/main/java/com/example/ticket/ │ ├── TicketApplication.java # 启动类SpringBootApplication │ ├── config/ # 拦截器注册、跨域、静态资源映射 │ ├── controller/ # 页面控制器 API 控制器 │ ├── service/ # 业务逻辑事务边界所在 │ │ └── impl/ │ ├── repository/ # JpaRepository 接口 │ ├── entity/ # 与表一一对应的实体 │ ├── dto/ # 登录请求、下单请求这类入参 │ ├── common/ # 统一返回体、业务异常、枚举 │ └── util/ # 订单号生成、日期工具 ├── src/main/resources/ │ ├── application.properties │ ├── templates/ # Thymeleaf 模板按模块分子目录 │ │ ├── movie/ │ │ ├── order/ │ │ └── admin/ │ ├── static/ # css / js / 海报图 │ └── data.sql # 初始化电影、场次、座位数据 └── src/test/java/...templates下的子目录名和 controller 返回的视图名是强绑定的。return movie/list找的是templates/movie/list.html少一层目录就是 500 错误Error resolving template。static下的资源在模板里用{/css/app.css}引用不需要写/static前缀这是 Spring Boot 默认的静态资源映射规则写错了就是 404。data.sql值得单独说一句。一个空的票务系统是没法演示的你得先有电影、有场次、有座位才能点进选座页。项目里用data.sql灌初始数据配合spring.jpa.hibernate.ddl-autocreate在每次启动时重建表学习阶段很方便。但上线前必须改成none或者用 Flyway 管理否则某天重启一下用户的订单全没了那就不是踩坑是事故了。3.2 pom.xml 依赖清单每个 starter 解决什么问题parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version /parent dependencies !-- Web MVC 内嵌 Tomcat -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- JPA Hibernate负责实体到表的映射 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-jpa/artifactId /dependency !-- Thymeleaf 模板引擎hot reload 靠它 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-thymeleaf/artifactId /dependency !-- 参数校验NotBlank / Min 这些注解的运行时依赖 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency !-- MySQL 8 驱动注意 groupId 是新版 com.mysql -- dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies三个地方容易出问题。第一mysql-connector-j在旧版本里叫mysql:mysql-connector-javaSpring Boot 2.7 之后换成了com.mysql:mysql-connector-j如果你手动抄了一段老配置Maven 不一定报错但运行时会提示驱动类找不到。第二Lombok 声明成optional是对的它只在编译期生成 getter/setter不打进最终 jar但 IntelliJ IDEA 需要装对应插件并开启 Annotation Processing否则满屏红色波浪线代码其实能跑。第三spring-boot-starter-validation不加的话Valid注解会被静默忽略你以为校验生效了实际什么也没拦。版本号我只在parent里写一次其余 starter 全不写版本交给 Spring Boot 的依赖管理统一裁决。这是避免版本冲突最省事的做法手动给每个 starter 指定版本迟早会撞上 Jackson 或者 Hibernate 的不兼容。3.3 application.properties 关键参数逐行讲# 服务端口冲突时改这里别去改 Tomcat 配置类 server.port8080 # 数据库连接三个参数最容易被漏掉 spring.datasource.urljdbc:mysql://localhost:3306/movie_ticket?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue spring.datasource.usernameroot spring.datasource.passwordchange_me spring.datasource.driver-class-namecom.mysql.cj.jdbc.Driver # ddl-auto学习阶段用 update生产必须换成 none spring.jpa.hibernate.ddl-autoupdate spring.jpa.show-sqltrue spring.jpa.properties.hibernate.format_sqltrue # 关闭 open-in-view避免事务被拖到视图渲染阶段 spring.jpa.open-in-viewfalse # Thymeleaf开发期关缓存改模板不用重启 spring.thymeleaf.cachefalse spring.thymeleaf.encodingUTF-8characterEncodingutf8和serverTimezoneAsia/Shanghai这两个参数缺一个就会出现中文变问号或者时间差 8 小时的现象。allowPublicKeyRetrievaltrue是 MySQL 8 默认加密插件下的必需项不加会报Public Key Retrieval is not allowed这个问题在新机器上极其常见。open-in-viewfalse是我个人的强制项。Spring Boot 默认开启它好处是 Thymeleaf 模板里访问懒加载关联不会报错坏处是一个 HTTP 请求从头到尾都占着数据库连接并发一上来连接池就耗尽。关掉之后就会暴露真实的懒加载问题逼你在 service 层用join fetch或者 DTO 解决短痛换长治。spring.thymeleaf.cachefalse只在开发环境开。上线记得改回true否则每次请求都重新解析模板文件QPS 能差出一截。4. 核心链路代码从注册登录到下单出票的完整实现业务代码是这份源码里最值得细看的部分。项目正文给了UserController、MovieController这些示例但那只是骨架真正决定系统能不能用的是实体之间的关系设计以及下单那一刻的并发处理。下面按数据流向从表结构一路讲到订单落库。4.1 实体建模五张表撑起从排片到出票的全流程除开用户、电影这些基础表票务系统真正的核心是screening场次和screening_seat场次座位。很多入门项目图省事只在screening上放一个sold_count字段做库存扣减结果就是没法选座 —— 用户不知道自己买的是哪个位置退票也没法精确释放。正确做法是为每个场次预生成座位行一行代表一个可售单位。Entity Table(name t_screening_seat, uniqueConstraints UniqueConstraint(columnNames {screening_id, seat_no})) public class ScreeningSeat { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; Column(name screening_id, nullable false) private Long screeningId; Column(name seat_no, length 8, nullable false) private String seatNo; // 例如 5排8座 Column(name row_index) private Integer rowIndex; Column(name col_index) private Integer colIndex; Enumerated(EnumType.STRING) Column(length 16, nullable false) private SeatStatus status SeatStatus.AVAILABLE; Column(precision 10, scale 2) private BigDecimal price; }uniqueConstraints这一行是兜底。应用层的锁可能因为代码写错而失效但数据库的唯一约束不会同一场次同一座位号想插两行直接抛异常。rowIndex和colIndex是给前端画座位图用的seatNo是给人看的两者都要留。status用Enumerated(EnumType.STRING)而不是ORDINAL。默认值ORDINAL会把枚举存成 0、1、2将来你在枚举中间插一个新状态历史数据的语义就全乱了这种坑排查起来极其痛苦因为数据库里看着一切正常。订单表则记录一次购买行为的快照Entity Table(name t_order, indexes Index(columnList user_id, status)) public class Order { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; Column(unique true, length 32) private String orderNo; // 业务单号对外展示用 private Long userId; private Long screeningId; Column(length 255) private String seatIds; // 逗号分隔逻辑上是一对多 Column(precision 10, scale 2) private BigDecimal amount; Enumerated(EnumType.STRING) private OrderStatus status; // UNPAID / PAID / CANCELLED / REFUNDED private LocalDateTime createdAt; private LocalDateTime expireAt; // 未支付超时时间定时任务扫这个字段 }seatIds用逗号分隔存字符串在严格范式下是不推荐的但订单一旦生成就不该再和座位表产生强关联 —— 座位可能被回收再卖给别人订单必须保留「当时买了哪几个位置」这个事实。用 JSON 字段或者中间表也行看团队习惯我选字符串是因为查问题的时候直接select出来就能看懂。4.2 注册登录密码加盐与 Session 落地原项目的UserService.register里只有一句userRepository.save(user)这个写法能跑通注册但密码是明文入库的。稍微正经一点的实现都要过一遍 BCrypt。Service public class UserServiceImpl implements UserService { private final UserRepository userRepository; private final PasswordEncoder passwordEncoder; // BCryptPasswordEncoder public UserServiceImpl(UserRepository userRepository, PasswordEncoder passwordEncoder) { this.userRepository userRepository; this.passwordEncoder passwordEncoder; } Override Transactional(rollbackFor Exception.class) public void register(RegisterRequest req) { // 先查重数据库唯一索引还会再兜一层 if (userRepository.findByUsername(req.getUsername()).isPresent()) { throw new BizException(用户名已存在); } User user new User(); user.setUsername(req.getUsername()); // encode 内部生成随机盐盐值随密码一起存进同一个字段 user.setPassword(passwordEncoder.encode(req.getPassword())); user.setRole(Role.USER); user.setCreatedAt(LocalDateTime.now()); userRepository.save(user); } Override public User login(LoginRequest req) { User user userRepository.findByUsername(req.getUsername()) .orElseThrow(() - new BizException(用户名或密码错误)); // matches 会用存下来的盐重新算一遍不要自己写比较逻辑 if (!passwordEncoder.matches(req.getPassword(), user.getPassword())) { throw new BizException(用户名或密码错误); } return user; } }两个安全细节。一是用户名不存在和密码错误返回同一句提示避免被人拿来枚举有效用户名。二是passwordEncoder.matches内部就是从数据库字段里解析盐值不需要单独存一列 saltBCrypt 的输出格式已经包含了它。登录成功后要把用户放进 SessionPostMapping(/login) public String doLogin(Valid LoginRequest req, HttpSession session, Model model) { try { User user userService.login(req); // 只放必要字段进 session别把整个实体塞进去 session.setAttribute(loginUser, user); return redirect:/; } catch (BizException e) { model.addAttribute(error, e.getMessage()); return login; // 回到登录页并带上错误提示 } }redirect:前缀走的是重定向避免用户按 F5 重复提交表单。失败时不重定向而是直接返回视图这样model里的错误信息能在页面上渲染出来。这个细节很多人写反了重定向之后再取model发现是空的。4.3 电影与场次查询分页 条件筛选的实际写法电影列表要支持按类型筛、按关键词搜用JpaRepository的派生查询方法会写出findByTitleContainingAndTypeIdAndStatus这种几十个字符的方法名一旦条件变可选就彻底失控。项目里用Specification动态拼条件更合适。public PageMovie pageMovies(int page, int size, Long typeId, String keyword) { SpecificationMovie spec (root, query, cb) - { ListPredicate ps new ArrayList(); // 只在参数非空时追加条件避免 null 参与比较 if (typeId ! null) { ps.add(cb.equal(root.get(typeId), typeId)); } if (StringUtils.hasText(keyword)) { ps.add(cb.like(root.get(title), % keyword %)); } return cb.and(ps.toArray(new Predicate[0])); }; // 前端页码从 1 开始JPA 从 0 开始这里要减 1 Pageable pageable PageRequest.of(page - 1, size, Sort.by(releaseDate).descending()); return movieRepository.findAll(spec, pageable); }ps.toArray(new Predicate[0])在条件为空的时候返回一个空数组cb.and()对空数组的处理是返回恒真条件正好符合「无条件即全量」的预期。分页的page - 1是必须的转换忘了就会一直跳过第一页或者越界抛异常。排序字段releaseDate要和实体属性名一致写数据库列名release_date会在启动时或首次查询时报Unable to locate Attribute。4.4 下单事务一次购买动作里三个必须原子化的步骤这是整个系统最关键的一段代码。锁座、计价、改座位状态三步必须在同一个事务里而且要解决并发下两个人抢同一个座位的问题。Service public class OrderServiceImpl implements OrderService { private final ScreeningSeatRepository seatRepository; private final OrderRepository orderRepository; private final MemberService memberService; Override Transactional(rollbackFor Exception.class) public Order createOrder(Long userId, Long screeningId, ListLong seatIds) { // 1. 排好序再查保证所有并发事务按同一顺序获取行锁避免交叉死锁 ListLong sorted seatIds.stream().distinct().sorted().collect(Collectors.toList()); // 2. 悲观写锁把座位行锁住第二个请求会在这里排队等待 ListScreeningSeat seats seatRepository.lockSeats(screeningId, sorted); if (seats.size() ! sorted.size()) { throw new BizException(座位不存在或不属于该场次); } for (ScreeningSeat s : seats) { if (s.getStatus() ! SeatStatus.AVAILABLE) { throw new BizException(座位 s.getSeatNo() 已被占用请重选); } } // 3. 计价会员折扣在 service 内完成不暴露给 controller BigDecimal amount seats.stream() .map(ScreeningSeat::getPrice) .reduce(BigDecimal.ZERO, BigDecimal::add); amount memberService.applyDiscount(userId, amount); Order order new Order(); order.setOrderNo(OrderNoGenerator.next()); order.setUserId(userId); order.setScreeningId(screeningId); order.setSeatIds(sorted.stream().map(String::valueOf).collect(Collectors.joining(,))); order.setAmount(amount); order.setStatus(OrderStatus.UNPAID); order.setCreatedAt(LocalDateTime.now()); order.setExpireAt(LocalDateTime.now().plusMinutes(15)); orderRepository.save(order); // 4. 座位状态流转为锁定支付成功后再置为已售 seats.forEach(s - s.setStatus(SeatStatus.LOCKED)); seatRepository.saveAll(seats); return order; } }配套的 repository 方法public interface ScreeningSeatRepository extends JpaRepositoryScreeningSeat, Long { /** * 按场次和座位 id 批量加悲观写锁 * param screeningId 场次 id防止跨场次误锁 * param ids 已排序的座位 id 列表 */ Lock(LockModeType.PESSIMISTIC_WRITE) Query(select s from ScreeningSeat s where s.screeningId :sid and s.id in :ids order by s.id) ListScreeningSeat lockSeats(Param(sid) Long screeningId, Param(ids) ListLong ids); }PESSIMISTIC_WRITE在 MySQL 下翻译成SELECT ... FOR UPDATE行级锁。为什么必须排序假设事务 A 锁了 5 号再要 8 号事务 B 锁了 8 号再要 5 号两边互相等待对方释放直接死锁。排序之后所有事务的加锁顺序统一最坏情况是排队不会死锁。expireAt是这张订单的「后悔药」。用户锁了座不付款座位会一直处于LOCKED状态别人买不了。所以要配一个定时任务每分钟扫一遍过期未支付的订单把订单置为CANCELLED、座位退回AVAILABLEScheduled(fixedDelay 60_000) Transactional(rollbackFor Exception.class) public void releaseExpiredOrders() { ListOrder expired orderRepository .findByStatusAndExpireAtBefore(OrderStatus.UNPAID, LocalDateTime.now()); for (Order o : expired) { o.setStatus(OrderStatus.CANCELLED); // 解析 seatIds 字符串批量恢复座位状态 seatRepository.releaseSeats(o.getScreeningId(), parseIds(o.getSeatIds())); } orderRepository.saveAll(expired); }15 分钟这个时长是可以调的太短用户还在支付页就被释放了太长高峰期座位被占着卖不出去。一般影院场景 10 到 15 分钟比较合适支付渠道回调慢的可以放宽到 20 分钟。提示定时任务需要启动类上加EnableScheduling忘了加的话这个方法一辈子不会执行而且没有任何报错。5. 启动与联调避坑5 个真实翻车现场的现象、原因与解法源码跑不起来的原因八成集中在环境、配置、依赖这三处跟业务代码关系不大。下面这五个坑是我在 Spring Boot 项目里反复遇到过的按踩中概率排序。5.1 环境与启动阶段连不上库、起不来服务坑一启动报Communications link failure现象是控制台一片红HikariPool-1 - Exception during pool initialization应用直接退出。原因通常有三个MySQL 服务没起、数据库movie_ticket没建、spring.datasource.url里的端口或主机写错。还有一种隐蔽的情况是密码里有或#直接拼在 URL 或者明文写在 properties 里会被解析错。解决方式是先用命令行客户端连一次确认账号密码和库名都对再回来改配置。密码含特殊字符的话properties 文件里用单引号包起来或者干脆把密码里那些字符换掉。建库语句记得指定字符集CREATE DATABASE movie_ticket DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;utf8mb4和utf8的区别在于前者支持完整的四字节字符电影名里带生僻字或者特殊符号时用utf8会存成问号。坑二端口被占用Port 8080 was already in use现象是启动瞬间就退出日志里明确写了端口冲突。原因可能是上一次的进程没杀干净也可能是本机跑着别的东西占着 8080。Windows 上用netstat -ano | findstr 8080找到 PID 再taskkill /F /PID xxxmacOS 或 Linux 用lsof -i :8080。更稳妥的方式是别去杀进程直接在配置里改端口server.port8081。团队协作时我会把端口写进application-dev.properties并加到.gitignore每个人本地用不同的端口互相不打架。坑三IDEA 里满屏红编译却是通的现象是Data、Slf4j这些 Lombok 注解下面全是红色波浪线get/set方法提示不存在但mvn compile完全正常。原因是 IDEA 没开注解处理。解决路径是 Settings → Build → Compiler → Annotation Processors 勾上 Enable annotation processing同时确认装了 Lombok 插件。这个坑之所以烦人是因为它不影响运行只影响你写代码时的心情和自动补全很多人忍了很久才发现是个开关的问题。5.2 运行与渲染阶段页面 500、数据拿不到坑四模板渲染报LazyInitializationException现象是电影详情页能打开但一访问关联数据比如电影的场次列表就 500堆栈里是could not initialize proxy - no Session。原因就是我前面提到的open-in-view。这个配置默认是true如果你手动关掉或者用了异步线程Session 在 service 方法返回时就关闭了模板里再访问懒加载集合就会炸。解决办法有两个方向。一是查询时就用join fetch把需要的数据一次捞出来Query(select distinct m from Movie m left join fetch m.screenings where m.id :id) OptionalMovie findDetailById(Param(id) Long id);二是在 service 层就组装成 DTO模板只碰 DTO 里的普通字段不碰任何代理对象。我一般选第二种因为 DTO 能明确表达「这个页面需要哪些数据」比猜哪些关联被用到了更可控。坑五POST 提交中文变乱码或者表单参数全是 null现象是新增电影时片名存进库变成问号或者 controller 里RequestParam拿到的值是null。前者是编码链路上的问题检查三处数据库表字符集、JDBC URL 里的characterEncodingutf8、页面meta charsetUTF-8。三者缺一不可。后者多半是参数名不匹配。表单里写namemovieTitlecontroller 里写RequestParam String titleSpring 找不到就给你 null而且不报错。加上RequestParam(name movieTitle)显式绑定或者干脆用对象接收PostMapping(/admin/movies) public String create(Valid MovieForm form, BindingResult result, Model model) { // BindingResult 必须紧跟在被校验对象后面位置错了会直接抛异常 if (result.hasErrors()) { model.addAttribute(errors, result.getAllErrors()); return admin/movie-form; } movieService.create(form); return redirect:/admin/movies; }BindingResult的位置是个经典陷阱。它必须紧挨着Valid修饰的参数中间插了别的参数Spring 就不会把它当成校验结果的载体校验失败直接抛MethodArgumentNotValidException你的自定义错误页根本走不到。6. 二次开发改造给选座页补一套可靠的锁座与释放机制拿到这份源码多数人的第一个改造需求是「把选座做得更像真的」。原实现的悲观锁方案在单机、并发量不大的场景完全够用但它有个明显的短板锁的粒度是数据库行用户点一下座位就占一次事务热门场次开票那一分钟数据库连接池很容易被打满。我一般会在外面加一层缓存预扣把压力挡在数据库前面。思路是引入缓存做第一道闸门键设计成seat:lock:{screeningId}:{seatId}值为用户 id过期时间设成和订单超时一致的 15 分钟。用户点座位先走缓存写入成功了再落库支付成功删 key 并更新座位状态。这样重复点击、并发抢占在前置层就被拦掉了数据库只处理真正走到下单的请求。代价是要处理缓存和数据库的一致性问题。缓存写成功但数据库写失败会出现「座位上锁了但没订单」的脏状态。我的做法是给缓存 key 的过期时间比订单短一分钟让它在订单失效之前先自然过期中间这段窗口靠数据库的唯一约束兜底 —— 万一真插重复了唯一索引会抛异常捕获后返回「座位已被占用」即可。验证改动是否有效别靠手动点。我会开两个终端用ab或者 JMeter 对同一个座位 id 并发打 100 个下单请求然后查数据库里这张座位被成功占用了几次。正确的输出应该是 1 次成功、99 次失败而不是 2 次甚至更多。这个测试跑通说明锁真的生效了跑不通再怎么改代码都是猜。验证维度可以按这个表过一遍验证项预期结果异常时的排查方向同座位并发下单仅 1 单成功锁模式、唯一索引是否存在未支付超时释放15 分钟后座位回到可售定时任务是否启用、时间字段时区会员折扣计算折后金额与规则一致折扣是否重复叠加、精度舍入退票后重新上架座位状态与订单状态同步事务是否覆盖两处更新最后说个我自己的习惯。这套系统第一次部署到测试环境时我没做压力测试就直接让同事试用结果开票那一下数据库连接池爆了页面全白。从那以后我每次改完锁相关的代码都会先用并发脚本跑一遍再交付哪怕只改了一行sorted()的调用位置。座位这东西卖重一次就是一次真实的客诉没有后悔药可吃。希望这篇拆解能帮到你少走几段弯路。本文还有配套的精品资源点击获取