企业官网建设流程全解析

1. 项目概述与核心价值拆解

先说结论：这套影院购票系统，本质上是一个典型的“管理端+用户端”双层业务系统，开发上采用的是当前国内企业级项目最主流的SpringBoot+Vue前后端分离架构，数据层用MyBatis做ORM映射、MySQL做持久化存储。标题里“企业级”三个字不是噱头，它意味着代码结构、权限设计、事务处理和部署方式都要达到可以对外交付的程度，而不是课程设计那种跑通就完事的Demo。

我为什么会关注到这套系统的选型组合？因为SpringBoot、Vue、MyBatis、MySQL这四个词，基本就是国内中小型企业内部系统开发的“标准全家桶”。SpringBoot负责把后端服务快速组装起来，Vue负责把页面交互做得流畅，MyBatis让SQL操作灵活可控，MySQL则是最稳妥、成本最低的关系型数据库。这套组合的优势不在于某个单项技术多先进，而在于生态成熟、招人容易、部署简单、出了问题网上一搜全是解决方案——对影院这种业务密集型场景来说，“稳定可控”比“花哨新颖”重要得多。

这套系统适合谁来参考？如果你是正在做毕业设计的学生、刚入职需要快速上手企业项目的初级开发、或者手里有影院/剧院/演出场馆类业务想做信息化的产品经理，这篇文章都能给你一些实打实的参考。接下来我会从架构思路、数据库设计、核心业务实现、部署实战和避坑经验五个维度，把一套影院购票系统从0到1的关键环节拆开讲透。

2. 整体架构设计与技术选型思路

2.1 前后端分离架构的搭建逻辑

影院购票系统的业务链路并不复杂：用户选电影、选场次、选座位、下单支付、取票入场，管理员排片、管理影院和影厅、处理订单和营销活动。但这个链路里涉及高并发抢座、事务一致性、权限分级等多个敏感点，所以架构上必须分层清晰。

前端采用Vue框架，配合Vue Router做页面路由管理、Vuex/Pinia做全局状态管理，组件化的开发方式让页面复用性大幅提升。用户在影院购票场景里的操作路径相对固定：首页影片列表、影片详情、选座购票、订单确认、支付结果、个人中心。这套流程如果用传统多页面开发，光是页面间参数传递就能写出一堆重复代码，而Vue的单页应用特性加上动态路由，让整个购票流程像操作一个原生App一样流畅。

后端SpringBoot的核心价值在于“约定优于配置”。影院系统涉及大量业务模块——影片管理、影厅管理、排片管理、用户管理、订单管理、支付对接、营销活动，如果不用SpringBoot而用传统的SSM框架手动配置，光Spring和MyBatis的整合XML就能写几百行。SpringBoot的自动配置机制把这些繁琐的装配工作接管了，开发者只需要关注业务本身。

前后端通过RESTful API交互，数据格式统一使用JSON。这里有一个关键的架构决策：接口层要设计成“按业务域拆分”而不是“按页面拆分”。比如用户选座时需要查询当前场次的座位状态、计算票价、校验座位是否被占用，这三个动作在页面上是连续的，但后台应该拆成“座位状态查询接口”“票价计算接口”“锁座接口”，而不是做一个大的“选座接口”把所有逻辑耦合在一起。这样后续如果要在App端、小程序端复用同一套接口，改动成本会小很多。

2.2 为什么选MyBatis而不是JPA或MyBatis-Plus

很多人在数据访问层会纠结选MyBatis还是Spring Data JPA。影院购票系统的数据查询非常复杂，尤其是排片查询——需要按影院、按日期、按影片多个维度筛选；选座查询——需要关联影厅座位表和订单表判断哪些座位已被占用；订单查询——需要关联用户表、影片表、场次表展示完整订单信息。这类复杂查询用JPA的派生查询方法写起来相当别扭，反而用MyBatis的XML映射文件可以直观地写出SQL，什么时候该联表、什么时候该用子查询、什么时候该做条件拼接，都在掌控之中。

