简介这份文档围绕基于Java与Spring Boot的电影在线订票选座系统展开面向具备一定Java基础、希望学习或从事在线票务平台设计与开发的专业人员也可为创业者规划票务服务需求提供参考。内容梳理普通用户、会员与管理员三类角色的功能边界并给出系统设计、技术选型与实作细节涉及Spring Data JPA、Thymeleaf、MySQL及IntelliJ IDEA环境下的开发与编译运行流程。资源包共1个docx文件约34KB集中呈现功能说明、系统截图位置、技术介绍、核心代码模块示例、操作演示与项目总结便于按章节理解数据模型和业务流程。已有315人学习适合据此把握订票选座系统的整体结构、关键组件用法与后续改进方向并对照代码示例加深对业务逻辑实现的理解。1. 需求先立住一张电影票背后的三类角色与十四个功能点做电影在线订票系统的人十个里有八个在第一步就走偏一上来就画座位图把「选座」当成系统核心做到一半才发现会员积分、订单状态、退改签、后台统计全都没地方挂。真正支撑整个系统的是订单座位只是订单身上的一个属性。这个顺序一旦搞反后面越写越乱。这套方案要解决的就是这件事以 Java 为语言底座用 Spring Boot 做后端服务Spring Data JPA 管数据持久化Thymeleaf 渲染页面MySQL 存业务数据IntelliJ IDEA Maven 作为开发与构建环境把普通用户、会员、管理员三类角色的十四个功能点收进一套可运行、可交付的工程里。适合两类人一是有 Java 语法基础、要交一份完整课设或毕设的学生二是需要一个能跑通的在线票务原型、准备往上加业务的公司开发者。2. 技术选型与总体架构为什么是 Spring Boot JPA Thymeleaf 这套组合技术选型这件事最怕的不是选错而是选了一个自己讲不清理由的方案。答辩现场被问一句「你为什么不用前后端分离」答不上来前面写的几千行代码在评委眼里就掉了一个档次。2.1 三条技术路线的对比与取舍把常见的三种做法摆在一起看差别其实很清楚维度方案 ASpring Boot Thymeleaf方案 BSpring Boot Vue 分离方案 CServlet JSP工程数量1 个 Maven 工程2 个工程后端 前端1 个 war 工程启动方式java -jar单进程后端 8080 前端 5173需跨域配置外置 Tomcat 部署页面改动改 HTML 刷新即见改完要重新构建前端改完要重新部署联调成本几乎为零接口文档、跨域、代理三件套中等团队分工不适合多人并行前后端可并行不适合适用场景课设、毕设、中小型票务系统有前端资源的团队项目老系统维护选 A 的理由不是它更先进而是它更适合交付。一套在线订票系统页面数量大概在二十个左右首页、影片列表、详情、选座、订单确认、支付、个人中心、后台七八个管理页。这个量级下前后端分离带来的收益抵不过它带来的麻烦——交付时对方要装 Node、要npm install、要起两个进程任何一步失败都是黑匣子。服务端渲染一个 jar 包起来浏览器打开就能用验收环境再差也跑得动。Thymeleaf 还有一个实际好处它渲染出来就是标准 HTML模板片段fragment可以像积木一样复用后台表格页和前台卡片列表能共用同一套样式骨架改一处全站生效。2.2 四层职责划分Controller 只做参数校验业务规则全部下沉分层不是形式主义是为了让「改一个功能」不用翻五个文件。这套系统按四层切Controller接收请求、绑定参数、做Valid校验、返回统一结果体。不写业务判断不碰数据库。Service业务规则的唯一归属地事务边界也在这里。折扣怎么算、积分怎么加、座位能不能选全在这一层。Repository继承JpaRepository的接口只声明查询方法不写实现。Entity / DTOEntity 对应数据库表DTO 对应请求和响应。两者不混用避免前端能直接改到role这种敏感字段。RestController RequestMapping(/api/user) public class UserController { private final UserService userService; // 构造器注入单测里能直接 new不依赖容器反射 public UserController(UserService userService) { this.userService userService; } PostMapping(/register) public ApiResultVoid register(Valid RequestBody RegisterRequest req) { userService.register(req.getUsername(), req.getRawPassword(), req.getPhone()); return ApiResult.ok(注册成功); } PostMapping(/login) public ApiResultString login(Valid RequestBody LoginRequest req, HttpSession session) { User user userService.login(req.getUsername(), req.getRawPassword()); // 登录态放会话Thymeleaf 用 ${session.LOGIN_USER} 直接取不用再查库 session.setAttribute(LOGIN_USER, user); return ApiResult.ok(user.getRole().name()); } }这段代码里三个决定值得说清楚。第一用构造器注入而不是Autowired字段注入字段注入在单元测试里拿不到实例只能靠反射塞值是个长期隐患。第二RegisterRequest是 DTOusername上加NotBlank、Size(min4,max16)rawPassword上加Pattern校验交给框架Service 里就不用写一堆if (xxx null)。第三返回体统一包一层ApiResultT前端和模板都只认code / msg / data三个字段异常处理也在这里收口。2.3 工程目录与关键配置项IDEA 里建 Maven 工程标准结构如下包路径按项目名替换即可movie-ticket/ ├── pom.xml ├── sql/init.sql # 交付时随包附带的建库脚本 ├── src/main/java/com/example/ticket/ │ ├── MovieTicketApplication.java # 启动类必须在所有子包的最外层 │ ├── config/ # 拦截器注册、密码编码器、全局异常 │ ├── controller/ │ ├── service/ │ ├── repository/ │ ├── entity/ │ ├── dto/ │ └── common/ # ApiResult、Role 枚举、BizException └── src/main/resources/ ├── application.properties ├── templates/ # Thymeleaf 页面 └── static/ # css / js / 海报图配置文件里每一行都别乱填后面排查问题一半靠它server.port8080 # 三处编码必须对齐连接串、库字符集、Java 时间类型 spring.datasource.urljdbc:mysql://localhost:3306/movie_ticket?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue spring.datasource.usernameroot spring.datasource.password你的密码 spring.datasource.driver-class-namecom.mysql.cj.jdbc.Driver # 开发期用 update 自动建表交付前改成 validate 并改用 sql/init.sql spring.jpa.hibernate.ddl-autoupdate spring.jpa.show-sqltrue spring.jpa.open-in-viewfalse # 开发期关缓存改完 HTML 刷新就生效 spring.thymeleaf.cachefalse spring.thymeleaf.encodingUTF-8open-in-viewfalse这一行很多人抄配置时顺手删掉因为它会让懒加载报错。但它恰恰是个好东西开着它懒加载异常被藏到视图渲染阶段才暴露等于把问题挪远关掉它问题在开发期就炸出来逼着你用join fetch或 DTO 投影一次查干净。ddl-autoupdate只适合本地开发交付前必须换成validate否则对方机器上表结构可能跟你对不上出了问题只能干瞪眼。3. 数据模型设计七张核心表撑起订票、会员与社区数据模型是这套系统里最不该返工的部分。表结构定完再改Service 层、模板、SQL 全得跟着动。所以先把实体清单摊开逐个过一遍字段。3.1 实体清单与关系梳理按业务域分核心是七张表外围还有四张辅助表表名说明关键关系sys_user用户主表含会员与管理员角色用枚举字段区分不建三张表movie影片信息多对一关联movie_typemovie_type影片类型动作、剧情、动画等后台可增删改screening场次含影厅、开场时间、单价多对一关联movieticket_order订单主表多对一关联sys_user、screeningorder_item订单明细一个座位一行多对一关联ticket_orderpoint_record积分流水多对一关联sys_usercomment/forum_post/announcement/resource评论、论坛、公告、资源中心辅助表字段简单把会员单独拆一张表是常见误判。会员和普通用户的差别只有三处折扣比例、收藏夹容量、优先预约权全是规则层面的差异用一个role字段加几条判断就能覆盖。拆表会带来「一个用户两条记录」的同步问题注册时要写两张表事务一断就出现半截数据。3.2 建表脚本与索引取舍CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL COMMENT BCrypt 密文固定 60 位留冗余, nickname VARCHAR(32), phone VARCHAR(20), role VARCHAR(16) NOT NULL DEFAULT USER COMMENT USER/MEMBER/ADMIN, points INT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 1 COMMENT 1 正常 0 禁用, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE screening ( id BIGINT PRIMARY KEY AUTO_INCREMENT, movie_id BIGINT NOT NULL, hall_name VARCHAR(32) NOT NULL, start_time DATETIME NOT NULL, price DECIMAL(10,2) NOT NULL, KEY idx_movie_start (movie_id, start_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, screening_id BIGINT NOT NULL, seat_no VARCHAR(8) NOT NULL COMMENT 如 A-12, price DECIMAL(10,2) NOT NULL, -- 这条唯一索引是防止同座位重复售出的最后一道闸 UNIQUE KEY uk_screening_seat (screening_id, seat_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;uk_screening_seat这条唯一索引是整张表里最重要的约束。应用层的「先查再插」在有并发的情况下必然出现缝隙两个人几乎同时查到座位空闲然后都插进去。数据库唯一索引是最后一道物理防线插不进去就抛DuplicateKeyException捕获后转成「该座位已被抢占」的友好提示。金额字段统一用DECIMAL(10,2)不用FLOAT也不用DOUBLE。浮点数做折扣乘法会出现59.400000000000006这种值页面显示难看对账还会差几分钱。Java 侧对应BigDecimal两边保持一致。3.3 角色枚举与后台权限拦截角色用一个枚举落地别用魔法字符串public enum Role { USER, // 普通用户浏览、下单、评论 MEMBER, // 会员额外折扣、积分、优先预约、更大收藏夹 ADMIN // 管理员用户管理、影片管理、论坛监督、数据看板 }后台路径统一挂/admin/**用一个拦截器把非管理员挡在外面Component public class AdminInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) throws IOException { User user (User) req.getSession().getAttribute(LOGIN_USER); if (user null || user.getRole() ! Role.ADMIN) { // 未登录跳登录页已登录但角色不对给明确提示别都跳同一个地方 resp.sendRedirect(/login?redirect req.getRequestURI()); return false; } return true; } }拦截器要在WebMvcConfigurer里注册并且excludePathPatterns(/static/**, /css/**, /js/**, /poster/**)否则后台登录页的样式会被一起拦掉页面变成一堆裸 HTML——这个现象很迷惑人第一次遇到容易以为是 Thymeleaf 坏了。4. 核心模块实现注册登录、影片检索、下单事务与会员积分前面搭好了骨架这一章填肉。四个模块是这套系统的主动脉每个都有容易写错的地方。4.1 注册登录BCrypt 加盐与登录态保持密码存储是这类项目最容易被挑毛病的地方。原始版本里UserService.register()直接userRepository.save(user)密码明文入库这是硬伤。改成 BCrypt 只需要两步注册一个编码器 Bean存的时候编码、比对的时候用matches。Service public class UserService { private final UserRepository userRepository; private final PasswordEncoder passwordEncoder; public UserService(UserRepository userRepository, PasswordEncoder passwordEncoder) { this.userRepository userRepository; this.passwordEncoder passwordEncoder; } Transactional public void register(String username, String rawPassword, String phone) { if (userRepository.existsByUsername(username)) { throw new BizException(用户名已被占用); } User u new User(); u.setUsername(username); // 每次 encode 的盐都不同同一个密码两次入库的密文也不一样 u.setPassword(passwordEncoder.encode(rawPassword)); u.setPhone(phone); u.setRole(Role.USER); userRepository.save(u); } public User login(String username, String rawPassword) { User u userRepository.findByUsername(username) .orElseThrow(() - new BizException(用户名或密码错误)); if (u.getStatus() ! 1) { throw new BizException(账号已被禁用请联系管理员); } if (!passwordEncoder.matches(rawPassword, u.getPassword())) { // 错误提示不区分是用户名错还是密码错避免被批量试出有哪些账号 throw new BizException(用户名或密码错误); } return u; } }编码器 Bean 放在config包里Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); }。BCrypt 每次生成的盐都嵌在密文里所以不需要额外存盐字段VARCHAR(100)够用。Transactional加在注册方法上是因为后续要扩成「注册 送新人积分」两步写操作现在加上省得回头改。4.2 影片检索动态条件加 JPA Specification前台搜索是典型的多条件组合关键词、类型、排序、分页四个条件任意组合写if嵌套会变成七八个 Repository 方法。用Specification拼条件一个方法通吃。public PageMovie search(String keyword, Long typeId, String sort, int page, int size) { SpecificationMovie spec (root, query, cb) - { ListPredicate ps new ArrayList(); if (StringUtils.hasText(keyword)) { // 片名或主演命中都算用 or 拼 ps.add(cb.or( cb.like(root.get(title), % keyword %), cb.like(root.get(actors), % keyword %) )); } if (typeId ! null) { ps.add(cb.equal(root.get(type).get(id), typeId)); } return cb.and(ps.toArray(new Predicate[0])); }; // 前端传 page 从 1 开始JPA 从 0 开始这里要减一 PageRequest pageable PageRequest.of(page - 1, size, buildSort(sort)); return movieRepository.findAll(spec, pageable); } private Sort buildSort(String sort) { if (score.equals(sort)) return Sort.by(Sort.Direction.DESC, score); if (hot.equals(sort)) return Sort.by(Sort.Direction.DESC, ticketCount); return Sort.by(Sort.Direction.DESC, releaseDate); }两个参数细节PageRequest.of的页码从 0 起算前端表单一般从 1 开始忘了减一会导致第一页永远跳过两条数据Sort里的字段名必须是实体属性名而不是数据库列名写release_date会启动即报错。%keyword%这种前后模糊匹配走不了 B 树索引数据量上万条以后会明显变慢。课设、毕设的数据量完全够用如果真要上线通常的做法是给title加 MySQL 全文索引或者把检索挪到独立的搜索组件上。这一点写进文档的「未来改进方向」比硬撑更实在。4.3 下单流程事务边界、行锁与死锁规避下单是这个系统里唯一必须慎重的写操作涉及座位占用、金额计算、库存一致性。默认的「查一次、插一次」在单机单人测试下永远不出问题一并发就翻车。Transactional(rollbackFor Exception.class) public Long createOrder(Long userId, Long screeningId, ListString seats) { // 悲观锁锁住场次行把同一场次的并发下单串行化 Screening sc screeningRepository.findByIdForUpdate(screeningId) .orElseThrow(() - new BizException(场次不存在)); if (sc.getStartTime().isBefore(LocalDateTime.now())) { throw new BizException(该场次已开场无法购票); } // 座位号先排序再处理避免两个请求以相反顺序占座造成死锁 ListString sortedSeats seats.stream().distinct().sorted().toList(); BigDecimal total BigDecimal.ZERO; ListOrderItem items new ArrayList(); for (String seat : sortedSeats) { if (orderItemRepository.existsByScreeningIdAndSeatNo(screeningId, seat)) { throw new BizException(座位 seat 已被选走请重新选座); } OrderItem item new OrderItem(); item.setScreeningId(screeningId); item.setSeatNo(seat); item.setPrice(sc.getPrice()); items.add(item); total total.add(sc.getPrice()); } TicketOrder order new TicketOrder(); order.setUserId(userId); order.setScreeningId(screeningId); order.setAmount(total); order.setStatus(OrderStatus.UNPAID); // 待支付 order.setExpireAt(LocalDateTime.now().plusMinutes(15)); orderRepository.save(order); items.forEach(i - i.setOrderId(order.getId())); orderItemRepository.saveAll(items); return order.getId(); }几个要点findIdForUpdate是自己写的Lock(LockModeType.PESSIMISTIC_WRITE)查询方法作用是给场次那一行加排他锁。座位排序这一步看着多余实际上是死锁的后悔药——A 请求要 A1、B2B 请求要 B2、A1不加排序两边互相等数据库检测到死锁会主动回滚一方日志里出现Deadlock found when trying to get lock。排序后所有事务的加锁顺序一致死锁概率直接归零。订单状态机也要提前定死只有四种UNPAID → PAID → REFUNDED以及UNPAID → CANCELLED。用Scheduled(fixedDelay 60000)每分钟扫一遍超时未支付的订单改状态并释放座位。这个扫描任务要加Transactional否则状态改了座位没放会留下永久占用的幽灵座位。4.4 会员折扣与积分结算用 BigDecimal 而不是 double折扣和积分是会员功能的核心也是最容易出现「差几分钱」的地方。public BigDecimal applyDiscount(BigDecimal original, Role role) { if (role Role.MEMBER) { // 九折HALF_UP 四舍五入到分 return original.multiply(new BigDecimal(0.90)).setScale(2, RoundingMode.HALF_UP); } return original.setScale(2, RoundingMode.HALF_UP); } Transactional public void settlePoints(Long userId, BigDecimal paidAmount) { // 实付金额向下取整当积分1 元 1 分不搞小数积分 int gain paidAmount.setScale(0, RoundingMode.DOWN).intValue(); if (gain 0) return; userRepository.addPoints(userId, gain); // update sys_user set points points ? pointRecordRepository.save(new PointRecord(userId, gain, 购票返积分)); }积分的写法有个原则sys_user.points只是余额快照真实数据在point_record流水表里。只改余额不留流水用户一旦质疑积分不对你连查的依据都没有。对账逻辑就是select sum(change) from point_record where user_id ?必须等于points这条校验写进验收清单里非常加分。折扣比例别设成 0 或接近 0。金额为 0 的订单会绕过支付校验等于给了一个免费出票的口子。真要搞大额优惠用优惠券表单独建模别在折扣系数上玩花活。4.5 页面渲染Thymeleaf 片段复用与时间格式化前端页面二十来个如果每个都复制粘贴一遍卡片结构改一次样式要动二十个文件。用th:fragment抽公共块!-- templates/fragments/card.html -- div th:fragmentmovieCard(m) classmovie-card img th:src{/poster/ ${m.poster}} th:alt${m.title} h3 th:text${m.title}片名/h3 span th:text${#temporals.format(m.releaseDate, yyyy-MM-dd)}2024-01-01/span a th:href{/movie/ ${m.id}}查看详情/a /div调用方写div th:replace~{fragments/card :: movieCard(${movie})}/div。{...}会自动补上应用的上下文路径将来部署到/ticket这种子路径下也不用改${...}是变量表达式。#temporals是处理LocalDate、LocalDateTime的工具对象——Spring Boot 3 用的 Thymeleaf 3.1 已把它并入核心Spring Boot 2.x 需要额外引thymeleaf-extras-java8time依赖这一点版本对不上就会报「无法解析 #temporals」属于典型的环境血泪经验。5. 避坑与排查五个最容易在上线前夜翻车的问题下面五条都是这套系统里真实会撞上的按「现象 → 原因 → 解决」整理遇到时照单排查就行。5.1 一访问就 500Table movie_ticket.sys_user doesnt exist现象IDEA 里点运行控制台走完绿色启动日志浏览器一打开首页直接 500堆栈里是SQLSyntaxErrorException: Table ... doesnt exist。原因三种可能。ddl-auto被设成了none或validate连接串里的库名写错实际连到了另一个空库或者实体类没加Entity、放在了启动类的兄弟包而不是子包下扫描不到。解决开发期先用ddl-autoupdate让它自动建表确认表出来了再改交付前统一用sql/init.sql手动建库建表然后把ddl-auto换成validate让启动时校验而不是修改。启动类的包路径必须是最外层SpringBootApplication只扫描它所在包及其子包这一点写在 README 第一行。5.2 时间差 8 小时、中文变问号现象下单时间入库比本地时间少 8 小时页面上显示的还是对的一导报表就露馅或者评论区出现一串?????。原因MySQL 连接没设serverTimezone驱动默认按 UTC 处理LocalDateTime字符集三处不一致——连接串没写characterEncodingutf8、库默认latin1、表继承了库的字符集。解决三处对齐。连接串加serverTimezoneAsia/ShanghaiuseUnicodetruecharacterEncodingutf8建库语句写DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_general_ciJava 侧统一用LocalDateTime不要一半Date一半LocalDateTime混着来。改完记得把已有表也ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4只改库不改表等于没改。5.3 两个人抢同一个座位两笔订单都成功现象本地自测怎么点都没事答辩演示时开两个浏览器同时下单同一个座位两笔订单都生成了座位卖出两张票。原因Service 里是「先existsBy查一次再save插一次」查和插之间没有任何锁。默认隔离级别下普通查询不加锁两个事务都能读到「座位空闲」。解决三层防护叠上。数据库层加UNIQUE KEY (screening_id, seat_no)这是最后一道物理防线应用层用悲观锁锁场次行把同场次的下单串行化座位号排序后再处理避免相反加锁顺序引发死锁。捕获到DuplicateKeyException时转成BizException(座位已被抢占请重新选座)别把原始堆栈甩给用户。5.4 改了 HTML 刷新没变化样式还 404现象Thymeleaf 模板改完浏览器 F5 还是旧页面或者登录页彻底失去样式控制台一片 404。原因spring.thymeleaf.cache默认为true模板编译后缓存住了IDEA 没开自动编译改的是源文件但target/classes里还是旧副本样式 404 多半是拦截器把/css/**一起拦了。解决开发期显式写spring.thymeleaf.cachefalseIDEA 里打开Build project automatically并允许运行时自动编译拦截器注册时excludePathPatterns(/static/**, /css/**, /js/**, /poster/**)。样式 404 还有一种情况th:href{/css/app.css}写对了但文件放在static/css/之外的目录路径和物理位置对不上。5.5 列表页抛 could not initialize proxy - no Session现象影片列表要显示所属类型名称Controller 里查完返回页面渲染到movie.type.name时抛LazyInitializationException。原因open-in-viewfalse推荐值之后事务在 Service 方法结束时就提交并关闭了 Session实体上的ManyToOne(fetch LAZY)代理对象已经失去连接再去取属性必然失败。解决两条正路。用EntityGraph(attributePaths type)在 Repository 方法上声明一次性抓取关联或者干脆写 DTO 投影select new MovieListVO(m.id, m.title, t.name) from Movie m left join m.type t页面只吃 VO压根不碰懒加载。把open-in-view改回true属于掩耳盗铃问题只是被推迟到更难排查的地方。6. 验收与答辩六项检查加一套讲法到这一步代码能跑了但「能跑」和「能交付」是两回事。我一般会在交付前从零走一遍验收六项检查每项都有明确的合格线检查项怎么查合格线环境可复现删库删表按 README 从零走一遍15 分钟内能完成注册登录三角色权限普通用户直接访问/admin/user返回 302 跳登录不是 500 也不是直接放行订单闭环下单 → 支付 → 取消 → 退款走一遍四种状态流转正确座位能释放回池并发一致性两个浏览器同抢一个座位只成功一单另一单给出友好提示积分对账流水求和 vs 用户余额两者完全相等异常兜底故意传空参数、超长用户名、错误密码返回结构化提示不出现堆栈页面前两项是评委最爱抽查的因为不用懂代码也能验。第三项和第四项能看出你是不是真跑过并发。第五项是我自己的习惯任何涉及余额、库存的功能都必须有一条能自证的等式。答辩讲法上有个反直觉的技巧别按「技术栈 → 功能列表 → 截图」这个顺序讲那是最容易被问到答不上来的讲法。用三段式第一段讲问题——一句话说清这套系统替代了什么手工流程谁在用一天大概多少单。第二段讲关键决策——挑三个讲比如「为什么用服务端渲染而不是前后端分离」「为什么座位唯一索引和悲观锁两套都上」「为什么会员不单独拆表」每个决策都要带上被放弃的那个方案和放弃理由这是加分点因为它证明你比较过。第三段讲尚未解决的问题——直说%keyword%模糊查询走不了索引、支付是模拟的没有对接真实渠道、并发只在单机验证过。评委听完会觉得你清楚边界在哪比硬吹「系统功能完善、性能优异」可信得多。演示顺序也有讲究先演示正常流程登录 → 浏览 → 选座 → 下单 → 支付 → 个人中心看积分再演示一个失败流程抢同一个座位被拦下最后演示后台用户禁用、影片上下架、数据看板。中间一旦卡住别急着解释退回上一页重来一遍比现场 debug 体面。从那以后我每次交方案前都强制走一遍「删库重建 换台机器跑一遍 让不熟悉项目的人照 README 走」。第一次这么做的时候就发现对方在第八分钟卡在了数据库密码上而我自己机器上早就配好了环境变量压根没意识到这是个门槛。这套习惯帮我省掉过不止一次返工。希望帮到你。本文还有配套的精品资源点击获取
