企业官网建设流程全解析

简介：一套基于WEB的车票预订信息系统完整实现，采用Java、Servlet、JSP与MySQL构建，覆盖前端交互、后端业务逻辑与数据存储，面向正在准备毕业设计或课程设计的计算机相关专业学生，也适合想系统梳理Java Web开发流程的开发者。压缩包内共1337个文件，容量55.82MB，包含jsp、html、css、js等前端页面文件，java与class组成的后端源码，jar依赖库、png/jpg/gif图片资源，以及sql数据库脚本和项目配置文件，目录结构清晰，便于按模块研读或直接部署运行。项目还附带视频讲解与实际操作指南，可帮助学习者在MyEclipse中完成环境配置、数据库连接与系统测试。目前已有1105人学习下载，通过该案例可完整掌握Servlet/JSP前后端协作、JDBC数据操作及Web应用发布等关键技能，对提升项目实战能力很有帮助。

1. 为什么选“基于WEB的车票预订信息系统”：场景痛点与适用人群

每年寒暑假和节假日，客运站窗口前都排着长队，旅客问询、查票、出票、找零一套流程走下来通常要好几分钟。而另一边，车站调度员手里只有一张Excel表，卖了多少票、哪个班次余票紧张、退票后座位释放是否及时，全靠人工盯。这种“旅客排队、窗口手工记账”的模式，在高峰期就是一场灾难。车票预订信息系统的核心价值，就是把查票、订票、支付确认、订单管理这几件事从线下搬到线上，让旅客自己查自己订，让管理员通过后台看数据而不是看纸单。

这套方案的技术选型是经典的JAVA + JSP + Servlet + MySQL组合，不使用重量级框架，适合课程设计和毕业设计场景。它由一组功能明确的Web页面构成，覆盖用户注册登录、车次查询、车票预订、订单管理以及后台车次与价格维护等完整业务闭环。如果你正在做JAVA Web方向的课设或毕设，或者需要一个直接可用的车票预订管理系统原型来改造，这套方案能帮你省掉大量从零搭建的时间和踩坑的成本。接下来我会从需求分析、总体设计、数据库设计到核心模块实现一条线拆开讲，每个环节都给出可以直接落地的做法。

2. 需求分析与技术选型：先把功能边界划清楚

2.1 角色与用例：谁在用这个系统

任何Web系统在设计前都要先定义用户角色，车票预订信息系统也不例外。这个系统实际参与业务的有两类人：前台旅客和后台管理员。旅客关心的是能不能快速找到车次、有没有余票、订票后在哪里看订单；管理员关心的是车次信息怎么维护、票价怎么改、哪些订单需要处理。围绕这两个角色，我通常会把用例图拆成两组：旅客侧包含注册登录、查询车次、在线预订、查看/退订订单，管理员侧包含车次管理、票价调整、订单查询与统计。两组用例之间通过数据库表关联，不绕不混。

边界划清楚之后，非功能性需求也要写明白。响应时间上，查询车次接口要在1秒内返回结果，页面加载不能超过3秒；并发能力上，按课程设计的量级，支持50个用户同时在线查询、10个用户同时提交订单即可达标——不要一上来就谈集群、缓存，那是生产环境的事。可靠性上，数据库需要定期备份，订单操作要能追踪。把这些写进需求文档的第一章，答辩时评委问“为什么这么设计”，你才有依据可讲。

2.2 技术栈选型：为什么是JSP + Servlet而不是SSM

现在看到“JAVA Web”很多人第一反应是Spring Boot + MyBatis，但车票预订信息系统这类课设项目，用JSP + Servlet + JavaBean恰恰是更稳妥的选择。原因有三：第一，JSP + Servlet是Java Web的基础，课程设计考察的就是这层能力，直接上框架反而容易被质疑“是不是自己写的”；第二，这个项目的业务逻辑复杂度不高，核心是CRUD加少量事务处理，用Servlet做控制层、JSP做视图层、JavaBean做模型层完全够用；第三，答辩时老师问的通常是Servlet生命周期、请求转发与重定向、Session管理这些基础问题，如果你用的是JSP + Servlet，能答得更有底气。

数据库选型上，MySQL是主流选择。JDBC连接、数据库驱动、数据库连接池（DBCP或C3P0）这些知识点都在课设考察范围内。开发环境建议使用Eclipse或IDEA，配上Tomcat 8.5和MySQL 5.7。这里有个需要注意的地方：Tomcat版本和JDK版本要匹配，Tomcat 8.5对应JDK 1.8，不要用太新的版本，后面第五章会专门说版本不匹配导致的坑。