极端情况下，一场热门影片首映场的座位状态查询，要在几百毫秒内返回全厅座位数据并标注已售/锁定状态，MyBatis的SQL优化能力在这里比ORM自动生成的查询更可靠。你可以精确控制SQL的执行计划，比如给影厅座位表、订单表建立联合索引，用一条带条件索引的SQL完成查询，而不是让JPA生成一条需要全表扫描的麻烦查询。

MyBatis在当前的选型中还有一个现实意义：团队的维护成本。懂MyBatis的开发人员数量远多于懂JPA的高级用法的人，而且网上关于MyBatis的踩坑经验非常多，项目出了问题排查效率高得多。如果你的SQL功底扎实，建议继续自己写SQL；如果团队水平参差不齐，后续也可以考虑引入MyBatis-Plus做单表CRUD的简化，但复杂的联表查询和统计报表仍然建议手写SQL，这是MyBatis生态的通用实践。

提示：选MyBatis并不代表放弃事务管理。影院购票系统里“选座-锁座-下单-支付”这条链路上有多个写操作，一定要在Service层用@Transactional声明事务，并结合数据库的隔离级别控制并发问题。这块后面我会重点讲。

2.3 MySQL表结构设计与索引规划

影院购票系统的数据库表设计是整个项目的根基，我见过太多项目死在表结构设计不合理上。最核心的几张表包括：电影表、影厅表、座位表、场次表、订单表、用户表、支付流水表。

电影表要区分“正在上映”和“即将上映”，需要一个status字段标记状态，同时存储影片的封面图URL、预告片URL、时长、类型、导演、演员等基础信息。这里有个细节容易被忽略：影片的评分不适合直接在电影表里冗余一个字段，因为用户评分是不断写入的，每次都更新电影表的评分字段会造成大量写操作。更好的做法是单独建一张评分统计表或者用缓存定期汇总。

影厅表和座位表是“一对多”关系。影厅表保存影厅名称、类型（IMAX、杜比、普通厅）、座位总数、座位布局的行列数；座位表保存每个座位的具体行列号、座位类型（普通座、情侣座、无障碍座）和状态。座位表的status字段要注意区分“物理状态”和“逻辑状态”——物理状态是座位是否损坏、是否维护中，逻辑状态是某场次下该座位是否被锁定或出售。这两个状态混在一个字段里是新手常犯的错误。

场次表是整个系统的核心枢纽，关联电影表和影厅表。场次表里保存放映时间、结束时间（由电影时长推算）、语言版本、票价、影厅ID。这里必须加影厅ID的唯一索引（上映时间、影厅ID），因为一个影厅在同一个时间点绝对不能排两个场次——否则选座模块会直接逻辑错乱。

订单表的设计决定了整个购票系统的可靠性。订单表要包含订单编号、用户ID、场次ID、座位ID列表、订单总金额、订单状态（待支付、已支付、已取消、已退款、已完成）、创建时间、支付时间等字段。这里要特别注意：一张订单可能包含多个座位，所以座位信息既可以在订单表里用逗号拼接的座位ID（简单场景），也可以单独建一张订单座位明细表（复杂场景）。企业级系统建议用明细表，因为后续要做退票、换座、部分退款时，明细粒度才能支撑业务操作。

索引规划上，我强烈建议在建表前就做好，不要等数据量大了再来补。用户表的手机号字段要建唯一索引；订单表的用户ID、场次ID、订单状态要建联合索引；场次表的电影ID和时间字段要建联合索引；座位表的影厅ID和行列号要建联合索引。这套索引设计覆盖了系统里95%以上的查询条件，能确保在数据量达到几十万条时查询性能依然稳定。

3. 核心业务模块与实现细节

3.1 用户注册登录与JWT鉴权

影院购票系统面向C端用户，用户注册登录是最基础的功能。这里不建议用传统的Session方式做会话管理，因为前后端分离架构下，Session的跨域处理和集群共享都是麻烦事。目前企业级项目普遍采用JWT（JSON Web Token）做无状态认证。

实现思路是这样的：用户登录成功后，后端签发一个JWT Token返回给前端，前端存储在localStorage或Vuex/Pinia中。后续每次请求在HTTP Header的Authorization字段带上这个Token，后端通过拦截器解析Token获取用户身份信息，从而实现接口鉴权。Token要设置合理的过期时间，影院购票场景建议短期Token配刷新Token的方案，比如主Token有效期2小时，用户在选座过程中页面停留时间可能较长，如果Token过期导致操作失败，体验会很差。

