★ FEATURED ARTICLE 做一个能拿去答辩、能写进简历、还能真正跑起来的前后端分离项目最怕的就是“功能看着多实际全是增删改查”。SpringBoot Vue 的安康旅游网站管理平台不一样的地方在于它把旅游业务里最常见的用户、景点、线路、订单、评论、统计这些模块串成了一个完整闭环后端是 Java 生态里最主流的 SpringBoot前端是 Vue数据库用 MySQL。对毕设、课设或者想系统学一遍前后端分离开发的人来说这套源码既能当项目底座也能当学习教材。这篇文章我打算换个讲法不贴一堆项目截图凑字数而是从项目拆解、技术选型、表结构设计、环境搭建、核心功能实现、常见坑这几个维度把整个项目从头到尾讲透。里面涉及的代码和步骤都是可以直接复制的每个关键设计我也会把背后的原因讲清楚这样你写完报告或者准备答辩的时候心里是有底的。1. 项目整体拆解一个旅游平台到底该有哪些东西1.1 用户视角游客在系统里能做什么很多初学者一看“旅游网站”四个字第一反应就是景点列表加个详情页但实际做下来你会发现一个能称为“平台”的系统用户侧的体验链路必须是完整的。这个项目里用户端的核心路径是注册登录 → 浏览景点 → 查看线路 → 下单预订 → 发表评论 → 查看个人订单。这条链路里的每一步都不是孤立的比如你要下单前提是景点和线路数据存在你要评论前提是订单状态已经是“已完成”。这种业务约束正好是答辩时能讲出来的亮点也是课程设计评分时最看重的“业务完整性”。另外用户端还包含搜索和筛选功能。游客可以按景点名称搜索按区域、分类、价格区间筛选线路分页查看结果。这些功能听起来简单但实现的时候会涉及后端接口的参数设计、MySQL 的模糊查询、前端搜索框的防抖处理每一个点都能单独展开讲。就算你的课设只需要“能用”把搜索做规范了代码质量也会明显高一个档次。1.2 管理视角运营人员在后台能做什么管理端是这个项目另一个重头戏。管理员登录后需要维护的内容包括景点信息、旅游线路、酒店民宿、资讯公告、订单审核、用户管理、评论管理、数据统计等模块。说白了用户端展示的每一条数据都必须在管理端能增删改查用户产生的每一笔订单管理端都要能看到状态并且可以处理。这种“前台展示 后台管理”的双端结构是绝大多数企业级 Web 项目的标准形态也是面试官最熟悉的项目形态。这里我想特别提醒一点做毕设的时候管理端不要做成只有一个“用户列表”的摆设。这个项目里能学到的管理端细节很多比如分页查询时条件怎么组合、删除景点时关联的线路和订单怎么处理软删除还是硬删除、图片上传后 URL 怎么存、统计报表的数据用什么接口聚合。这些细节你在写论文的“系统设计”章节时都能用上。1.3 为什么业务闭环比功能数量更重要判断一个项目适不适合当毕设不是数它有几个页面而是看业务能不能闭环。举个例子如果只有景点 CRUD没有订单那系统就是一个“数据管理后台”谈不上“平台”如果有订单但订单不关联库存、不改变状态那订单就是一张空表。这个安康旅游平台把“浏览—预订—支付—评价—统计”串到了一起数据在表之间流动状态在接口之间流转这才是“平台”二字的含义。从答辩的角度讲业务闭环意味着你可以画出一张完整的数据流图可以讲清楚订单表为什么要有 status 字段、评论表为什么外键关联订单而不是用户这些设计理由比“我用了 Vue SpringBoot”这种话有力得多。从学习的角度讲你跟着这个闭环走一遍前后端数据交互的整个套路就通了。2. 技术选型为什么这套组合是毕设的“标准答案”2.1 SpringBoot后端开发的“默认答案”SpringBoot 在 Java 后端开发里的地位基本等同于“默认答案”。它把 Spring 框架里繁琐的 XML 配置变成了自动配置内嵌 Tomcat 让项目可以用一个 main 方法直接启动配合 Spring MVC 写 RESTful 接口非常直观。对毕设来说SpringBoot 还有一个隐藏优势社区资料多你遇到任何报错搜索一下基本都有解决方案这点在赶工的时候能救命。这个项目里SpringBoot 的核心职责是提供 REST API、处理业务逻辑、操作数据库。你会用到 Spring Web、Spring Data JPA 或 MyBatis、Spring Validation 参数校验、JWT 鉴权、跨域配置等模块。用 SpringBoot 还有个好处是它的依赖管理很省心Maven 引入 starter 之后基本不用管版本兼容问题。2.2 Vue前端开发的高效选择Vue 的核心优势是组件化和响应式数据绑定。组件化意味着你可以把导航栏、景点卡片、分页器、弹窗提示这些 UI 拆成独立组件改一处全站生效响应式意味着你不需要像 jQuery 时代那样手动操作 DOM数据变了页面自动更新。这个项目用 Vue 2 Element UI 或 Vue 3 Element Plus 都能跑具体看你拿到的源码版本但核心思想一致前端通过 Axios 调用后端接口拿到 JSON 数据后渲染页面。对初学者来说Vue 的学习曲线比 React 平滑得多模板语法接近 HTML上手成本很低。而且 Element UI 这类组件库能直接给你表格、表单、日期选择器、分页、弹窗写管理端页面基本就是搭积木。这个项目的管理端页面大量使用了这类组件非常适合用来练手。2.3 MySQL业务数据的第一选择MySQL 不用多说开源、稳定、资料全是绝大多数中小型 Web 项目的首选数据库。选择 MySQL 意味着你的表结构设计、SQL 查询、事务处理、索引优化这些知识都能直接迁移到工作场景里。这个项目里的核心表包括用户表、景点表、线路表、订单表、评论表、公告表等表之间通过外键逻辑关联比如订单表关联用户和线路评论表关联用户和订单。如果让我给初学者一个建议那就是拿到项目后先不要急着启动先花半天时间把 SQL 脚本里的建表语句一条条看懂。看懂了表结构你就知道一个旅游平台的数据是怎么组织的后面看代码会轻松很多。2.4 前后端分离架构要解决的关键问题前后端分离听起来高大上本质就是前端跑在一个端口后端跑在另一个端口前端通过 HTTP 请求调用后端接口。这种架构带来三个必须解决的问题跨域、鉴权、接口约定。跨域是因为前端地址和后端地址的协议、域名、端口不一致浏览器默认会拦截响应需要在后端配置跨域过滤器或者在前端配置代理。鉴权是因为 HTTP 请求是无状态的后端需要一种方式识别“你是谁”这个项目用的方案是 JWT登录成功后后端签发一个 token前端存在本地存储里每次请求带上后端校验通过才算合法。接口约定是前后端开发时的“合同”比如列表接口返回什么结构、分页参数叫什么名字、错误码怎么定义这些在项目中都有统一规范很值得学习。3. 数据库设计先看懂表才能看懂代码3.1 核心表结构设计我在拿到一套源码的时候习惯先看数据库脚本因为表结构是业务的骨架子。这个项目里比较关键的表大概有这些表名核心字段作用userid, username, password, nickname, avatar, role存储用户和管理员账号role 区分权限scenic_spotid, name, description, address, price, image, category景点基础信息routeid, name, spot_ids, price, days, detail旅游线路可能关联多个景点hotelid, name, address, price, image酒店民宿信息ordersid, order_no, user_id, route_id, hotel_id, status, total_price核心订单表状态流转的核心commentid, user_id, order_id, content, rating, create_time用户评价noticeid, title, content, create_time公告资讯cartid, user_id, route_id, quantity购物车部分版本有设计上的几个关键决策值得说一下。第一用户表里用 role 字段区分管理员和普通用户这样一套登录接口就能覆盖两个端而不是建两张用户表。第二订单表里有 order_no 这种业务编号看起来和 id 重复但实际业务中订单号用来给用户看、用来对账id 只是数据库内部用两者职责不同。第三评论表外键关联的是订单而不是直接关联用户和线路这样能防止“没买过就能评论”这种逻辑漏洞。3.2 订单状态流转一张表怎么支撑完整业务订单表里的 status 字段是整个项目业务逻辑最密集的地方。常见状态可以设计为待支付、已支付待出行、已完成、已取消。每个状态对应一组用户操作和管理员操作用户下单生成“待支付”订单支付后变成“已支付”出行结束后管理员或系统标记“已完成”用户此时才能评价。任何状态下用户都可以申请取消取消后订单进入“已取消”状态。这个状态机设计在答辩时特别好讲。你可以画一张简单的状态图说明每个状态之间的迁移条件和触发动作。比如“已完成”状态不是说改就能改必须校验订单是否已支付、是否在出行日期之后这些规则写在 Service 层的代码里。这种“状态 校验 操作”的写法就是企业里常说的业务逻辑封装。3.3 索引与查询优化数据量大了怎么办毕设项目通常数据量不大但如果你在论文里写了“系统具有较好的性能”就得懂点索引知识。这个项目里最常用的查询场景是按景点名称模糊搜索、按线路价格区间筛选、按用户查询订单列表、按时间范围统计订单金额。针对这些场景合理的索引设计是scenic_spot 表的 name 字段加普通索引模糊查询 LIKE 开头是通配符时索引会失效这点可以在论文里讨论orders 表的 user_id 加索引orders 表的 create_time 加索引用于统计查询。另外一个常见优化是分页。前端传 pageNum 和 pageSize后端用 LIMIT 实现分页同时返回 total 总数。MySQL 的 COUNT 查询在大表下会变慢但在毕设数据量下完全没问题真正需要讲的是分页参数怎么从前端传到后端再传回前端这个链路本身就是很好的接口设计案例。4. 从零启动项目环境配置与踩坑准备4.1 环境版本对照先别急着装最新版启动这个项目之前先把环境版本对齐这是我见过初学者最容易卡住的地方。后端建议 JDK 1.8 或 11SpringBoot 2.x 版本如果是 3.x 要注意 JDK 版本要升级前端建议 Node.js 14 以上npm 6 以上。数据库用 MySQL 5.7 或 8.0 都行但 8.0 要注意时区和认证插件的问题下面我会细说。建议的本地环境清单如下JDK 8、Maven 3.6、Node.js 14、MySQL 5.7、IDEA后端、VSCode 或 WebStorm前端。不要一上来就装最新的 JDK 21很多旧项目在 JDK 17 以上会有兼容问题SpringBoot 2.x 配合 JDK 8 是最稳的组合。4.2 数据库初始化两条命令搞定项目里一般会提供一个 .sql 文件比如an_kang_travel.sql。启动数据库后先创建数据库实例再导入脚本CREATE DATABASE an_kang_travel DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE an_kang_travel; SOURCE /你的路径/an_kang_travel.sql;用 utf8mb4 而不是 utf8 的原因是utf8mb4 才能完整支持中文和 emoji 字符避免评论内容带表情符号时插入报错。导入完成后用 Navicat 或 DataGrip 随便查一张表确认数据存在即可。4.3 后端启动改三个配置就够后端项目用 IDEA 打开等待 Maven 下载依赖然后修改配置文件application.yml里的数据库连接信息和 JWT 密钥server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/an_kang_travel?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver jwt: secret: your-secret-key expire: 604800这里要提醒两个高频坑。第一serverTimezoneAsia/Shanghai少写了会直接报时区错误。第二如果你用的是 MySQL 8.x 而驱动是com.mysql.jdbc.Driver启动会报警告或直接失败要改成com.mysql.cj.jdbc.Driver。改完配置直接运行主类里的 main 方法看到“Started Application”字样就是启动成功。4.4 前端启动npm 装依赖要有耐心前端项目在终端里依次执行npm install npm run servenpm install如果速度很慢可以换成国内镜像源npm config set registry https://registry.npmmirror.com启动成功后会显示本地访问地址一般是http://localhost:8081或http://localhost:3000。打开页面后如果所有接口都报错不要慌先看前端配置文件里的代理设置。Vue CLI 项目的vue.config.js通常会有类似这样的代理配置devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这个代理的意思是前端把以/api开头的请求转发到后端 8080 端口。如果没配代理前端直连后端需要后端开启跨域两种方式任选其一但最好是都有。5. 核心功能实现从接口设计到具体代码5.1 登录鉴权JWT 的完整流程登录功能看起来简单但前后端分离下的登录和传统 session 登录有本质区别。这个项目的流程是前端把用户名密码发给后端/api/user/login后端校验通过后生成一个 JWT token 返回给前端前端把 token 存到 localStorage之后每次请求都在请求头里带上Authorization: Bearer token后端通过拦截器统一校验。一个典型的登录接口代码如下PostMapping(/login) public Result login(RequestBody LoginDTO dto) { User user userService.login(dto.getUsername(), dto.getPassword()); if (user null) { return Result.error(用户名或密码错误); } String token JwtUtil.generateToken(user.getId(), user.getUsername(), user.getRole()); return Result.success(new LoginVO(token, user)); }这里的JwtUtil负责生成和解析 tokenInterceptor负责拦截需要登录的请求。有一点你要注意密码千万别明文存数据库项目里如果是明文你可以在写论文时顺手改成 MD5 加盐或 BCrypt这是很好的“个人改进点”。5.2 景点列表分页 搜索 条件筛选用户端首页最有代表性的接口是景点分页列表。前端传pageNum、pageSize、keyword、category等参数后端用 MyBatis 或 JPA 查询数据库返回固定格式的数据结构public PageResultScenicSpot page(ScenicSpotQuery query) { PageHelper.startPage(query.getPageNum(), query.getPageSize()); ListScenicSpot list scenicSpotMapper.selectByCondition(query); PageInfoScenicSpot info new PageInfo(list); return new PageResult(info.getTotal(), info.getList()); }返回给前端的数据结构建议统一为{ code: 200, message: success, data: { total: 100, list: [] } }这种统一返回格式是前后端联调的核心。如果每个接口返回结构都不一样前端就得每个接口单独写解析逻辑那代码就没法维护了。这也是写论文时“系统设计”章节里值得大书特书的一点。5.3 下单与订单状态更新事务是关键下单接口是业务逻辑最集中的地方。用户选择线路和日期后后端要做的动作包括校验线路是否存在、计算总价、生成订单号、扣减库存如果线路有库存概念、插入订单记录。这些动作必须放在一个数据库事务里任何一个失败都要回滚否则会出现“订单生成了但库存没减”这种脏数据。一个精简的下单逻辑是Transactional public Long createOrder(OrderCreateDTO dto) { Route route routeService.getById(dto.getRouteId()); if (route null) throw new BusinessException(线路不存在); Order order new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(dto.getUserId()); order.setRouteId(route.getId()); order.setTotalPrice(route.getPrice() * dto.getNum()); order.setStatus(OrderStatus.PENDING_PAYMENT); orderMapper.insert(order); return order.getId(); }这里的关键是Transactional注解。你可能觉得毕设里数据量小事务无所谓但面试官一定会问所以你要能说清楚事务保证的是“多个操作要么全部成功要么全部失败”在下单场景里就是不能出现半成功状态。5.4 统计报表管理端的数据看板管理端首页一般会有统计图比如近一周订单量趋势、热门景点排行、用户增长曲线。这些图表的数据来自统计接口典型的实现是用一条带分组的 SQLSELECT DATE(create_time) AS day, COUNT(*) AS order_count FROM orders WHERE create_time #{startTime} GROUP BY DATE(create_time) ORDER BY day前端拿到数据后用 ECharts 渲染折线图和柱状图。这个模块是项目里“看起来最厉害”的部分但实现难度并不高核心就是 SQL 的聚合分组。建议你重点掌握这一块答辩演示的时候打开数据看板比口头讲一百句都有说服力。6. 常见问题与排查实录6.1 前端页面能打开但接口全报 404这个问题我见到的频率最高。页面能打开说明前端代码没问题接口 404 基本是路径问题。排查步骤是打开浏览器开发者工具的 Network 面板看请求的完整 URL。如果请求落在http://localhost:8081/api/xxx但后端接口路径是/api/xxx且后端端口是 8080那就需要检查前端代理是否生效或者直接改成完整地址请求。还有一种可能是后端的 context-path 配置如果 application.yml 里设置了server.servlet.context-path所有接口会自动加前缀前后端必须对应。6.2 MySQL 8.0 连接报时区错误报错信息一般是The server time zone value Öйú±ê׼ʱ¼ä is unrecognized。解决方案有两种一是在 JDBC URL 后面加serverTimezoneAsia/Shanghai二是执行数据库命令SET GLOBAL time_zone 8:00。第一个方法简单推荐优先使用。6.3 npm install 报错或卡住常见原因是网络问题或 Node 版本不兼容。先切换镜像源再删除node_modules和package-lock.json重新安装。如果项目用的是 node-sass 这类原生模块很容易因为 Node 版本太新导致编译失败建议直接看 package.json 里的版本要求装对应版本的 Node。6.4 登录后刷新页面就失效这个问题的根因通常是没有持久化登录状态。JWT 本身可以设置过期时间但如果前端只在内存里保存 token刷新就会丢失。正确做法是把 token 存到 localStorage在路由守卫里检查本地是否存在 token不存在则跳转登录页。同时每次请求在 Axios 拦截器里统一加请求头。axios.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer token; } return config; });6.5 图片上传成功但访问不到项目里如果有图片上传功能上传后数据库保存的路径经常会被人忽略。比如上传到你项目所在的static/upload目录但访问路径写的是localhost:8080/upload/xxx那就对不上。排查时先确认图片实际保存在哪里然后看后端有没有配置静态资源映射。SpringBoot 可以用如下配置把磁盘目录映射为访问路径Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file:D:/upload/); } }这类静态资源映射问题特别适合写进论文的“系统实现”部分因为能体现你对 SpringBoot 配置的掌握程度。7. 基于个人经验的一些建议这套项目我跟进过很多次也帮别人排查过不少问题。如果让我总结一句最重要的话那就是拿到源码别急着跑步先抱着数据库脚本看半天先理清模块边界再去看代码会事半功倍。很多同学卡在“不知道从哪看起”这个问题上我的建议是倒着看管理员端能操作什么 → 对应的表是什么 → 对应的接口是什么 → 前端哪个页面调用了它。这个链路走通两三个功能之后整个项目就活了。另外一个建议是一定要修改默认的 admin/123456 这类内置账号至少把密码改成自己的。虽然只是毕设但这种安全习惯越早养成越好写在论文里和放在简历里都能加分。再有就是项目跑通之后不要满足于能启动试着改一个功能比如给景点加一个“推荐”标记、给订单加一个“退款”状态这些小的改动会让你的理解深度完全不一样。最后想说的是毕设项目的价值不只是最后那一份代码和论文而是你在调试报错、搜索资料、修改功能的过程中积累起来的排查能力。哪怕你最后只是把“安康旅游网站管理平台”改成了“自己城市名 旅游平台”只要所有文案、图片、数据都换了再改一两个页面和接口逻辑它就是你自己的项目。答辩的时候能清楚讲出每个表为什么这么设计、每个状态为什么这么流转比什么华丽的辞藻都管用。
阅读完成 · 觉得有帮助？
