企业官网建设流程全解析

毕业设计选这个题目，十有八九是在校生，身边没有能随时请教的资深开发，网上资料又良莠不齐，很容易被各种互相矛盾的帖子带到沟里。这篇文章我会按照当时带某位学弟完成这个项目的实际节奏来写，不堆理论，不讲空话，从需求拆解到数据库设计，从后端接口到前端页面，最后再补上联调部署和答辩会被问到的坑，尽量做到你拿到手就能照着做。

这个系统的核心业务并不复杂：用户注册登录、按出发地和目的地查询车次、看到余票后下单、模拟支付、出票、退票，再加一个后台管理页面做车次和站点维护。但麻雀虽小五脏俱全，它覆盖了一个完整商业项目的主链路：权限认证、核心业务逻辑、事务与并发控制、前后端分离联调。不管你是保研复试需要作品集，还是找工作想写进简历，这个项目的“含金量”都足够撑场子。

先说清楚这个项目适合谁。如果你已经能独立写出一个简单的Web项目，比如用Servlet或者JSP做过登录注册，想在毕业设计里尝试前后端分离和主流框架，这个题目就是很合适的过渡。如果你目前连Maven依赖报错都还没搞定，建议先把SpringBoot的基础示例跑通再来碰这个项目，否则很容易卡在环境上把信心消磨光。

1. 项目思路与需求拆解

火车站票务系统的业务逻辑比表面看起来要复杂一点，如果直接把12306的功能全抄一遍，比如涉及多趟车次、多个日期、复杂的调图逻辑，那一个学期都不够用。毕设的核心不是功能越多越好，而是把主链路做深、做扎实。

1.1 业务模块划分

我习惯在做任何代码之前，先花两天时间把需求文档画出来。别嫌这一步浪费时间，后面你会发现它帮你省下至少一周的返工时间。这个系统按照角色划分，就两大类：普通用户和管理员。

用户端的核心流程是：注册账号 → 浏览车次查询页面 → 输入出发城市、目的城市和乘车日期 → 查看符合条件的车次列表 → 点击某车次查看详细经停站和余票 → 下单并填写乘车人信息 → 模拟支付 → 查看订单状态 → 需要时退票。

管理员端的核心流程是：登录管理后台 → 维护站点信息、维护车次基本信息 → 管理车次经停站点的顺序和时间 → 处理用户的退票申请（其实做成自动退票更省事）。

需求文档里有一个特别容易被忽视的点：车次查询是在“城市”级别还是“车站”级别。12306是按城市出结果，城市下挂多个车站。咱们做毕设可以直接按车站做，但界面文案仍然写“出发地”，后台站点表里存的是真实站名。你别小看这个设计，答辩时老师一定会问“为什么你的查询不加城市和车站的关联关系”，你直接回答“本站系统定位为单一车站出发，所以天然省去城市分组，后续如需扩展可以增加中间表”，这个思路就是加分点。

1.2 技术栈选型逻辑

SpringBoot + Vue + MySQL这套组合，在2024年的今天依然是毕业设计的主流，原因很简单——它兼顾了开发效率、生态成熟度、参考资料丰富度和答辩表现力。

先说SpringBoot。它内置了Tomcat，一个main方法就能启动服务，不需要像之前的SSH架构那样配置一堆XML。它把Spring的依赖注入简化到了注解级别，学习曲线平滑。另外一个很关键的点：SpringBoot的版本迭代非常稳定，你拿着SpringBoot 2.7写的代码，和网上主流教程对得上，不会出现因为版本差异导致陌生API的情况。

再说Vue。这里要选Vue 2还是Vue 3，我推荐直接Vue 3 + Vite + Element Plus。为什么？因为Vue 3组合式API（Composition API）对后端背景的开发者更友好，代码组织方式更接近Java的类划分。而且现在学校答辩环境里，老师大概率已经见过大量的Vue 2项目，你换Vue 3的写法反而能体现你在跟随技术趋势。Vite启动速度比Webpack快了一整个量级，改一行代码刷新页面几乎是秒开，开发体验提升很大。