权限管理上还需要做一层角色区分。管理系统里的管理员、运营人员、财务人员拥有不同的操作权限，比如运营人员可以排片但不能修改票价（价格策略由管理员制定），财务人员只能查看订单报表不能直接操作用户订单。这种细粒度的权限控制建议用Spring Security或自定义拦截器实现，在注解里声明接口所需角色，不满足权限的请求直接返回403。

3.2 影片管理、排片管理与影厅维护

这三个管理功能是运营后台的核心。影片管理模块支持上下架、基础信息的增删改查，上传封面图时要注意图片存储方案的选择。本地磁盘存储简单但不利于多机部署，建议使用对象存储服务或者将图片转存为Base64字符串存入数据库的小文件场景。

排片管理模块是容易出问题的重灾区，核心难点在于时间冲突校验。当运营人员新增一个场次时，系统必须校验该影厅在该时间段是否有其他场次，同时要预留合理的间隔时间（通常15-30分钟）用于散场清场。这里用SQL做区间重叠校验即可，查询条件为“影厅ID=指定值 且 放映开始时间<新场次结束时间 且 放映结束时间>新场次开始时间”，一旦查询到记录就提示冲突。

影厅维护模块处理座位图配置。座位上要注意预留特殊位置，比如每排的中间位置可以设置为情侣座，靠近过道的位置设为无障碍座，这样在C端选座时能针对不同人群展示差异化票价。影厅的基础布局数据是一次性的，但座位状态是动态的，建议座位表里保存静态布局字段（行、列、区域），而“是否可用”这类的动态状态按场次生成快照。

3.3 选座购票核心链路与事务控制

选座购票是整个系统业务复杂度最高、也最容易出Bug的环节。我来完整走一遍这个流程：

第一步，用户从影片列表进入场次列表，选择具体场次后进入选座页。选座页需要调用接口获取当前场次的座位图。座位图数据由影厅静态布局和该场次的动态占用状态两部分组成，未售出的座位、已锁座的座位（其他用户正在下单）、已售出的座位要分别用不同颜色展示。

第二步，用户点击选座，前端先做本地交互反馈。此时不能直接在后端锁座，因为用户可能还没下决心购买，如果每次点击座位就锁座，库存会很快被无效占用。企业级做法是“先提交意向、再锁定座位”。

第三步，用户选定座位后点击“立即购买”，前端把“场次ID+座位ID列表”发给后端。后端进入锁座逻辑：查询这些座位当前的锁定状态，如果有座位已被其他用户锁定或售出，返回“座位已被占用”的提示；如果状态正常，则将这些座位状态改为“锁定”，生成一个待支付订单，订单状态为“待支付”，并设置锁定的到期时间（通常10-15分钟）。

第四步，用户支付成功后，后端回调中把订单状态更新为“已支付”，同时将座位状态从“锁定”改为“已售出”。如果用户超时未支付，需要有一个定时任务把超时的锁定座位恢复为“未锁定”。

这里最关键的问题是并发控制。两个用户同时点击同一个座位时，MySQL层面需要使用“乐观锁”或“悲观锁”来保证只有一个操作成功。我推荐使用乐观锁方案：座位表增加version字段，更新时使用“UPDATE 座位表 SET status=‘锁定’, version=version+1 WHERE 座位ID=? AND status=‘未锁定’ AND version=原版本号”，通过受影响行数判断是否更新成功。如果影响行数为0，说明座位已被抢占，后端返回失败提示。

注意：锁座后生成的待支付订单必须设置过期时间。建议在订单表增加expire_time字段，同时开启一个每1分钟执行一次的定时任务，扫出所有“待支付且超时”的订单，恢复座位状态并取消订单。这样即使用户中途关闭页面，也不会造成座位永久占用。

3.4 商城促销与优惠券模块设计