2.3 环境搭建与项目目录规范

环境搭建部分，我建议按照“JDK → MySQL → Tomcat → IDE”这个顺序来。JDK安装后配置JAVA_HOME和PATH环境变量，MySQL安装后设置root密码并创建数据库，Tomcat解压到非中文路径（这点很重要，中文路径会导致部署失败），最后在IDE中配置Tomcat运行时环境。每一步完成后都做一次验证：JDK用java -version确认，Tomcat启动后访问http://localhost:8080看到默认页面，MySQL用命令行或可视化工具连接一次。

项目目录结构上，标准的Web项目要区分开源码和配置文件。src目录下按包名组织：com.xxx.entity放实体类、com.xxx.dao放数据访问层、com.xxx.servlet放控制层、com.xxx.util放工具类（如DBUtil）。WebContent目录下放JSP页面、CSS和JS文件，WEB-INF/web.xml做部署描述。这个结构在后期的代码部署和维护中能省很多事——我见过不少同学把所有JSP页面堆在根目录，Servlet里直接写JDBC代码，项目跑起来没问题但答辩时被问了两个问题就露馅了。分层清晰本身也是评分项。

3. 总体架构设计：三层结构与四个核心模块的职责划分

3.1 三层架构：页面、控制、数据怎么协作

车票预订信息系统的架构采用经典的三层设计：表示层（JSP页面）、业务逻辑层（Servlet + JavaBean）、数据访问层（DAO + JDBC）。这三者的协作方式很简单：浏览器发起HTTP请求到达Servlet，Servlet通过request对象接收参数，调用JavaBean中的业务方法处理数据，JavaBean再通过DAO对象访问数据库，最后把结果通过request域或session域返回给JSP页面渲染展示。

这里要特别强调Servlet在中间承担的控制职责。查询车次时，Servlet需要做三件事：接收前端传来的出发地、目的地、日期参数，调用业务层方法查询数据库，把查询结果放入request.setAttribute("resultList", list)后转发到queryResult.jsp。注意这里用forward而不是sendRedirect——request域中的数据在重定向后会丢失，这是初学者最容易犯的错误之一。另外，所有Servlet类在web.xml中完成映射配置，使用注解方式虽然代码量少，但课设阶段用配置文件更能展示你对URL映射机制的理解。

3.2 功能模块划分：前台两个模块、后台两个模块

整个系统按功能边界可以拆成四个核心模块：用户管理模块、车次查询与预订模块、订单管理模块、后台管理模块。用户管理模块负责注册、登录、密码加密存储和Session会话维护；车次查询与预订模块是本系统的核心，负责按条件查询车次、展示余票情况、生成预订请求并锁定座位；订单管理模块让用户查看自己的历史订单、执行退票操作，同时让管理员可以查看所有订单；后台管理模块提供车次信息的增删改查和票价的调整功能。

模块划分的目的是让代码各司其职，避免一个Servlet处理所有请求的单体化。我的做法是：每个模块对应一个Servlet类，例如LoginServlet、RegisterServlet、QueryServlet、BookServlet、OrderServlet、AdminServlet。每个Servlet根据请求参数中的action字段决定具体执行的操作，比如BookServlet接收action=addPage时跳转到填写乘客信息页面，接收action=confirm时执行真正的订票逻辑。这种设计既清晰又便于扩展，后期要加一个支付回调接口，只需要在BookServlet中增加一个case分支即可。

3.3 页面流转：一次完整订票的数据走向

页面流转是整个系统设计中最容易被忽略但答辩时大概率被问到的部分。我用文字描述一次典型订票流程，把每个环节的数据流向说清楚。