MySQL没什么好争的，结构化数据存储的首选。它的InnoDB引擎支持事务和行级锁，这对于订单创建和余票扣减的一致性保障极其重要。NoSQL在那些并发量极高的场景才有意义，毕设项目用MySQL体现不出性能瓶颈，反而能把事务、索引这些数据库基本功展示清楚。

1.3 功能清单规划

我按实际开发优先级把功能排了个序。第一梯队是必须要做、答辩时核心演示的：用户注册登录、车次查询、下单支付、余票扣减、退票。第二梯队是完善用户体验、体现工程化能力的：JWT权限校验、分页查询、Swagger接口文档、前端路由守卫。第三梯队是能显著加分的：使用Redis缓存高频查询结果、数据库索引优化、项目部署到云服务器。

这三个梯队不用一次性全做出来，先完成核心功能，形成一个可以演示的闭环，再逐步往里面加亮点。很多学生犯的错误是一上来就研究Redis怎么缓存、Docker怎么部署，结果核心的下单流程还没跑通，最后时间不够草草交付。

2. 数据库设计与核心表结构

数据库设计是这类管理系统的灵魂，它直接决定了你写代码时是流畅还是痛苦。我在设计表结构时遵循了一个原则：每个表都只储存一个维度的核心信息，关联关系通过外键逻辑连接，不搞冗余字段。

2.1 表关系总览

整个系统需要六张核心表：用户表（user）、站点表（station）、车次表（train）、车次经停表（train_station）、订单表（orders）、乘车人表（passenger）。如果业务上需要记录支付流水，可以加一张订单流水表，但毕设阶段把支付流程写在订单状态变更里也能讲清楚。

这几张表中，user和passenger是一对多，一个用户可以有多个常用乘车人。train和station是多对多，中间表就是train_station，它既记录某个车次经过哪些车站，也记录每站的到发时间和顺序。orders保存下单时的快照信息，包括车次、出发站、到达站、乘车日期、席别、价格、乘车人信息，这样即使车次后续调整，已经生成的订单数据也能保持完整。

2.2 车次与车站设计的细节考量

列车与车站的关系是这个系统里最容易做错的地方。一个车次从北京西始发，经停郑州东、西安北，最终到达成都东，那么它就关联了四个车站。车次基本信息表（train）里只存始发站和终到站的ID，经停站的完整信息放到train_station表里。

CREATE TABLE train_station ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', train_id BIGINT NOT NULL COMMENT '车次ID', station_id BIGINT NOT NULL COMMENT '车站ID', station_order INT NOT NULL COMMENT '经停顺序，1为始发站', arrive_time TIME NULL COMMENT '到达时间', leave_time TIME NOT NULL COMMENT '发车时间', INDEX idx_train_id (train_id) ) COMMENT '车次经停站表';

有了这张表，查询“只买中间某一段区间”的余票时，逻辑就清晰了：先根据出发站和到达站找到对应的车次，再比较这两个站的station_order大小，确认方向正确，最后判断乘车日期和余票。

出发站和到达站的经停顺序判断特别容易忽略。卖票系统不能允许用户买到“从成都到北京段”然后出现始发站顺序小于终到站的倒挂情况。我在代码里加了一个校验，比较两个站在同一车次下的station_order，出发站的order必须小于到达站的order，否则提示“请检查您的出行方向”。

2.3 车次表设计与余票字段的取舍

车次表的设计有两种方案。方案A是每个车次一条记录，直接存各种席别的余票数量；方案B是拆分出一个车次排班表（train_schedule），每天一班的数据单独一行。

方案B更贴近真实业务，因为同一车次每天都会发车，余票按日期各自独立。但它的代价是代码复杂度翻倍，每次查询都要join日期维度。对毕业设计而言，做方案B容易把自己绕晕。我当时用的是方案A的变体：车次表存基本信息，余票数量按乘车日期拆开，用一张独立表记录“某车次 某日期 某席别 剩余多少张”。这个折中既保证了逻辑清晰，又能在答辩时体现你考虑到了“每天不同余票”的真实场景。

CREATE TABLE train_seat_stock ( id BIGINT PRIMARY KEY AUTO_INCREMENT, train_id BIGINT NOT NULL, ride_date DATE NOT NULL, seat_type TINYINT NOT NULL COMMENT '1-商务座 2-一等座 3-二等座', remaining INT NOT NULL, version INT DEFAULT 0 COMMENT '乐观锁版本号', UNIQUE KEY uk_train_date_seat (train_id, ride_date, seat_type) );

