企业官网建设流程全解析

每到毕业设计选题季，技术群里总有一群人在反复横跳：做管理系统怕太水，做商城感觉烂大街，做算法类又担心撑不起前后端。如果你正在找一个既能覆盖Java后端、前端页面和数据库设计，又不会把自己拖进地狱难度的方向，SpringBoot+Vue+MySQL的旅游网站管理平台是值得认真考虑的一个选择。这个平台业务上围绕景点、旅游线路、团期和订单来转，技术上把前后端分离开发、权限控制、文件上传、分页查询、事务和部署整条链路都串了起来，无论应付毕设答辩，还是作为一份作品写进简历，都有东西可讲。这篇文章我不想写成“复制源码走一遍”的流水账，而是想以一个实际带过这个题目的开发者视角，把从选型到落地的关键决策、容易踩的坑、以及答辩时最容易被追问的细节都拆开聊一遍。

1. 选型与定位：这套技术组合的“正好够用”逻辑

1.1 SpringBoot+MySQL：把精力放在业务而不是配置上

如果回到用传统SSH或者原生Spring MVC写项目的年代，光是XML配置、数据源管理、事务配置就要耗掉大量时间。SpringBoot通过自动配置把这些变成了约定俗成的东西，application.yml里写上数据库连接、端口和少量参数就能把项目跑起来。对毕设这种周期有限的场景，这是最重要的时间节省。

更重要的是，SpringBoot在整个就业市场里的认知度非常高。答辩时无论老师问Spring的IOC、AOP，还是问自动配置原理，你都有现成的知识储备可以接住。如果你在这里选了一个特别小众的框架，反而要花额外精力向老师解释“它是什么、为什么用它”，解释成本一高，答辩节奏就会被打乱。

有人会问，要不要直接上SpringCloud微服务？我的建议是不要。微服务的核心是服务拆分、注册中心、配置中心、网关、降级限流这一堆东西，而一个旅游管理平台的业务量级根本撑不起这些复杂度。硬拆出来的微服务，在答辩时一旦被追问“服务拆分的边界是什么”“注册中心挂了怎么办”，很容易把自己绕进去。选型不是越高级越好，而是越匹配越好。

1.2 Vue在前后端分离中的位置

前端选Vue而不选其他框架，核心原因在于生态完整、上手曲线温和。配合Element UI或Element Plus，管理后台能在很短时间里搭出一套足够专业的界面，表格、表单、弹窗、分页这些后台管理的高频组件都有现成方案。用户端的旅游展示页面也可以用组件化方式拆成导航栏、线路卡片、景点详情、订单步骤条等模块，结构一目了然。

如果学校课程还在教Vue2，那就跟着学校版本走，因为课设评分一般会参考课堂内容；如果完全是自学选题，直接上Vue3加组合式API。组合式API的setup语法让同一个功能的响应式数据、计算属性和方法集中在一块，比Vue2的分散写法更容易读懂，也更容易展示“我理解前端工程化”。

1.3 为什么没有引入Redis、MQ这类中间件

不是不能用，而是分清主次。旅游平台的并发压力主要集中在下单和余位扣减这两个动作，对毕业设计来说，MySQL配合条件更新和事务完全能扛住。引入Redis做缓存、引入MQ做异步处理确实能让简历更好看，但代价是多两套运维、多两套排错负担，还要把“为什么必须用它们”想清楚。

面试官最反感的一种情况是：简历上写了Redis，问缓存穿透怎么解决，回答是“我复制了别人的配置”。如果时间不够，宁可不加，也不要让项目处于一种“依赖了很多中间件但讲不清非用不可”的状态。先把这个旅游平台做到逻辑闭环，再去考虑加分项。

选型定了以后，接下来的关键问题就是：平台的业务模块到底怎么拆才合理。

2. 业务模块拆解：用户端和管理端的边界划分

2.1 核心实体关系：景点、线路、团期、订单

旅游平台最核心的实体是四张表：景点、线路、团期、订单，外加用户表。景点是基础资源，一条旅游线路通常会包含多个景点，一个景点也可能出现在多条线路里，所以景点和线路是多对多关系，一般需要一张线路-景点关联表来表达。线路本身是“商品模板”，真正可售卖的是团期，也就是某条线路在某一天出发，还剩下多少名额。订单落在整个关系链的最末端，由用户针对某个团期提交。

这种从“资源”到“商品”到“库存”再到“交易”的分层模型很典型。很多初学者会犯的错，是把出发日期、余位这些字段直接塞在线路表里。看起来省事，可一旦线路包含多个出发计划，整张表的数据就乱套了。把团期单独拆成一张表，是这套设计里第一个值得在答辩时主动讲清楚的决策。