影院购票系统通常还包含优惠券和会员折扣功能。优惠券模块的表设计需要三张表：优惠券模板表（定义满减门槛、优惠金额、有效期）、用户优惠券表（用户领取的优惠券实例，包含使用状态）、优惠券发放记录表（跟踪发放渠道）。下单时，系统先计算出订单原始金额，再根据用户选择的优惠券优惠金额算出应付金额，生成支付流水时按应付金额创建记录。

优惠券设计的重点在于防超领和防错用。防超领靠数据库的唯一索引——用户ID和优惠券模板ID的组合字段加唯一索引，同一个用户对一个活动只能领一次。防错用则在下单时校验优惠券的使用条件（满减门槛、适用范围、是否过期、是否已使用），校验通过后在事务中将优惠券状态更新为“已使用”，避免同一张券被并发使用。

4. 前后端核心功能实现与系统实战记录

4.1 Vue前端项目结构与路由配置

Vue前端的项目结构建议按功能模块划分，不要所有文件都堆在src/views下面。我常用的结构是：

• api目录：按业务域拆分的接口请求封装，对应后端的控制器。
• assets目录：静态资源。
• components目录：公共组件，比如影片卡片组件、电影轮播组件、座位选择组件。
• router目录：路由配置，包含静态路由和动态路由两部分，根据用户角色在后端登录接口中返回对应的路由表。
• store目录：Vuex/Pinia状态管理，存放用户信息、Token、购物车状态、全局加载状态等。
• utils目录：请求封装、Token存取、工具函数。
• views目录：页面级组件，包含用户端的Home、MovieDetail、CinemaList、SeatSelect、OrderPay、OrderList以及管理端的Dashboard、MovieManage、ScheduleManage、OrderManage等页面。

路由设计上，影院系统需要区分“用户端页面”和“管理端页面”。用户端页面不需要登录也能浏览影片列表、查看场次，只有在选座和下单时需要强制跳转到登录页；管理端页面则必须登录且要求管理员角色才能访问，这个控制可以用Vue Router的导航守卫实现，在每次路由跳转前检查Store中的Token和用户角色信息。

我特别想强调Vuex/Pinia在选座流程中的重要性。用户在选座页面选择了多个座位，接下来跳到订单确认页，再跳到支付页，这一连串页面间如果要反复通过URL参数传递座位ID列表，代码会异常繁琐且在刷新页面时容易丢失状态。正确做法是把“当前选中的场次信息、座位列表、金额计算详情”存入全局状态管理，在各个页面之间共享，只有支付成功后或者进入个人中心查询订单时才去后端拉取权威数据。

4.2 后端接口设计与代码分层

后端项目的包结构我习惯按三层层级来划分：Controller层负责接收请求和参数校验；Service层负责业务逻辑；Mapper层负责数据库交互。有的开发者会把所有查询逻辑全部写在Controller里，结果代码越写越长，接口越来越难维护。保持每层职责单一，后续即使有人离职，接手的人看一下Service层的业务方法名，就能大致了解系统的业务流转路径。

接口设计要遵循RESTful风格。比如影片模块的接口是：GET /api/movies（影片列表）、GET /api/movies/{id}（影片详情）、POST /api/movies（新增影片）、PUT /api/movies/{id}（修改影片）、DELETE /api/movies/{id}（删除影片）。订单模块的接口是：POST /api/orders（创建订单）、GET /api/orders/{orderNo}（订单详情）、POST /api/orders/{orderNo}/pay（发起支付）、POST /api/orders/{orderNo}/cancel（取消订单）。

统一返回格式也是企业级项目必备规范。我定义了Result类包含code、message、data三个字段，所有Controller的返回值都是Result类型。前端封装axios拦截器，当code不为200时统一弹出错误提示，避免每个页面都写重复的错误处理代码。

下面是一个典型的Controller方法示例，展示如何通过MyBatis查询场次列表并返回前端：