这张表同时承担了一个重要职责——并发控制。当成千上万个请求同时抢同一趟车的最后一张票时，数据库必须保证不会出现超卖。这里用的是带版本号的乐观锁。UPDATE语句执行后，受影响行数为0说明版本冲突或余票不足，此时直接返回“余票不足”的提示。

2.4 订单状态机设计

订单表的状态字段是整个业务闭环的核心。我设计了四个状态：待支付（0）、已支付（1）、已出票（2）、已退票（3），外加一个超时自动取消（4）。

一开始我担心状态太多会不会乱了，后来发现在订单查询页面里，状态字段是直接决定按钮显隐的唯一依据。待支付时显示“去支付”和“取消订单”，已支付时显示“申请退票”，已退票时全部置灰只读。一个清晰的状态机让前端代码少写一半的if-else。

这里有一个细节：支付成功后，我没有立刻把状态改为已出票，而是先改为已支付，再通过一个异步逻辑或者定时任务更改为已出票。真实系统里这两步之间涉及票务系统的出票回调，毕设里可以直接在支付成功后同步改为已出票，但状态编码仍然保留两个值，不用改代码就能在答辩时说明白“支付和出票是两个独立步骤，解耦后便于后续接真正的支付回调接口”。

3. 后端核心模块实现

后端代码的组织方式对后期维护影响很大。网上很多教程喜欢把业务逻辑直接写在Controller里，几行代码倒是能跑，但项目一复杂就乱。这里采用经典的四层结构：Controller → Service → Mapper → Entity，外加通用返回类和JWT拦截器。

3.1 项目分层与Maven依赖

用Spring Initializr生成项目的时候，需要勾选Web、MyBatis Framework、MySQL Driver、Lombok、Validation这几个依赖。Lombok能省掉一堆getter/setter，但要注意项目组成员都必须装Lombok插件，否则编译期报错找不到方法。

项目包名可以命名为com.xxx.train，结构如下：

com.xxx.train ├── controller # 接口层 ├── service # 业务逻辑层 ├── mapper # 数据访问层 ├── entity # 数据库实体 ├── dto # 前端交互对象 ├── common # 通用返回类、业务异常、工具类 ├── config # 拦截器、全局配置 └── TrainApplication.java

实体类命名一定不要跟数据库表名完全一致然后强行驼峰，MyBatis开启驼峰映射后，user_id可以直接对应userId，省去大量ResultMap配置。

3.2 注册登录与JWT鉴权

用户密码安全这块，我见过太多毕设直接用明文存储，答辩老师问你密码安全性的时候就会很尴尬。这里使用BCrypt加盐哈希加密，Spring Security的这个工具类可以直接引进来单独使用，不必引入全家桶。

用户表设计时预留了role字段，0代表普通用户，1代表管理员。注册时默认都是0，管理员账号手动在数据库里插入。

