企业官网建设流程全解析

带毕设这几年，接触最多的就是各种"管理系统"，其中景区管理系统是个很有意思的选题。业务上它有真实的应用场景——门票、景点、导游、订单、统计，把这些逻辑捋清楚，代码量和工作量都足够扎实；技术上它又可以稳稳落在SpringBoot + Vue这套主流全栈组合里，不像秒杀系统那样需要扛并发，也不像纯CRUD那样显得单薄。文章后面我会把整个系统的破题思路、数据库设计、后端接口、前端页面到部署答辩，完整拆一遍，代码和设计文档怎么组织、哪些地方容易被老师追问，都会交代清楚。

1. 为什么景区管理系统是毕设的热门选题

1.1 选题价值与难度定位

选毕设题目，最怕两种：一种是题目太大，分布式、高并发、微服务全部堆上去，结果论文写得像概念综述，代码根本没跑通；另一种是题目太小，一张表搞定，老师看了直摇头。景区管理系统刚好卡在中间。

它覆盖了一个完整业务系统该有的要素：用户角色（管理员、游客/会员）、核心业务（景点信息、门票预订、订单支付、导游预约）、运营支撑（公告、评论、数据统计）。这套业务模型的复杂度，恰好能撑起一篇合格的本科毕业论文，又不会让你在半年时间里陷进技术深坑。

很多同学纠结"要不要加个推荐算法""要不要上Redis缓存"，我的建议是：先把基础功能做扎实。毕设评审看的是你能否把需求分析、设计、实现、测试这套工程流程走通，而不是技术名词堆得有多高。一个跑得稳、文档全、逻辑清楚的景区管理系统，远比一个半成品的技术杂烩得分高。

1.2 技术栈选择背后的一笔账

SpringBoot + Vue这个组合为什么成了默认答案，是有原因的。

后端选SpringBoot，核心是"约定大于配置"救了很多人的命。传统SSH（Struts + Spring + Hibernate）那套，光配置文件就能把人绕晕；SpringBoot把内嵌Tomcat、自动配置、起步依赖全部做进去了，你写一个@RestController就能把接口跑起来，这对毕设周期来说太友好了。同时，SpringBoot是Java后端招聘市场的主流要求，做完这个项目，你简历上写的"熟练使用SpringBoot"是有实际项目背书的。

前端选Vue，原因更简单：上手曲线平缓，中文资料多，Element UI组件库拖出来直接就能拼出后台管理界面。Vue的双向绑定和组件化思想，比jQuery时代写DOM操作不知道高到哪里去，而且现在很多公司前端就是Vue栈，学了不亏。

数据库选MySQL，没什么可争议的，开源、稳定、资料多，Navicat或者dbx这种可视化工具一连，建表查数据都直观。整个技术栈的选型逻辑可以用一句话概括：用最主流的工具，做最稳妥的项目，拿最有说服力的结果。

2. 业务拆解：景区管理到底在管什么

2.1 角色与核心业务流程

拿到题目先别急着写代码，把业务流程画明白，后面能省一半返工的时间。我习惯用"角色-用例"的方式来拆。

景区管理系统通常有两大类角色：

• 系统管理员：维护景点信息、管理门票类型和价格、处理订单、发布公告、查看统计数据。
• 游客/注册用户：浏览景点、在线购票、预约导游、查看个人订单、发表评论。

核心业务流程也不复杂：游客注册登录后，在景点列表里选景点，下单支付（毕设一般用模拟支付），形成订单；管理员在后台可以看到订单流水，统计每个景点的售票情况；导游预约则是把导游资源和游客需求匹配起来，生成预约记录。

有一个关键点容易被忽略：订单状态的管理。待支付、已支付、已使用、已取消、已退款，这几种状态之间的流转逻辑，不仅在代码里要写清楚，在论文的用例图、状态图里也要能自圆其说。很多学生答辩被问倒，就是死在"你这个订单能退款吗？退款后库存怎么恢复？"这种问题上。

2.2 功能模块清单

把业务流程翻译成功能模块，我一般分成这几个：

这个清单看着多，但每个模块的实现难度都不高，属于"体力活"性质。真正需要动脑子的，是订单和库存的关系、是权限控制怎么做，这两个点我会在后面重点讲。

2.3 论文结构怎么和系统对应

这里多说一句论文的事，因为很多同学代码写完了发现论文不会组织。我的建议是论文目录和系统架构严格对应：