@RestController @RequestMapping("/api/schedule") public class ScheduleController { @Resource private ScheduleService scheduleService; @GetMapping("/list") public Result list(@RequestParam Long movieId, @RequestParam String date) { // 参数校验 if (movieId == null || StringUtils.isEmpty(date)) { return Result.error("参数不完整"); } List<ScheduleVO> scheduleList = scheduleService.getScheduleList(movieId, date); return Result.success(scheduleList); } }

Service层处理业务逻辑，比如获取场次列表时需要同时查出影厅名称、当前场次的剩余座位数。剩余座位数必须用SQL计数而不是直接读某张表的冗余字段，因为座位状态是动态变化的，冗余字段容易在并发下不一致。

4.3 核心SQL与Mapper配置实战

MyBatis的XML映射文件在整个项目里占有重要地位。以前端选座页为例，查询某个场次所有座位的状态，最简单的实现是先把该场次关联影厅的全部座位查出来，然后将已售和锁定的座位状态覆盖到对应位置。但这种方式在数据量大时会很低效，我推荐用一条LEFT JOIN语句直接查出座位和订单状态：

<select id="selectSeatStatusByScheduleId" resultType="map"> SELECT s.row_no, s.column_no, s.seat_type, CASE WHEN o.id IS NULL THEN 'available' WHEN o.status IN (1, 2) THEN 'locked' ELSE 'sold' END AS seat_status FROM seat s LEFT JOIN order_seat os ON os.seat_id = s.id LEFT JOIN orders o ON o.id = os.order_id AND o.schedule_id = #{scheduleId} WHERE s.hall_id = (SELECT hall_id FROM schedule WHERE id = #{scheduleId}) </select>

这条SQL的巧妙之处在于把座位静态信息和订单动态信息拼在一次查询中返回，前端拿到数据后直接根据row_no和column_no渲染座位格子即可，避免了后端Java代码里做大量的内存遍历拼接操作。

MyBatis的另一个实用技巧是使用动态SQL处理多条件查询。影片列表管理页面通常支持按“类型、状态、上映时间范围”等条件筛选，如果为每个条件组合都写一条SQL，那Mapper文件会爆炸。用MyBatis的 和 标签可以完美解决这个问题：

<select id="selectMovieList" resultType="MovieDTO"> SELECT * FROM movie <where> <if test="type != null and type != ''"> AND type = #{type} </if> <if test="status != null"> AND status = #{status} </if> <if test="cityId != null"> AND city_id = #{cityId} </if> </where> ORDER BY release_date DESC </select>

这种写法不仅避免了多个条件拼接时WHERE和AND的位置问题，而且SQL是动态构建的，只有传入条件时才会拼进SQL，数据库的执行计划也相对稳定。

4.4 选座锁座与订单支付完整流程实现

选座锁座的完整流程，我从代码层面拆解一遍，这也是整个系统里技术含量最高的部分。

第一步，创建订单。Controller接收前端传来的场次ID和座位ID数组，先将订单数据插入orders表，状态为“待支付”，再将座位数据和订单的关联关系插入order_seat表。这两个操作必须在同一个事务里，否则可能出现订单有了但座位关系丢失的情况。

第二步，锁定座位。这里使用乐观锁更新，逐条更新座位状态。注意不要用循环逐条更新，可以用批量更新语句或减少数据库交互：

@Transactional(rollbackFor = Exception.class) public Order createOrder(CreateOrderDTO dto) { // 1. 生成订单号 String orderNo = generateOrderNo(); Order order = new Order(); order.setOrderNo(orderNo); order.setUserId(dto.getUserId()); order.setScheduleId(dto.getScheduleId()); order.setStatus(0); // 待支付 order.setExpireTime(new Date(System.currentTimeMillis() + 15 * 60 * 1000)); orderMapper.insert(order); // 2. 锁定座位（乐观锁） for (Long seatId : dto.getSeatIds()) { int rows = seatMapper.lockSeat(seatId, dto.getScheduleId()); if (rows == 0) { throw new BusinessException("座位已被抢购，请重新选择"); } OrderSeat orderSeat = new OrderSeat(); orderSeat.setOrderId(order.getId()); orderSeat.setSeatId(seatId); orderSeatMapper.insert(orderSeat); } // 3. 计算订单金额（根据座位类型和场次票价） BigDecimal totalAmount = calculateAmount(dto.getScheduleId(), dto.getSeatIds()); order.setTotalAmount(totalAmount); orderMapper.updateById(order); return order; }

第三步，支付回调。用户在前端调起支付（对接微信/支付宝），支付成功后由支付平台的回调通知后端。后端接收到通知后做两件事：更新订单状态为“已支付”，把该订单关联的座位状态更新为“已售出”。支付回调接口必须实现幂等——即同一个支付通知可能被推送多次，要判断订单当前状态，只有当订单是“待支付”时才执行状态流转。

这里有一个需要特别注意的细节：支付回调后，座位状态更新务必放在事务中执行，并且要在更新时加WHERE条件“订单状态=0”，防止极端情况下出现重复支付把订单状态覆盖乱。

4.5 MinIO实现影片海报与预告片存储

影院购票系统里图片和视频资源很多，如果用本地磁盘存，上线后运维扩容和管理都麻烦。我在实战中强烈建议引入MinIO作为私有化对象存储服务。MinIO是一款兼容Amazon S3协议的开源对象存储系统，部署简单，社区活跃，特别适合中小型项目的资源存储。

SpringBoot集成MinIO的步骤不复杂：引入minio依赖，配置好服务端地址、AccessKey、SecretKey，声明MinioClient的Bean。上传文件的接口先接收MultipartFile，调用MinioClient的putObject方法将文件存入指定Bucket，同时生成文件的访问URL。文件访问URL如果要做权限控制，可以使用MinIO的预签名URL，生成一个带有效期的HTTP链接给前端使用，过期后链接自动失效，防止静态资源被恶意盗链。

在实际使用中要注意一个容易踩的坑：MinIO的图片访问地址最好通过自定义域名或反向代理暴露到前端，而不是直接暴露MinIO服务端口。这样后续如果需要做CDN加速或流量统计，只需要在反向代理层调整配置即可，完全不影响系统代码。

5. 常见问题排查与部署实战指南

5.1 数据库连接与索引性能排查

影院购票系统上线后最常遇到的性能问题，就是列表页越查越慢。排查思路先看MyBatis的执行SQL日志，确认命中哪些索引，然后使用EXPLAIN命令分析SQL执行计划。优先排查是否出现全表扫描，比如订单列表页查询条件里包含了user_id、status、order_no，如果只给user_id建了索引，而status和order_no没有索引，那么查询效率会大打折扣。

我遇到过的一个实际案例是：某影院上线一个月后，运营反馈“用户订单列表打开要5秒”。日志定位到查询订单列表时，MyBatis分页查询的count语句使用COUNT(*)统计所有订单数量，而订单表此时已经有几十万条数据。这个场景不适合用乐观的精确COUNT，我通过修改分页插件配置，在超过一定数据量时改用近似COUNT估算，列表加载速度从5秒降到了300毫秒。如果你的项目也用了PageHelper分页插件，建议检查是否开启了合理的分页优化参数。

5.2 SpringBoot项目启动失败的常见原因

SpringBoot项目启动失败，90%是以下三类问题。

第一类：端口被占用。排查命令是netstat -ano | findstr 8080（Windows）或lsof -i:8080（Linux/Mac），找到占用端口的进程并杀除，或者修改application.yml里的server.port配置。

第二类：数据库连接失败。检查MySQL服务是否启动、连接URL中的IP/端口/库名是否正确、账号密码是否有权限。这里要注意MySQL 8.0对连接时区要求更严格，建议在JDBC连接串中显式指定serverTimezone=Asia/Shanghai，否则经常报时区错误。

第三类：依赖版本冲突。SpringBoot的parent版本和MyBatis-Starter版本、MySQL驱动版本之间如果存在不兼容，启动时会报Bean创建异常或找不到驱动类。推荐使用阿里云Maven镜像，避免下载慢和依赖缺失的问题。

5.3 Vue前端常见报错与调试技巧

Vue项目最常遇到的报错是跨域问题。本地开发时前端在localhost:8080，后端在localhost:8081，浏览器会拦截跨域请求。解决方法是后端配置CORS过滤器，允许指定来源访问，或者在开发时使用代理转发（Vue CLI配置proxy）。生产环境部署时通常用Nginx做反向代理，把/api路径转发到后端服务，这样前端和后端属于同源，跨域问题自然消失。

第二个常见问题是打包上线后白屏。多数原因是构建出的静态资源路径不对，或者路由使用了history模式但Nginx没有配置try_files回退规则。使用history模式时，Nginx的配置要在location /下加上try_files $uri $uri/ /index.html，否则刷新页面会出现404。

第三个常见问题是组件间数据传递不生效。比如选座页面选择的座位数据，跳转到订单确认页后发现数据为空。排查思路是先确认Vuex/Pinia中的状态是否在页面跳转后被清空，看是不是刷新导致状态丢失。如果订单确认页必须支持刷新后数据不丢失，就需要把关键的选座数据持久化到sessionStorage中，在页面初始化时重新读取。

5.4 系统部署上线完整实操记录

影院购票系统的生产部署我推荐使用Docker Compose编排，虽然增加了一层学习成本，但后续升级扩容和搬迁服务器会省心很多。

基础环境是三台服务：MySQL 8.0容器、后端服务容器、Nginx前端容器。我这里不再展开完整的Dockerfile写法，只强调几个关键配置点。

MySQL容器要挂载数据卷，防止容器重建后数据丢失。后端容器要设置环境变量注入数据库连接信息，不要写死在application.yml里。Nginx配置中前端静态文件用挂载目录，API请求代理到后端容器的服务名和端口，容器间通信使用docker-compose定义的自定义网络。

部署完成后，第一步要验证健康检查接口——SpringBoot的actuator健康检查端点；第二步用管理员账号登录后台系统，尝试执行影片新增、排片新增等写操作，确认数据库写入正常；第三步用真实手机号注册一个前端测试账号，完整走一遍“浏览影片-选择场次-选座-创建订单-模拟支付-查看订单”的流程；第四步验证订单超时未支付的座位释放功能是否生效；最后检查Nginx的错误日志和容器日志，确认没有异常堆栈输出。

5.5 数据备份与日常维护

影院是7x24小时营业的业务，数据库备份是绝对不能省略的运维工作。建议每天凌晨执行一次MySQL全量备份，备份文件保留近7天的版本。备份命令可以直接用mysqldump：

mysqldump -u root -p your_database --single-transaction --quick --routines > backup_$(date +%Y%m%d_%H%M%S).sql

--single-transaction参数用于数据一致性，避免备份过程中业务写入导致数据不一致。日常维护还要关注MySQL的连接数和慢查询日志。连接数被打满时，前端后续请求基本都会卡死，这时要检查应用层是否出现了连接泄漏——常见原因是某些查询后没有关闭连接，或者线程池配置过小导致排队。

我在实际项目中还养成了一个习惯：每周检查一次慢查询日志，把执行时间超过1秒的SQL捞出来分析，优先优化访问频繁的查询。这套影院系统的首页影片列表接口、场次查询接口、座位状态查询接口是高频接口，任何一次慢查询都会直接影响用户体验，必须重点盯防。

6. 我个人在开发中的一些体会

整套系统从数据库建表到前端页面全部跑通，中间踩过的坑有不少，但让我印象最深的还是选座模块的并发问题。当时我使用MySQL悲观锁（SELECT ... FOR UPDATE）实现锁座，结果压测时发现并发量一上来，锁冲突导致数据库连接池耗尽，接口响应时间飙到了十几秒。后来改成乐观锁加重试机制，性能提升非常明显，用户抢座的体验也顺滑了很多。这里我想提醒你：技术方案没有绝对的好与坏，只有适不适合当前的业务量和架构规模。

如果你准备照着这个项目自己动手做一遍，我的建议是先不要急着写代码，花一天时间把数据库的表结构设计清楚、把核心业务状态流转图理顺。表结构和状态设计一旦定了，后续的开发基本就是“体力活”；反而是在开发过程中反复改动表结构，才会让项目越做越乱。

最后分享一个提高开发效率的小技巧：使用MyBatis的代码生成器，根据数据库表结构自动生成实体类、Mapper接口和XML映射文件，能省掉大量重复的CRUD代码。生成之后再根据自己的业务需求调整复杂SQL和动态查询条件，效率比纯手写高好几倍。这个技巧几乎适用所有MyBatis项目，算是我踩过几年坑后最推荐的一招。