2.2 用户端的操作闭环

用户端面向普通游客，功能可以概括为“逛、查、订、看”。逛是指浏览首页轮播图、景点列表和线路列表；查是按名称搜索线路、查看线路详情和团期计划；订是选择出发日期和出行人数，填写联系人信息后提交订单；看是在个人中心查看订单状态，待支付订单可以取消或模拟支付。

整个闭环不需要做得很复杂，但必须完整。很多课设做到浏览就停了，订单只是一个静态页面，那答辩时会非常吃亏，因为评委一定会追问“用户提交之后，后台到底发生了什么”。哪怕支付只是模拟状态，也要把“下单→扣余位→生成订单→后台可见→更新状态”这条链路跑通。

2.3 管理端的权限与功能边界

管理端做四块核心就够了：内容管理负责景点、线路和轮播图的增删改查；库存管理负责团期和余位的设置；订单管理负责查看订单、确认订单、取消订单；用户管理负责用户列表和账号状态。想进一步提升展示效果，可以加一个统计面板，显示订单总数、用户总数、待处理订单数，这些数据直接查表count就能出来，不需要额外依赖任何中间件。

权限模型用两层就够：普通用户只能访问用户端接口，管理员可以访问管理端接口。不需要把权限设计成多角色的RBAC模型，因为当前场景根本没有那么多角色和权限点。硬塞一个角色选择器进去，反而会让自己陷入“设计了这个角色却不知道给什么权限”的尴尬。

3. 数据库设计里最容易翻车的三个决策

3.1 订单状态机的流转：不要散落一堆if-else

订单的status字段不要用int加注释去记，更不要在每个接口里到处写if判断。推荐的做法是用一个枚举集中管理状态和流转规则。旅游平台的订单至少要包含以下状态：待支付、已支付待出行、已完成、已取消。待支付只能流转到已支付或者已取消；已支付只能流转到已完成；已完成和已取消是终态，不能再改。

状态流转逻辑建议收口到枚举的nextStatus方法里，Service层统一调用。这样在答辩时，你可以很明确地说“状态是单向流转的，每一种转换都是被枚举约束的”，而不是“代码里几个if判断了一下”。如果考虑了退款，可以把已支付待出行流转到已取消的同时做一次模拟退款，但要注意这是简化方案，真实业务还需要退款流水表。

3.2 价格精度与余位并发控制

价格字段必须用BigDecimal，不要用double。double在表示小数时存在精度误差，1块钱的0.1折价格算出来的结果可能是一长串奇怪的小数，钱一旦出现精度问题就是硬伤。MySQL侧对应字段使用decimal(10,2)，Java侧使用BigDecimal接收，前端展示时再处理小数位。

余位控制是另一个高频追问点。多人同时下单，怎么避免超卖？最稳妥的写法是条件更新，把扣减动作约束在一条SQL里完成。

UPDATE t_line_schedule SET booked_seats = booked_seats + 1 WHERE id = #{scheduleId} AND booked_seats < total_seats

受影响行数为1说明扣减成功，继续创建订单；受影响行数为0说明余位已经满了，抛出“该团期余位不足”的提示。这种写法比“先查余位，判断后再更新”更安全，因为查询和更新之间的时间窗口就是并发问题的温床。配合@Transactional事务，这条SQL就能作为答辩中“防超卖”的核心论据。

3.3 时间、图片、字符集三个隐藏坑

时间字段优先使用LocalDateTime，不要再使用java.util.Date。MySQL侧存datetime，接入层通过Jackson配置统一序列化成“yyyy-MM-dd HH:mm:ss”，前端展示时才不会出现时间偏移8小时的问题。如果坚持用Date，务必保证数据库连接的serverTimezone和运行环境的时区一致，否则排查起来很头疼。我实际遇到过客户端显示时间比正常时间多了8小时，翻到最后才发现是连接参数没有指定serverTimezone。

图片字段存的是路径，不是图片本身。上传的图片重命名后保存在服务器指定目录，数据库只存相对路径或访问URL，前端通过后端映射或Nginx直接访问。千万不要把图片转成Base64再塞进数据库，那种做法会让表变得又大又慢，后期导数据都是噩梦。字符集方面，建库时就指定utf8mb4，否则部署到Linux后中文变成问号的问题会反复出现。

4. 后端编码的关键骨架：登录认证、统一返回体、条件分页和下单事务