• 第一章绪论写研究背景和意义，把"智慧旅游""数字化转型"这几个词自然地带进去；
• 第二章需求分析，对应上面的功能模块清单，画用例图；
• 第三章系统设计，画架构图、功能结构图、数据库ER图；
• 第四章系统实现，按后端接口和前端页面分节写，每个功能配截图和核心代码段；
• 第五章测试，写功能测试用例表和结果。

这样论文和工作量是"一套东西的两面"，答辩的时候老师让你演示哪个功能，你都能在论文里找到对应的章节。

3. SpringBoot后端：接口设计的核心思路

3.1 工程分层与包结构

后端代码的组织方式，直接反映了你"会不会写工程代码"。我见过不少学生的后端，所有逻辑全堆在Controller里，一个方法三五百行，这种代码虽然能跑，但在老师和面试官眼里是要扣分的。

规范的工程结构应该按职责分层：

com.example.scenic ├── controller // 接收请求，返回结果 ├── service // 业务逻辑 │ └── impl ├── mapper // 数据库访问（MyBatis） ├── entity // 实体类 ├── dto // 数据传输对象 ├── common // 通用返回结果、异常处理、工具类 └── config // 配置类（拦截器、跨域等）

分层的好处是：Controller只负责参数接收和结果封装，Service写业务规则，Mapper只做数据库交互。后面扩展功能、修bug，都清楚该去哪个层改代码。这也是答辩时老师喜欢看到的"工程素养"。

3.2 JWT认证与权限控制

景区管理系统虽然简单，但"不同角色看到不同内容"这个需求必须有。管理员不能像普通用户一样下单，游客也不能进后台管理页面。实现方案我推荐JWT（JSON Web Token）。

流程是这样的：用户登录成功后，后端用JWT生成一个token返回给前端；前端把token存到localStorage，每次请求在header里带上Authorization: Bearer xxx；后端用拦截器解析token，识别用户身份。

核心代码大致是：

// 登录接口 @PostMapping("/login") public Result login(@RequestBody LoginDTO loginDTO) { User user = userService.login(loginDTO.getUsername(), loginDTO.getPassword()); String token = JwtUtil.generateToken(user.getId(), user.getRole()); return Result.success(new LoginResponse(token, user)); }

// JWT工具类（简化版） public class JwtUtil { private static final String SECRET = "your-secret-key"; private static final long EXPIRE = 1000 * 60 * 60 * 24; // 24小时 public static String generateToken(Long userId, String role) { return Jwts.builder() .claim("userId", userId) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET).parseClaimsJws(token).getBody(); } }

同时在后端加一个拦截器，所有需要登录的接口都走token校验，管理员接口再额外校验role字段。这个方案比Session简单，前端后端都省心，而且论文里写"基于JWT的认证机制"是很标准的表述。

3.3 订单与库存的事务处理

订单模块是整个系统最值得写进论文的部分，因为这里有真正的业务逻辑：用户下单时要扣减门票库存，订单取消时要恢复库存，而且这两个操作必须保证原子性——不能出现库存扣了但订单没生成的情况。

这里必须用@Transactional事务注解：