登录成功后颁发JWT令牌，令牌里带上用户ID和角色，后续接口通过拦截器解析。JWT的过期时间设置为24小时，前端每次请求时把令牌放在Authorization请求头中。

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); try { Claims claims = Jwts.parser().setSigningKey(SECRET_KEY).parseClaimsJws(token).getBody(); request.setAttribute("userId", claims.get("userId")); return true; } catch (Exception e) { // 令牌无效 } } response.setStatus(401); return false; } }

这个拦截器注册到WebMvcConfigurer里，并配置放行白名单：注册接口、登录接口、车次查询接口。管理员的接口还需要二次校验角色，可以在Controller层加一个注解判断，也可以在拦截器里根据URL路径判断。

3.3 车次查询与余票扣减

车次查询接口是逻辑最复杂的一个。前端传递的参数包括出发站ID、到达站ID、乘车日期。SQL层面要联合train、train_station、seat_remaining三张表。我建了一个专门的查询DTO来接收上层的入参，然后用一个自定义SQL一次性查出来。

SELECT DISTINCT t.id, t.train_number, t.train_type, t.start_time, t.end_time, t.duration, ts_from.leave_time AS from_leave_time, ts_to.arrive_time AS to_arrive_time FROM train t INNER JOIN train_station ts_from ON t.id = ts_from.train_id INNER JOIN train_station ts_to ON t.id = ts_to.train_id WHERE ts_from.station_id = #{fromStationId} AND ts_to.station_id = #{toStationId} AND ts_from.station_order < ts_to.station_order

为什么要用两个join而不是在同一张经停表里查两遍？因为一个车次既要在出发站表里匹配，又要在到达站表里匹配，如果不分开别名，数据库会认为必须同一行同时满足两个条件，那就什么都查不出来了。这个坑当年卡了我一个下午。

余票扣减是整个系统最核心的并发安全点。我用的是乐观锁方式：

UPDATE train_seat_stock SET remaining = remaining - 1, version = version + 1 WHERE train_id = #{trainId} AND ride_date = #{rideDate} AND seat_type = #{seatType} AND remaining > 0 AND version = #{version}

执行这条update返回的影响行数为1，说明扣减成功并占用了名额；返回0说明余票不足或版本冲突，此时抛异常并回滚事务。有一点必须注意：这个UPDATE操作必须在事务里，并且下单支付整个流程要保证原子性。

3.4 下单支付退票主流程

下单接口接收的参数包括车次ID、乘车日期、席别、乘车人信息。Service层逻辑依次做了五件事：查询车次是否存在且日期距今三天内（避免买过期票）、校验出发站和到达站经停顺序、查询余票是否充足、扣减余票、插入订单记录。

支付接口是一个模拟操作，前端点击支付后，后端立即将订单状态从0改为1，再改为2（已出票）。实际项目里这里会调第三方支付接口并等待异步通知，毕设里做一个同步跳转就能演示完整链路。

退票接口的逻辑必须包含“恢复余票”的操作。事务里先查询订单状态是否为可退状态，如果是，将订单状态改为3，同时把对应的余票数量加回去。注意这里不能用UPDATE无条件加1，而是用“UPDATE ... SET remaining = remaining + 1 WHERE ...”的原子自增。

有一个很多人容易忽略的问题：支付和出票之间如果中断，用户的订单处于已支付未出票状态，但余票已经扣了。毕设阶段可以不考虑这个细节，但是答辩老师如果问到，你可以说引入一个订单补偿机制，定时扫描超过五分钟仍未出票的订单，自动恢复余票并退款。

4. 前端页面与交互实现

前端部分采用Vue 3 + Vite + Element Plus + Axios的组合。整个前端工程并不大，核心页面控制在六个左右：首页车次查询、车次列表、下单弹窗、订单列表、登录注册、后台管理。

4.1 前端工程结构

Vite创建项目后，在src下建views、components、router、store、api这几个目录。api目录下的每个文件对应一个后端的Controller模块，比如train.js、order.js、auth.js，里面统一导出axios封装好的方法。

Axios封装是前端最容易碰壁的地方。如果不做统一封装，每个页面的请求都自己处理loading、错误提示、状态码，代码会重复到爆炸。封装的核心是在响应拦截器里统一处理HTTP状态码和业务状态码。

service.interceptors.response.use( (response) => { const res = response.data if (res.code === 200) { return res } if (res.code === 401) { // 跳转登录页 } ElMessage.error(res.message) return Promise.reject(new Error(res.message)) }, (error) => { ElMessage.error('网络异常，请稍后重试') return Promise.reject(error) } )

这样所有业务页面只需要关注数据本身，不需要在每处都处理异常分支。

4.2 核心页面拆解

首页查询页面是门面，设计时用了一个大表单，三个输入项：出发地、目的地、出发日期。出发地和目的地用的是两个级联选择器，数据来源是后端站点接口。日期选择器限制只能选三天内的日期，这里跟前端接口参数校验要排队对牢。

车次列表页用一个Table表格展示，每行的操作列是“订票”按钮，点击后弹出下单对话框。对话框内展示车次号、出发到达时间、历时以及各席别价格和下单选座。乘车人信息需要从常用乘车人里选择，也可以在对话框内直接填写姓名和身份证号。

订单列表页用Tabs切换到三个状态：待支付、已完成、已退票。每个Tab里的表格列略有不同，但核心字段一致：车次号、区间、乘车日期、席别、金额、状态。最关键的是操作按钮要跟状态联动，待支付显示“去支付”和“取消”，已支付显示“申请退票”。

4.3 路由守卫与权限控制

前端路由需要做登录限制，未登录用户不能访问订单页面。Vue Router的路由守卫里，每次跳转前读取localStorage中的token，如果存在且未过期就放行，否则跳转到登录页面。

管理端的页面要单独分离权限。我在router配置里给管理页面加了meta.requiresAdmin字段，守卫里再判断token解析出的角色是否为1，不是就弹窗提示“无权限访问”。

这里有一个坑：管理员后台不应该和普通用户页面混在一个布局里。我用Vue Router的嵌套路由分别挂载了两个Layout，前端工程结构更清晰。

4.4 跨域问题处理

前后端分离开发最大的障碍就是跨域。SpringBoot的CORS配置类里，用addMapping("/**")允许所有路径跨域，allowCredentials设置为true，allowedOriginPatterns设置为*。注意如果使用allowedOrigins("*")加allowCredentials(true)会有浏览器兼容问题，必须用OriginPatterns。

开发阶段用Vite的proxy代理转发也可以，把/api开头的请求转发到localhost:8080，这时候后端就不需要配置CORS了。两种方案都可以，我偏向在SpringBoot配置CORS，这样部署到服务器后前端Nginx反代也不需要额外处理，配置少一步。

5. 联调部署与性能优化

项目开发完要先把自己电脑上的环境理顺。后端直接本地起SpringBoot，前端npm run dev，通过Vite的代理解决跨域，这样就能完成全链路人工测试：注册、查询、下单、支付、退票。测试通过后再考虑部署。

5.1 数据库初始化与接口测试

项目启动前需要执行建库建表脚本。数据库字符集一定要设置成utf8mb4，否则乘车人填个中文名字可能正常，但一旦涉及生僻字或者表情符号就乱码。连接串也要加上characterEncoding=utf8的参数。

接口测试建议使用接口调试工具，把所有接口的系统性测试做一遍。这里提一个提高测试效率的技巧：在上线前，把每个接口的典型成功和失败用例整理成表格，照着表格逐项验证，就不会出现答辩现场演示时某个按钮突然报错的翻车。

5.2 打包部署方案

后端打包很简单，直接在IDEA的Maven面板执行clean package，得到可执行jar包后放服务器上执行nohup java -jar train-system.jar。前端打包用npm run build，产出纯静态文件，放到Nginx的html目录里。

后端配置里有几项是部署前必须修改的：数据库连接地址跟随环境变化、JWT密钥使用强随机字符串不要硬编码、MySQL驱动的时区参数serverTimezone必须设置为Asia/Shanghai，否则时间字段会差八个小时。

5.3 性能优化加分项

答辩时如果能说出几处有依据的性能优化，分不会低。

首先给高频查询添加索引。车次查询接口涉及train_station表的station_id关联，所以无论如何都要在train_station.station_id上建普通索引。否则数据量稍微涨到几万条，联表查询就会变成全表扫描。

其次是在车次查询接口上做Redis缓存。出发站、到达站、乘车日期三个参数在短时间内会有大量用户重复查询，把相同条件下的查询结果缓存十五秒，能极大减小数据库压力。这里用缓存时要考虑一个细节：余票数据的一致性不能依赖缓存，因为下单时已经写了基于数据库扣减的逻辑，缓存只是展示层的旧数据，实际购买时仍然准确。答辩时把这个设计说明白，就能体现你对缓存一致性的理解。

另外后端加了参数校验框架，所有的入参在进入业务前先用注解校验一遍。身份证号、手机号正则表达式都有现成的validation注解，能少写很多if-else判断。

6. 答辩高频问题与避坑指南

这部分是压轴重点。我把过去带过的毕设里最容易翻车的点整理成清单，你按这个清单查漏补缺，至少在技术维度上站得住脚。

6.1 开发过程中的常见技术坑

分页查询的坑。MyBatis的PageHelper分页插件用法是startPage之后紧跟第一个查询，然后立刻获取PageInfo，中间不能插入别的SQL操作。有些同学在业务逻辑里先调了其他查询，再分页查车次，结果分页插件会把两条查询都拦截，导致返回数据数量不对。

日期传参的坑。前端传给后端的乘车日期是字符串，后端如果直接用LocalDate接收，必须使用@DateTimeFormat(pattern = "yyyy-MM-dd")注解，否则框架直接报格式转换错误。响应时LocalDateTime默认序列化成数组，需要加@JsonFormat注解才能变成"2024-10-01 12:30:45"的格式。

事务失效的坑。Spring的@Transactional默认只对RuntimeException回滚，如果业务方法里catch了异常但是没有往外抛，事务是不会回滚的。下单流程里扣减余票和插入订单如果分开提交，就会出现扣了余票但没有订单的脏数据。务必保证这两个操作在同一个事务方法里，异常统一抛出到统一异常处理器。

乐观锁的坑。乐观锁适合竞争不激烈的场景，如果请求并发量极高，版本冲突会导致大量请求失败。毕设项目没有几万人同时抢票的压力，用乐观锁是一套很合理的折中方案。答辩时如果老师质疑这一点，你可以回答“这里是为并发预留的可用空间，真实环境中还可以引入Redis分布式锁或者改造为悲观锁方案，但会带来额外复杂度，和当前场景不匹配”。

6.2 答辩高频问题整理

为什么选择SpringBoot加Vue这套技术栈？从开发效率和生态角度回答：SpringBoot解决了传统SSM框架的大量配置问题，开箱即用；Vue组件化开发让页面逻辑更清晰；MySQL事务处理保证了交易数据的一致性。

系统有哪些安全隐患？至少说出四条：密码使用了BCrypt加盐处理，JWT令牌设置有效期，接口拦截器校验权限防止越权，SQL全部使用预编译防止注入。

如果并发量上来，系统的瓶颈在哪里？怎么优化？数据库压力是首要瓶颈，可通过增加索引、Redis缓存、请求限流、水平扩容和读写分离来解决。

你的项目有哪些创新点？不建议生造功能，实打实说自己做了哪些性能优化和工程化改进就好：统一异常处理、接口文档自动化、JWT无状态认证、核心链路事务加乐观锁防超卖。

6.3 项目完整性自查清单

最后列一个自查清单，每一项都要确认无误再提交。

系统功能上，用户从注册到退票的完整闭环必须亲手跑通至少五遍，不要只演示一条幸福路径，还要故意输入错误参数、重复下单、退票后再购票，确认异常分支不会导致页面崩溃。数据库层面，重新执行初始化脚本，插入几条测试数据，确认各表数据能正常关联查询，没有外键缺失。安全层面，确认未登录用户无法访问订单接口，普通用户无法访问管理端接口，提交订单时车次余票为0时报错提示。

前端展示层面，把所有页面的空数据状态检查一遍，车次查询不到结果时要有友好提示，接口报错时弹窗信息要明确，不能出现白屏。部署层面，生产环境的数据库密码不能用默认弱密码，JWT密钥不能用文档示例里的字符串，管理端默认账户登录后要能正常修改密码。

这些都是“看起来很小、崩起来很惨”的细节。

7. 结语与个人经验总结

我自己带过的毕业设计项目里，这个选题算是完成度比较好控制的一类。核心链路不会过于复杂导致做不完，技术点又足以覆盖一个商业系统的主要环节。如果你时间充裕，还可以把前端页面打磨得更精致一些，比如增加一个车次时间轴的可视化展示，或者把表格改成卡片式布局，这些视觉细节在答辩演示的时候能非常直观地展示你的主动性。

要特别提醒的一点是：不要试图在毕业设计里“炫技”。有些同学觉得用了Redis、消息队列、微服务这些高级技术就厉害，但毕设论文和答辩考察的核心是“你是否掌握了软件工程的基本功”。把SpringBoot的分层架构说清楚，把数据库设计和事务控制讲明白，把前端交互和接口对接过程能完整复述出来，这远比堆砌一堆你并不熟练的技术名词更有说服力。技术是为业务服务的，这一点在任何一个真实项目里都比会写几个复杂算法重要得多。

如果你在做这个项目过程中遇到了具体的报错或者逻辑卡点，欢迎随时交流。编程这件事，很多时候就是一个卡点通了后面全顺，希望你能顺利把项目跑通，答辩拿个漂亮成绩。