4.1 JWT登录与传统Session方案的取舍

旅游平台采用JWT做无状态认证是性价比很高的选择。用户登录成功后，后端签发一个带过期时间的token，前端保存起来，后续请求放到Authorization请求头里，后端用拦截器解析并确认身份。相比Session方案，JWT不依赖服务端的内存和Session存储，以后想把接口开放给小程序端，同一套登录认证逻辑可以直接复用，不需要改后端。

实现时要注意三个细节。第一，拦截器不仅要验证token是否有效，还要做角色判断，管理端接口必须校验当前用户是管理员；第二，公开接口比如首页、景点列表、登录注册要放进白名单，否则用户没登录连网站首页都打不开；第三，处理跨域时要对OPTIONS预检请求放行，这个后面会单独讲。签名算法用HS256就够了，密钥放在配置文件里，不要为了追求“高级”而引入复杂的密钥管理，给自己增加没必要的工作量。

4.2 统一返回体、全局异常与分页插件

后端接口不要散装返回各种Map，定义一个Result 容器，包含code、message、data三个字段，业务成功返回200和真实数据，业务失败抛异常，由全局异常处理器统一转换成错误信息。前端axios拦截器只需要处理这一种结构，代码会清爽很多。业务异常建议单独封装一个BusinessException，在Service层需要中断逻辑时直接throw，由@RestControllerAdvice捕获后返回给前端。

分页查询用MyBatis-Plus的分页插件，但有一个非常容易漏掉的配置：必须在配置类里注册PaginationInnerInterceptor。很多新手导入了MyBatis-Plus却不注册分页插件，分页查询返回的total永远是0，Page对象里只有当前页数据，前端分页组件就失去了总页数。多条件搜索建议用LambdaQueryWrapper，配合StringUtils判断条件是否加入，避免写一长串if-else。下面这段代码是线路列表的典型写法：

LambdaQueryWrapper<TravelLine> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.isNotBlank(keyword), TravelLine::getName, keyword) .ge(minPrice != null, TravelLine::getPrice, minPrice) .le(maxPrice != null, TravelLine::getPrice, maxPrice) .eq(StringUtils.isNotBlank(city), TravelLine::getDepartureCity, city) .orderByDesc(TravelLine::getCreateTime); Page<TravelLine> page = lineService.page(new Page<>(pageNum, pageSize), wrapper);

Controller只负责接收参数，查询条件的组装和分页逻辑下沉到Service层，结构清晰，答辩时也更好解释。

4.3 下单事务的执行顺序与订单快照

下单接口是后端业务的核心，逻辑顺序很关键。第一步根据前端传来的团期ID查出团期数据，判断出发日期是否在当前日期之后；第二步根据出行人数计算订单金额；第三步执行带条件的余位更新，校验受影响行数；第四步插入订单记录，订单里冗余保存线路名称、出发日期、单价、总价等信息；整个过程加上@Transactional，任何一步异常都回滚余位扣减。

订单快照这个点很多人忽略。如果订单表只存线路ID，管理端后续修改了线路价格，历史订单的展示也会跟着变化，这显然不符合业务逻辑。订单必须保留下单那一刻的关键信息，这是关系型数据库设计里很重要的冗余思想，值得在答辩时主动讲。图片上传接口也用MultipartFile接收文件，校验文件类型和大小上限，重命名为UUID加后缀，存到指定目录后返回访问路径，数据库只保存这个访问路径。

5. 前端Vue工程化的落地细节：路由守卫、请求封装与列表页写法

5.1 目录划分与路由规划

前端项目按功能把目录分成用户端和管理端两块。src/views下面至少要有首页、景点、线路、订单、个人中心这些页面目录，管理端则是admin/scenic、admin/line、admin/order、admin/user等。路由表全部静态声明，管理端路由统一挂在AdminLayout下，通过路由守卫统一拦截，不需要做动态路由权限。只有管理员和普通用户两档角色，动态路由的收益太小，反而增加实现复杂度。

页面组件建议按业务拆分，导航栏组件、线路卡片组件、订单状态标签组件都单独放。这样用户端和管理端复用组件时，只需要传不同的数据，避免了在多个页面里复制粘贴大段模板代码。组件化的意义不单是让代码更短，而是让某个功能有了唯一的修改入口。

5.2 路由守卫与Axios请求拦截

用户没有登录时，可以浏览景点和线路，但进入个人中心和下单页就必须登录。路由守卫在beforeEach里判断目标路由的meta.requiresAuth，必要时检查本地存储里的token，没有就跳转登录页。登录成功后把用户基本信息也写入本地存储，页面顶部显示头像和昵称，刷新后不丢失，这个小优化能明显提升演示体验。