@Transactional(rollbackFor = Exception.class) public Order createOrder(OrderCreateDTO dto) { // 1. 查门票库存 Ticket ticket = ticketMapper.selectByIdForUpdate(dto.getTicketId()); if (ticket.getStock() < dto.getQuantity()) { throw new BusinessException("库存不足"); } // 2. 扣减库存 ticketMapper.decreaseStock(dto.getTicketId(), dto.getQuantity()); // 3. 创建订单 Order order = new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(dto.getUserId()); order.setTicketId(dto.getTicketId()); order.setQuantity(dto.getQuantity()); order.setAmount(ticket.getPrice() * dto.getQuantity()); order.setStatus(1); // 待支付 orderMapper.insert(order); return order; }

注意selectByIdForUpdate这句，它加了一把行级锁，防止两个用户同时下单导致库存超卖。这个细节如果能在论文里写出来，是一大加分项，因为它是真的考虑了并发问题的。

另外一个教训是：订单号和主键id不要混用。主键id是数据库自增的，暴露给用户会很奇怪；订单号应该用时间戳加随机数生成，比如20250607123045 + 4位随机数，看起来专业，后面做统计也方便。

3.4 统一返回结果与全局异常

前端和后端交互，格式必须统一。我用的最简单方案是定义一个Result类：

@Data public class Result<T> { private Integer code; // 200成功，500失败 private String message; private T data; public static <T> Result<T> success(T data) { return new Result<>(200, "操作成功", data); } public static <T> Result<T> error(String message) { return new Result<>(500, message, null); } }

所有Controller方法都返回这个Result，前端拿到后统一判断code === 200，再处理数据。配合一个全局异常处理器：

@RestControllerAdvice public class GlobalExceptionHandler { @ExceptionHandler(BusinessException.class) public Result<?> handleBusinessException(BusinessException e) { return Result.error(e.getMessage()); } }

这样业务代码里该抛异常就抛异常，不用每个方法都写try-catch，代码干净很多。这两个类属于"每个项目都会用到的基建"，早点写好，后面所有接口开发速度都能提上来。

4. Vue前端：从零搭出一个可用的管理端

4.1 工程初始化与目录组织

前端我用Vue 2 + Element UI这套组合，别问我为什么不用Vue 3，稳定才是第一位的。Vue 2的资源最多，任何奇怪的问题百度都有答案，对毕设来说是性价比最高的选择。

用Vue CLI创建工程后，我习惯把目录整理成：

src ├── api // 所有接口请求封装 ├── assets // 静态资源 ├── components // 公共组件 ├── router // 路由配置 ├── store // Vuex状态管理 ├── views // 页面 │ ├── admin // 管理后台页面 │ └── front // 前台页面 ├── utils // 工具函数（axios实例等） ├── App.vue └── main.js

views下面分admin和front两个目录，是我比较推荐的做法。管理后台和前台流量入口是两套界面，混淆在一起后面改起来会很痛苦。

4.2 Axios封装与路由守卫

前端核心工程化的第一步是封装axios实例。我见过很多同学的代码，每个页面里直接this.$http.get(...)，没有统一的封装，遇到token过期、接口报错，处理逻辑散落各处。正确做法是：

// utils/request.js import axios from 'axios' import { Message } from 'element-ui' import router from '@/router' const request = axios.create({ baseURL: '/api', // 开发环境走代理 timeout: 10000 }) // 请求拦截器：附加token request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = 'Bearer ' + token } return config }) // 响应拦截器：统一处理错误 request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { Message.error(res.message) return Promise.reject(new Error(res.message)) } return res.data }, error => { if (error.response && error.response.status === 401) { Message.error('登录已过期，请重新登录') localStorage.removeItem('token') router.push('/login') } else { Message.error('网络异常') } return Promise.reject(error) } ) export default request

第二件事是路由守卫。管理后台的路由必须在登录后才能访问：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.meta.requiresAuth && !token) { next('/login') } else if (to.path === '/login' && token) { next('/') } else { next() } })

这个拦截逻辑和后端的JWT校验形成双保险：前端控制页面能不能进，后端控制数据能不能拿，两层都过才算真正安全。

4.3 核心页面设计思路

前端页面虽然多，但归纳起来就三类：列表页、表单页、统计页。

景点列表页是最典型的列表页：顶部搜索栏（关键词、分类筛选），中间表格（Element UI的el-table），底部翻页（el-pagination）。这里有一个实用经验：分页参数一定要在请求里带上pageNum和pageSize，别偷懒一次全查出来，数据量大了页面会卡。

下单表单页要注意联动交互：用户选了门票类型后，前端要实时算总价；库存不足时提交按钮要置灰。这些交互逻辑写清楚，页面体验一下子就上来了，答辩演示的时候也更有话说。

统计页是性价比最高的一页。用ECharts画三个图：每月售票量的折线图、各景点售票占比的饼图、热门景点排行榜的柱状图。前端组件自带图表缩放和tooltip，视觉效果好，后端也只需要提供几个聚合查询接口，工作量不大但答辩时非常出彩。

4.4 前后端联调与跨域处理

本地开发时，前端跑在localhost:8080，后端跑在localhost:8081，必然存在跨域问题。解决办法有两个，我都用过：

一是在Vue的vue.config.js里配置代理：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true } } } }

二是在后端配置跨域：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("*") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

我推荐两种都写上，开发时走代理最省事，部署后如果前后端分开部署，后端跨域配置能兜底。

5. 数据库设计：表结构决定系统的天花板

5.1 核心表结构

数据库设计是整个系统里最不能返工的部分。表建错了，后面代码全得跟着改。景区管理系统我一般设计这几张核心表：

用户表（user）

景点表（scenic_spot）

门票表（ticket）

订单表（orders）

**导游预约表（guide_reservation）和评论表（comment）**结构类似，核心都是业务主键 + 关联用户 + 内容/时间。公告表则更简单，title + content + create_time就够了。

5.2 外键与索引的取舍

一个常见的纠结是：到底要不要建外键？我的建议是逻辑关联，物理不建外键。也就是说，ticket.scenic_id在业务上关联scenic_spot.id，但你不在数据库层面加FOREIGN KEY约束。