用户打开login.jsp输入账号密码，表单以POST方式提交到LoginServlet，Servlet调用UserDao.findByUsernameAndPassword()查询用户表。验证通过后，把用户对象放入Session，同时sendRedirect到index.jsp（首页），这样浏览器地址栏会更新，刷新页面也不会重复提交表单。用户选择出发地、目的地和日期后点击查询，query.jsp提交到QueryServlet，Servlet组装SQL条件并调用ScheduleDao.findByCondition()返回车次列表，通过forward到queryResult.jsp展示。用户点击某车次的“预订”按钮，请求转到BookServlet的addPage分支，展示该车次剩余座位和票价，填完乘车人信息后提交confirm分支，此时系统先检查余票数是否大于0，再执行INSERT订单操作和UPDATE余票减一的数据库事务，成功后跳转到orderSuccess.jsp，失败则提示余票不足。

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String action = request.getParameter("action"); if ("confirm".equals(action)) { // 1. 获取表单参数：车次编号、乘车人姓名、证件号、购票数量 String userId = request.getSession().getAttribute("userId").toString(); String scheduleId = request.getParameter("scheduleId"); String passengerName = request.getParameter("passengerName"); int ticketCount = Integer.parseInt(request.getParameter("ticketCount")); // 2. 检查余票是否充足（下面的checkRemainingTickets方法内部查询座位表） if (!orderService.checkRemainingTickets(scheduleId, ticketCount)) { request.setAttribute("errorMsg", "余票不足，请选择其他车次"); request.getRequestDispatcher("book.jsp?scheduleId=" + scheduleId).forward(request, response); return; } // 3. 创建订单并锁定座位（事务操作在Service层完成） int orderId = orderService.createOrder(userId, scheduleId, passengerName, ticketCount); response.sendRedirect("orderSuccess.jsp?orderId=" + orderId); } }

这段代码的设计要点在于：余票检查与订单创建之间可能发生并发问题，所以createOrder必须在数据库层面使用事务，先执行SELECT ... FOR UPDATE锁定座位行，再判断余票、插入订单并更新余票数。等到第五章我会专门讨论并发抢票这个坑——如果不做行锁，两个用户同时买最后一张票时就会出现超卖。sendRedirect和forward的使用在这里也有讲究：订票成功是Post/Redirect/Get模式，防止用户刷新页面重复提交订单；而查询失败时用forward保留request域中的提示信息回显给用户。

4. 数据库设计与核心模块实现：从建表SQL到JSP页面实战

4.1 数据表设计：这五张表怎么支撑整个系统

车票预订信息系统的数据表设计直接影响开发进度和后期维护成本。多数课设会用到五张核心表：用户表（t_user）、车次表（t_schedule）、站点表（t_station）、订单表（t_order）以及座位余量表（t_seat_stock）。前四张表是业务主表，第五张表在并发控制中起着关键作用，很多人在架构设计阶段会漏掉它。

用户表主要字段包括id（自增主键）、username（唯一索引）、password（MD5加密存储，不要明文存）、real_name、id_card、phone、create_time。车次表包含id、schedule_no（车次编号如G1001）、depart_station_id（出发站ID）、arrive_station_id（到达站ID）、depart_time、arrive_time、ticket_price、seat_type（座位类型）、train_type（车型）。站点表则简单一些，存id和station_name、city_name。订单表需要关联用户和车次，包含订单编号order_no、用户ID、车次ID、乘车日期、乘车人姓名、证件号、购票张数、订单状态（正常/已退票）、下单时间。座位余量表是防超卖的关键，包含车次ID、乘车日期、总座位数、已售座位数，用(schedule_id, travel_date)做唯一约束。

CREATE TABLE t_seat_stock ( id INT PRIMARY KEY AUTO_INCREMENT, schedule_id INT NOT NULL COMMENT '关联t_schedule表的车次ID', travel_date DATE NOT NULL COMMENT '乘车日期', total_seats INT NOT NULL DEFAULT 100 COMMENT '该车次总座位数', sold_seats INT NOT NULL DEFAULT 0 COMMENT '已售座位数', UNIQUE KEY uk_schedule_date (schedule_id, travel_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这张表的SQL是系统防超卖的第一道保障。UNIQUE KEY uk_schedule_date保证同一车次同一天只存在一条余票记录，后续更新时用UPDATE t_seat_stock SET sold_seats = sold_seats + 1 WHERE schedule_id = ? AND travel_date = ? AND sold_seats + 购票张数 <= total_seats，通过受影响行数是否为1来判断是否抢票成功。数据库的存储引擎用InnoDB而不是MyISAM——只有InnoDB支持行级锁和事务，MyISAM在高并发预订场景下会出现严重的锁表问题。字符集统一用utf8mb4，避免输入生僻字时出现中文乱码。

4.2 数据库连接工具类：一次配置，到处使用

数据库连接是每个DAO共用的基础能力，我会在项目里写一个DBUtil工具类，它负责加载JDBC驱动、获取数据库连接和关闭资源。这里使用DBCP连接池，避免在每次请求时手动创建Connection造成的性能浪费。

import java.sql.Connection; import java.sql.SQLException; import javax.sql.DataSource; import org.apache.commons.dbcp2.BasicDataSource; public class DBUtil { private static DataSource dataSource; static { BasicDataSource ds = new BasicDataSource(); ds.setDriverClassName("com.mysql.jdbc.Driver"); ds.setUrl("jdbc:mysql://localhost:3306/ticket_db?useUnicode=true&characterEncoding=utf8&useSSL=false"); ds.setUsername("root"); ds.setPassword("123456"); ds.setInitialSize(5); // 初始连接数 ds.setMaxTotal(20); // 最大连接数 ds.setMaxIdle(10); // 最大空闲连接数 dataSource = ds; } public static Connection getConnection() throws SQLException { return dataSource.getConnection(); // 从连接池获取，用完必须归还 } public static void close(Connection conn, java.sql.Statement stmt, java.sql.ResultSet rs) { // 标准关闭顺序：rs先关，stmt其次，conn最后 } }

连接池参数需要根据使用场景做调整。课设阶段访问量不大，initialSize=5、maxTotal=20足够了，如果你的项目里还包含后台管理页面的批量数据导出，maxTotal可以适当调大到50。注意JDBC URL中useUnicode=true&characterEncoding=utf8这两个参数必不可少，少了它们，页面提交的中文数据写进数据库就会变成乱码。类名如果使用较新的MySQL驱动版本，则要写成com.mysql.cj.jdbc.Driver，老驱动在新版本上会抛出ClassNotFoundException。

4.3 用户登录与Session会话管理：从表单到拦截器

登录模块是前后台共用的门户，也是答辩必考点。LoginServlet的完整逻辑分为四个步骤：接收用户名和密码参数并进行非空校验；调用UserDao查询用户；比对MD5加密后的密码；登录成功后把用户信息放入Session并跳转到对应主页。这里有一个容易忽略的安全细节：注册时密码要用MD5加盐存储，而不是明文直接入库；登录时也要先MD5再比对。可以参考下面的实现：

String inputPassword = MD5Util.md5(password + userSalt); // userSalt为用户注册时生成的随机盐值 User user = userDao.findByUsernameLogin(username, inputPassword); if (user != null) { request.getSession().setAttribute("loginUser", user); if ("admin".equals(user.getRole())) { response.sendRedirect("admin/index.jsp"); } else { response.sendRedirect("index.jsp"); } } else { request.setAttribute("loginError", "用户名或密码错误"); request.getRequestDispatcher("login.jsp").forward(request, response); }

Session的会话管理包含超时设置和权限校验。Tomcat默认Session超时时间为30分钟，如果用户登录后长时间不操作，Session会被销毁，再次提交请求时会因为loginUser为空而跳转回登录页。权限校验我通常用过滤器（Filter）实现——LoginFilter在web.xml中配置过滤规则，检查访问/admin/路径的请求是否包含登录用户且角色为管理员，否则重定向到登录页。答辩时这一块可以主动提，“登录用Session做会话保持，后台页面用Filter做权限拦截，避免未登录用户直接访问URL绕过登录”是评委比较认可的回答思路。

4.4 车次查询与预订实现：SQL动态拼装与事务控制

车次查询是旅客输入条件最多的页面，出发地、目的地、日期都是可选参数，SQL需要动态拼装。这里容易出现的坑是拼接SQL时忘记处理条件为空的场景，最终导致查出全部车次。更稳妥的做法是使用PreparedStatement，通过判断参数是否为空来决定是否追加条件以及setObject填充。

public List<Schedule> findByCondition(String depart, String arrive, String travelDate) { StringBuilder sql = new StringBuilder("SELECT s.*, st1.station_name AS depart_name, st2.station_name AS arrive_name "); sql.append("FROM t_schedule s "); sql.append("JOIN t_station st1 ON s.depart_station_id = st1.id "); sql.append("JOIN t_station st2 ON s.arrive_station_id = st2.id WHERE 1=1 "); List<Object> params = new ArrayList<>(); if (depart != null && !depart.isEmpty()) { sql.append("AND st1.station_name LIKE ? "); params.add("%" + depart + "%"); } // arrive与travelDate条件拼装同上 PreparedStatement ps = conn.prepareStatement(sql.toString()); for (int i = 0; i < params.size(); i++) { ps.setObject(i + 1, params.get(i)); } ResultSet rs = ps.executeQuery(); // 遍历封装为Schedule对象列表 }

查询时还有一个加分项：展示车次时把余票数同时显示出来。这需要关联t_seat_stock表，在查询SQL中通过schedule_id和当前日期关联，计算出total_seats - sold_seats作为剩余票数。预订部分的核心是同时操作订单表和座位余量表，必须放在同一个事务里执行。我通常在OrderService中开启手动事务：先关闭自动提交，执行余票检查和INSERT，全部成功后再commit，任何一步抛异常就rollback，最后在finally块中恢复自动提交并关闭资源。把事务控制在Service层而不是DAO层，是为了让一个方法包含的多次数据库操作具备原子性。

4.5 后台管理：车次增删改查与订单统计

后台管理模块是区分“完整方案”和“Demo”的分界线。一个车票预订管理系统如果只有前台查车订票，没有后台管理页面，在评审时会被判定为功能不完整。后台管理至少包含两部分：车次信息管理（新增车次、修改票价、停运删除）和订单管理（按车次查看订单、处理退票申请、按日期统计售票数）。

车次管理页面的设计我建议采用AB面模式：左侧是车次列表，右侧是编辑表单。列表用<c:forEach>遍历车次，每一行都提供“编辑”和“删除”按钮；编辑时点击按钮，JS通过Ajax请求携带车次ID查询详情并回填表单，保存时再提交到AdminServlet的updateSchedule分支。这里与前台共用同一个ScheduleDao，只在Servlet层增加管理员角色校验。删除车次时要注意联表问题：如果该车次已经存在订单，直接删除会造成外键悬空。处理方案是删除前先检查订单表中是否有该车次记录，如果有则将其状态置为“已取消”而非物理删除。

订单统计功能则是展示数据库聚合查询能力的场景。SELECT depart City, COUNT(*) AS orderCount, SUM(ticket_count) AS totalTickets FROM t_order o JOIN t_schedule s ON o.schedule_id = s.id GROUP BY s.depart_station_id，统计结果放到一个HashMap中并传入JSP，用表格或柱状图展示。如果你的方案里还有ECharts图表可视化，可以在这部分加一个按日售票趋势折线图，这是答辩时最容易让评委眼前一亮的功能点——因为大多数同学的页面只有表格没有图形。

5. 高频踩坑与排查指南：JSP项目开发中最容易翻车的五处

5.1 中文乱码：页面、Servlet、数据库三层都要统一编码

现象：数据库查询结果显示出来是问号，或者表单提交的中文保存在数据库中变成乱码；更隐蔽的是页面正常但导出Excel时中文全部乱码。原因：JSP页面编码、Servlet读取请求的编码、数据库连接URL的编码、数据库表字段的字符集，这四个环节只要有一个不一致，乱码就产生了。解决：页面顶部加<%@ page contentType="text/html;charset=UTF-8" language="java"%>，Servlet的doPost开头加request.setCharacterEncoding("UTF-8")，数据库连接URL带上useUnicode=true&characterEncoding=utf8，建表时用DEFAULT CHARSET=utf8mb4，四个条件缺一不可。我排查的时候通常直接在浏览器开发者工具里看请求头Content-Type是不是charset=UTF-8，如果这里没问题就去检查数据库表的编码。

5.2 JDBC驱动找不到或版本不匹配

现象：Tomcat启动正常，但第一次访问数据库相关页面就报ClassNotFoundException: com.mysql.jdbc.Driver。原因分两种：一是jar包没放进WEB-INF/lib目录，放在普通Java项目的build path里Tomcat运行时找不到；二是驱动版本与MySQL版本不匹配，MySQL 8.0以上必须用com.mysql.cj.jdbc.Driver。解决：确认mysql-connector-java版本与MySQL对应，5.7用5.x驱动，8.0用8.x驱动；jar包放置位置必须是WEB-INF/lib并且部署时在部署清单中确认包含。这个坑在每次MAVEN没配好、手动导包的项目里都会出现一次，我自己遇到过两次，后面都养成了检查WEB-INF/lib的习惯。

5.3 并发订票导致余票超卖

现象：最后一张票同时被两个用户提交，两个订单都提示预订成功，库存显示负数。原因：余票检查与扣减余票不是原子操作，查询余票和执行UPDATE之间其他请求穿插执行。解决：使用数据库行锁保证扣减库存的原子性，UPDATE t_seat_stock SET sold_seats = sold_seats + ? WHERE schedule_id = ? AND travel_date = ? AND sold_seats + ? <= total_seats。执行后检查int rows = ps.executeUpdate()的返回值，如果rows == 0说明当前没有可售票，返回失败提示。如果你用的是InnoDB并且开了事务，配合SELECT ... FOR UPDATE也可以达到同样效果。这里要提醒一下，行锁必须在事务范围内才有效，单独执行一条UPDATE不加事务也能保证原子性，但后续的插入订单操作需要和扣减余票一起成功或一起失败。

5.4 JSP页面路径与URL映射不对应，点击跳转404

现象：点击链接后地址栏是http://localhost:8080/ticket/admin/query.jsp，Tomcat返回404，或者页面能打开但CSS/JS加载不出来。原因：JSP页面放在WEB-INF目录下不能直接通过URL访问；相对路径在嵌套目录中会失效；<form action="LoginServlet">在子目录下会指向/子目录/LoginServlet而不是项目根的Servlet。解决：JSP页面不要放WEB-INF里，统一放WebContent根目录或按功能建子文件夹；所有静态资源引用使用绝对路径${pageContext.request.contextPath}/css/style.css；Servlet访问采用${pageContext.request.contextPath}/loginServlet拼路径。这个坑很容易排查——打开浏览器按F12看Network标签，404的请求路径对比一下自己配置的url-pattern就能发现差异。

5.5 数据库连接未关闭导致Tomcat假死或连接池耗尽

现象：跑了一段时间后，第一次点击查询页面非常慢，再点直接报Connection refused或Data source rejected establishment of connection。原因：获取连接后没有在finally块中关闭，连接池所有连接被请求占用，后续请求拿不到连接，最终Tomcat失去响应。解决：所有DAO方法的关闭操作写在finally块中，Connection从连接池获取后必须关闭（关闭意味着归还连接池而不是真正断开），Statement和ResultSet也必须依次关闭；更稳妥的做法是用try-with-resources语法，Java 7以上支持，能自动关闭资源。排查时执行SHOW PROCESSLIST看数据库连接数是否满，你就知道连接是否泄漏了。

6. 验收与答辩：从功能测试到现场演示的完整准备

车票预订信息系统这类课设/毕设项目，验收时看的不是代码量，而是三项：功能是否正确闭环、数据库事务是否可靠、答辩能否说清关键设计决策。我先说功能验收怎么做。按用户操作路径准备一张测试用例表，覆盖“注册→登录→查询车次→提交订单→查看订单→退票→后台车次管理”这条主线流程，每个步骤都记录预期结果、实际结果和是否通过。测试数据的准备也有讲究：数据库中至少造20条车次记录，分布在5条不同路线，日期覆盖今天、明天和一周后，这样才能演示查询条件过滤的效果。另外要专门构造边界数据——车次余票剩1张时，两个账户同时下单，看系统是否只允许成功一单。

答辩演示的顺序我通常建议按“三段式”来组织：第一阶段展示业务流程闭环，从登录开始一路操作到退票，让评委完整看到系统的真实可用性；第二阶段展示后台管理能力，进入管理端，修改一个车次的价格，再到前台刷新页面验证价格已更新——这一步是为了证明前后台数据是联动的，系统不是写死的静态页面；第三阶段展示一个亮点功能或难点突破，这里你把t_seat_stock表结合并发事务控制的方案讲出来，比泛泛说“使用SSH框架开发”更有说服力。

下面是一张可直接使用的自我验收清单，每一项都对应一个答辩可能追问的点：

最后说一个我在答辩现场看到过很多次的问题：不少同学演示时先打开数据库，说“大家看这个表里有数据”，然后打开页面操作一遍，然后就没有了。整个答辩变成了“操作演示”，而不是“设计讲解”。评委想听的是“你遇到的最难的问题是什么、你怎么解决的”。你完全可以主动讲一个开发过程中真实踩到的坑，比如上面提到的并发余票超卖：先描述现象、再定位原因、最后给出事务加行锁的解决方案。这比你能把流程背得滚瓜烂熟更能证明系统的可靠性。

从那以后，我每次做这类信息管理系统，都会强制走一遍“备份数据库→恢复备份→跑一遍完整测试用例→检查关键表数据一致性”的流程，每次都能发现一两个自己以为写对了但实际上有漏的业务分支。希望这套从需求分析到验收答辩的方案能帮到你。如果你正在做车票预订这个题目，直接按这个结构和实现方式推进就可以了，设计和编码两个环节能省下大量试错成本。

本文还有配套的精品资源，点击获取