axios封装是前端工程的必修课。创建一个axios实例并配置baseURL；请求拦截器从本地存储取token，放到Authorization头；响应拦截器统一处理后端返回的Result结构，如果code不是200，使用组件库的Message或ElMessage提示后端返回的message，如果遇到401则清理token并跳转登录页。这样每个页面里的接口调用都只关心正常的业务数据，不用重复写错误弹窗。

5.3 列表展示、服务端分页与状态标签

线路列表和管理端订单列表面临同一个问题：数据量一大，不能一次查全。前端分页组件把当前页码和每页条数传给后端，后端做服务端分页，返回total和当前页记录。这个“为什么不在前端一次查全”的问题在答辩中出现的频率很高，回答思路是：服务端分页减少网络传输数据量、提升响应速度，也避免前端渲染大量DOM导致卡顿，同时分页本身是后端对大批量数据的通用控制手段。

订单状态标签这种重复展示的逻辑，建议封装成一个组件，传入状态值渲染对应的颜色和文案。管理端多处使用的景点选择器、线路选择器也抽成组件，接口字段变动时只改一处。页面表单要同时做前端校验和后端校验，前端校验拦住大多数不符合规则的提交，后端校验兜底保证接口安全，这两层不能省。

6. 联调、部署与答辩展示阶段的经验沉淀

6.1 跨域问题的两种解决路径

前后端分离项目必须要处理跨域。开发环境最简单的前端代理方案，配置Vite或webpack的proxy，把以/api开头的请求代理到本地Java服务端口，开发时完全不用在后端操心跨域。生产环境用Nginx反向代理转发/api请求到Java服务，Nginx本身就绕开了浏览器同源策略的限制，后端甚至可以不配置跨域。如果坚持在后端配置CORS，注意当需要携带凭证时不能使用allowedOrigins("*")，要改用allowedOriginPatterns指定允许的来源模式，否则浏览器会拦截响应。这个细节经常表现为前端控制台报CORS错误，但后端日志显示接口已经执行了，其实就是响应在浏览器侧被拦截了。

6.2 从本地到服务器的部署操作清单

部署可以拆成四步：前端构建、后端打包、环境配置、服务托管。前端执行npm run build，把dist目录放到Nginx的html目录，并配置一条把/api路径代理到SpringBoot服务的规则；后端用Maven打成可执行jar，通过systemd注册一个服务，设置开机自启和异常自动重启，避免进程意外退出后还要手动拉起。配置文件用spring.profiles.active区分开发和生产环境，生产配置里数据库地址、文件上传路径、JWT密钥都要单独设置，不要把本地账号密码带到线上环境。

Linux服务器上最容易忽略的是三个点。第一是时区，系统默认的UTC会导致时间显示偏差，启动脚本里要显式指定时区；第二是字符集，连接参数里需要指定UTF-8和服务端时区，否则中文乱码问题会反复出现；第三是静态资源目录权限，Java进程必须对上传目录有写权限，否则图片传不上去，接口却一直报别的错误，排查半天才发现是权限问题。

6.3 答辩演示的流程和“话术”准备

演示顺序建议这样安排：先走用户端全流程，从注册或登录开始，浏览景点线路、搜索筛选、进入线路详情查看团期余位、选择日期和人数组装订单、提交后到个人中心看状态变化；然后切到管理端，找到刚才这笔订单做确认和状态更新，再演示景点和线路的增改。这样评委看到的是一套完全打通的链路，而不是两个孤立的界面。

还要准备若干高频问题：JWT和Session的区别是什么；超卖问题是怎么解决的；为什么订单表要冗余快照字段；为什么分页必须做在后端；图片为什么不存入数据库；MySQL以后数据量变大了怎么办。每一个问题都可以从前面章节的决策理由里找到答案，用自己的话整理一遍，比背概念有用得多。

6.4 收尾：一点个人体会

这几年带题目的体会是，类似的项目拉开差距的地方不在功能多少，而在细节深浅。你能把订单状态流转讲清楚，把余位条件更新讲明白，把订单快照字段的原因说透，比堆十个半成品模块更有说服力。后续想扩展的话，建议不要急着加秒杀或者推荐系统，先从订单导出、线路收藏、多条件搜索优化这种能快速看到效果的小功能入手，每加一个就让它真正跑通、讲得明白，这个项目的价值会一点点积累起来。