原因很实际：加了外键之后，删除景点时如果还有关联门票，数据库会拒绝删除或者报错，给毕设的增删改查功能带来很多不必要的麻烦。而在Service层自己控制关联校验，处理逻辑更灵活，代码表现力也更强。这个观点论文里可以写，答辩时老师问起来你能说出理由，反而是加分项。

索引方面，必加的索引就两个：user.username的唯一索引，orders.user_id的普通索引（查某个用户的订单列表）。其他的等数据量大了再考虑，毕设阶段不用过度设计。

5.3 常用聚合查询

统计模块需要几类查询，写进MyBatis的XML文件里即可：

<!-- 各景点门票销量排行 --> <select id="selectScenicSalesRank" resultType="map"> SELECT s.name AS sceneryName, SUM(o.quantity) AS totalSales FROM orders o JOIN ticket t ON o.ticket_id = t.id JOIN scenic_spot s ON t.scenic_id = s.id WHERE o.status IN (2, 3) GROUP BY s.id ORDER BY totalSales DESC </select>

<!-- 按月份统计售票量 --> <select id="selectMonthlySales" resultType="map"> SELECT DATE_FORMAT(create_time, '%Y-%m') AS month, COUNT(*) AS orderCount, SUM(amount) AS totalAmount FROM orders WHERE status IN (2, 3) GROUP BY DATE_FORMAT(create_time, '%Y-%m') ORDER BY month </select>

这种聚合查询在ECharts里展示效果很好，而且SQL写出来也是论文第四第五章的素材，不用另外编造数据。

6. 从跑通到答辩：最后的临门一脚

6.1 本地运行的全流程清单

很多同学卡在"代码有了但跑不起来"这一步。我整理一个排查清单，按顺序走一遍基本都能跑通：

1. 数据库初始化：用Navicat或dbx新建数据库，导入scenic.sql脚本，确认所有表和数据都在。
2. 后端启动：检查application.yml里的数据库用户名、密码、URL是否匹配；确认Maven依赖下载完整；启动后看到"Started Application"日志说明成功。
3. 前端启动：npm install装依赖，npm run serve启动，注意Node.js版本和Vue CLI的兼容性。
4. 联调验证：先不加token直接访问接口，确认能拿到401；登录后拿token再访问，确认能拿到数据。前后端通了，再逐页点功能。

最常见的问题是Maven仓库依赖缺包和npm版本冲突。遇到过Node 18配老版本Vue CLI装不上依赖的情况，解决办法是降Node版本到16，或者升级Vue CLI。这种细节写进README文档里，能帮后面的同学少走很多弯路。

6.2 答辩老师最爱问的问题

答辩环节，老师问的问题通常集中在三个方向：

• "为什么用这个技术方案？"要答出选型对比：为什么不选JSP/Servlet、为什么不直接用Thymeleaf、为什么用Vue不用React。不需要贬低其他技术，说清楚"因为毕设需要前后端分离的架构思路"即可。
• "这个系统的安全性怎么样？"至少要答出三层：密码MD5加盐或BCrypt加密存储、JWT做身份认证、后端接口做了角色鉴权。如果再能说出SQL注入通过预编译PreparedStatement来防，那就是超纲加分。
• "系统有哪些不足和未来改进？"记住，老师希望你承认系统有局限，但你要展示你思考过。可以答"当前使用本地存储模拟支付，未来可以对接微信支付；数据量增加后可以引入Redis缓存热点景点数据"，既诚实又有深度。

6.3 文档与源码的整理规范

最后交付的源码和文档，建议按照这个结构整理：

景区管理系统源码 ├── backend // SpringBoot工程 │ └── src ├── frontend // Vue工程 │ └── src └── sql // 初始化脚本 └── scenic.sql

配套文档至少包含：开题报告、任务书、论文正文（含中期检查表）、答辩PPT、演示视频。论文里的截图一定重新截，不要用占位图；核心代码段要精选，别把一整页代码贴上去；数据库设计部分放ER图和建表SQL。

我在帮学生整理毕设资料的时候，见过太多因为"文档和代码对不上"被老师挑刺的情况——论文里写的字段名和代码里的实体类不一致、截图的页面和最终代码不是同一个版本。这些问题在提交前花半小时就能核对完，千万别省。

做一个毕设，代码能力是一方面，把整个工程闭环走完、把所有材料组织成一套能自圆其说的作品，才是答辩过关的关键。景区管理系统这个选题好就好在，它让你用最主流的技术栈完整体验了一次"从需求到交付"的过程。这个项目跑通的那一刻，你对SpringBoot和Vue的掌握程度，就已经和只看教程完全不同了。