企业官网建设流程全解析

最近不少同学在后台问我：SpringBoot毕设到底怎么上手？尤其是像“绍兴旅游系统”这种听上去模块很多、功能很杂的项目，很多同学第一眼看到源码就懵了，不知道从哪开始跑，也不知道部署之后出了问题怎么排查。今天我就用这个经典案例，把从项目定位、功能拆解、数据库设计，到编码实现、远程调试、上线部署的完整链路全部过一遍。这篇文章不吹框架、不贴烂大街的截图，重点讲清楚每一步的“为什么”，顺带把我这几年带毕设踩过的坑、总结出的经验一块写出来。

如果你是初学者，我建议你按顺序读；如果你已经能跑通SpringBoot项目，可以直接跳到第四章看远程调试和部署那部分，那部分内容是多数教程不会细讲的。

1. 这个系统到底做什么？项目定位与核心需求拆解

1.1 旅游系统为什么成了毕设“常青树”

先别急着写代码，想清楚一个问题：为什么老师喜欢布置旅游信息系统？因为这类项目“麻雀虽小，五脏俱全”。它既要面对游客端的浏览、搜索、评论、收藏，也要覆盖管理端的景点管理、订单管理、公告发布，天然就分出了前台和后台两条业务线。你能在一套代码里同时展示“增删改查”“关联查询”“登录鉴权”“文件上传”“统计报表”这些核心技能点，而这些都是JavaWeb毕设最常考的东西。

绍兴本身又是个旅游城市，景点多、故事多（鲁迅故里、东湖、兰亭、沈园等），用真实地名做演示数据，论文里“数据来源”也说得出口，答辩时被问“为什么选这个题目”立刻就能答上。所以选题本身不算难，难的是把系统拆分成可落地的小模块，再按顺序开发。

1.2 技术选型背后的底层逻辑

Spring Boot已经是绝对主流，但“用Spring Boot怎么配持久层框架”依然是个问题。我见过太多人混用，结果自己都理不清。目前主流方案就两条：

我的建议是选择MyBatis-Plus。原因很直白：它自带BaseMapper，最基础的增删改查不用写SQL，自带分页插件，还有反向代码生成器，能帮你把实体类、Mapper接口一次性生成好。毕设阶段你省下的时间，可以用来打磨前端页面和测试用例，而不是浪费在写重复的CRUD上。

前端同样有两条路。传统方案Thymeleaf：服务器渲染，一个Controller返回一个页面，逻辑简单，不需要前后端分离，适合零基础。前后端分离Vue+Vite：后期上Element UI比较漂亮，但你要同时写两套工程，还要处理跨域、Token鉴权，工作量翻倍。我的态度是：如果你SpingBoot本身还不太熟，优先用Thymeleaf，先把业务跑通；如果确实想冲高分，就用Vue，但一定要给自己留足调试时间。

版本选择上，推荐 Spring Boot 2.7.x + JDK 8/11，这是目前兼容性最好的组合。Spring Boot 3.x强制JDK17，虽然新，但很多老教程里的配置都不适用，临时报错你查起来很痛苦。别追求版本最高，稳定才是王道。

2. 从零构建绍兴旅游系统：架构设计与数据库建模

2.1 系统分层与模块划分

拿到需求后，先把系统画成一张结构图，不用特别标准，只要能表达清楚：

旅游系统 ├─ 前台游客端 │ ├─ 注册/登录 │ ├─ 景点列表/分类筛选 │ ├─ 景点搜索（关键词） │ ├─ 景点详情 │ ├─ 发表评论 │ ├─ 收藏景点 │ └─ 旅游路线推荐 ├─ 后台管理端 │ ├─ 管理员登录 │ ├─ 景点管理（增删改查、发布状态） │ ├─ 用户管理（禁用/启用） │ ├─ 评论管理（审核/删除） │ ├─ 新闻/公告管理 │ └─ 订单/留言管理 └─ 公共模块 ├─ 统一返回结果 ├─ 全局异常处理 ├─ 登录拦截器 └─ 工具类（加密、文件存储）

代码分层就按经典三段式：Controller（控制层）→ Service（业务逻辑层）→ Mapper（数据访问层）。再加一个entity放实体类，一个dto放前端接收参数，一个vo放返回给前端的展示数据。有人觉得这也太啰嗦了，但我建议，毕设文档最后肯定有一章“系统设计”，你把包名一画，层次一写，配上一段“单一职责”的解释，这一章节就撑起来了。

2.2 数据库表设计实战

数据库是整个系统的地基，表建错了后面改起来想哭。我见过太多人把所有信息塞进一张表，结果评论、收藏、订单全部互相干扰，最后不得不推倒重来。核心表建议这样设计：

用户表sys_user

景点表scenic_spot

评论表comment

收藏表favorite：字段就是id、user_id、scenic_id、create_time，联合唯一索引别忘了。

如果还要做酒店、门票订单，再建hotel和order_record，核心是订单表里要有订单号、用户ID、商品ID、数量、金额、状态（待支付/已支付/已完成/已取消），再加一个支付时间。

设计原则我总结三条：第一，主键用自增bigint，不要用业务字段当主键；第二，价格用decimal，别用float，不然算金额会有精度问题；第三，所有记录加status状态字段，方便做逻辑删除和上下架，而不是物理删数据。物理删除一时爽，数据关联全断光，这我踩过不止一次。

3. 手把手开发核心功能：景点浏览、搜索与评论模块

3.1 搭建Spring Boot工程与核心配置

如果你用IDEA，直接New Project → Spring Initializr，Group填com.shaoxing，Artifact填buyu-travel，依赖勾选Web、MySQL Driver、MyBatis-Plus Framework、Lombok、Thymeleaf。如果是自行搭建，pom.xml核心依赖如下：

<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.28</version> <scope>runtime</scope> </dependency>

启动类什么都不用多做，@MapperScan记得加上：

@SpringBootApplication @MapperScan("com.shaoxing.travel.mapper") public class TravelApplication { public static void main(String[] args) { SpringApplication.run(TravelApplication.class, args); } }

application.yml是最容易出错的地方，直接给你一份能跑的配置：

server: port: 8080 servlet: context-path: / spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/shaoxing_travel?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: 123456 thymeleaf: cache: false mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

这里重点说两个参数。serverTimezone=Asia/Shanghai不写，Spring Boot 2.x连接MySQL 8必报时区错误；allowPublicKeyRetrieval=true是MySQL 8新驱动必须的选项，很多人卡在连接不上一晚上，就是少它。

3.2 后端接口开发实录

我们用一个典型的场景来走通整个链路：游客端分页获取景点列表 + 关键词搜索 + 点击查看详情 + 登录后发表评论。

首先写统一返回结果，否则每个接口返回的JSON格式都不一样，前端没法接：

@Data public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> success(T data) { Result<T> r = new Result<>(); r.code = 200; r.msg = "success"; r.data = data; return r; } public static <T> Result<T> error(String msg) { Result<T> r = new Result<>(); r.code = 500; r.msg = msg; return r; } }

景点Controller。注意分页参数我们直接让前端传页码和页大小，后端用Page对象接：

@RestController @RequestMapping("/api/spot") public class ScenicSpotController { @Autowired private ScenicSpotService scenicSpotService; /** 分页+关键词查询 */ @GetMapping("/page") public Result<IPage<ScenicSpot>> page( @RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(defaultValue = "8") Integer pageSize, @RequestParam(required = false) String keyword, @RequestParam(required = false) String category) { return Result.success(scenicSpotService.queryPage(pageNum, pageSize, keyword, category)); } /** 详情 */ @GetMapping("/detail/{id}") public Result<ScenicSpot> detail(@PathVariable Long id) { ScenicSpot spot = scenicSpotService.getById(id); if (spot == null) { return Result.error("景点不存在"); } return Result.success(spot); } }

ServiceImpl里的分页写法用MyBatis-Plus很简洁：

public IPage<ScenicSpot> queryPage(Integer pageNum, Integer pageSize, String keyword, String category) { LambdaQueryWrapper<ScenicSpot> wrapper = new LambdaQueryWrapper<>(); // 关键词模糊搜索，尽量用like而不是手动拼接SQL，防注入 wrapper.like(StringUtils.hasText(keyword), ScenicSpot::getName, keyword) .eq(StringUtils.hasText(category), ScenicSpot::getCategory, category) .eq(ScenicSpot::getStatus, 1) // 只查上架 .orderByDesc(ScenicSpot::getVisits); return baseMapper.selectPage(new Page<>(pageNum, pageSize), wrapper); }

看到没有，这就是为什么我用MyBatis-Plus。查询条件可以一直链式拼接，有没有某个参数就用布尔条件控制。最关键的是用了eq、like，框架帮你加参数占位符，不需要自己字符串拼接，从根上避免了SQL注入。

评论接口需要登录状态。我这里用的是简单Session方案，后端通过拦截器统一判断：

@PostMapping("/add") public Result<?> addComment(@RequestBody CommentDto dto, HttpSession session) { User user = (User) session.getAttribute("loginUser"); if (user == null) { return Result.error("请先登录"); } Comment comment = new Comment(); comment.setUserId(user.getId()); comment.setScenicId(dto.getScenicId()); comment.setContent(dto.getContent()); comment.setScore(dto.getScore()); comment.setStatus(0); // 待审核 commentService.save(comment); return Result.success(null); }

拦截器写起来不过三五十行，重头戏是preHandle里判断请求路径和Session。注意：登录、注册、景点列表页面放行，其他管理操作一律拦截。你可以把拦截器注册进WebMvcConfigurer，直接在addInterceptors里写排除规则，这样代码一眼就能看懂。

3.3 前端页面交互要点

Thymeleaf后端渲染的好处是，页面能直接用th:each遍历景点列表。打开src/main/resources/templates/index.html，核心片段长这样：

<div class="spot-grid" th:each="spot : ${spotList}"> <div class="spot-card"> <img th:src="${spot.image}" alt="封面" /> <h3 th:text="${spot.name}">景点名称</h3> <p th:text="${'¥' + #numbers.formatDecimal(spot.price, 1, 2)}">价格</p> <a th:href="@{/spot/detail/{id}(id=${spot.id})}">查看详情</a> </div> </div>

如果是Vue前后端分离，则使用axios请求/api/spot/page，渲染v-for列表。我用过两种方案，实话实说：Thymeleaf适合快速出成品，但用户交互体验比较“传统”；Vue写起来舒服，但你必须处理thymeleaf标签不生效、静态页面放在哪、CORS跨域这三个问题。推荐做法是在Spring Boot里配置CORS：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowedHeaders("*") .allowCredentials(true); } }

前端的关键不只是“显示数据”，还有状态处理。比如游客没登录就点“我要收藏”，前端要先判断session里有没有用户信息，没有就弹窗提示去登录；后端同样要拦截，这就是“前后端双重校验”。很多同学只做了后端校验，前端直接报500，页面上一堆红色报错，体验很差。至少要在前端统一封装一个axios拦截器，请求返回code不等于200的时候就toast提示。

4. 远程调试与部署上线：毕设交付前的最后一步

4.1 远程调试的正确姿势

毕设做完了，本地跑得好好的，一部署到服务器上就开始出幺蛾子：明明代码一样，接口就报错；数据库连不上；查出来的中文全是“？”。这时候你要在服务器上打日志看半天，效率太低。正确做法是使用Java远程调试。

Spring Boot应用支持JDPA协议（Java Debug Wire Protocol），启动时加一段参数就可以暴露调试端口：

java -jar -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 shaoxing-travel.jar

参数含义拆开讲：

• transport=dt_socket：通过Socket传输调试数据。
• server=y：当前应用作为调试服务器。
• suspend=n：不要启动后立刻暂停，否则App会一直卡住不响应。
• address=5005：调试端口，你可以换一个不常用的，比如5006。

然后在IDEA里配置连接：选择Run → Edit Configurations → + → Remote JVM Debug，Host填服务器IP，Port填5005，Open Debugger模式选Attach to remote JVM，IDEA一般会自动生成agent参数，你把那段替换掉上面这种也行。

配置好之后启动Debug，在本地代码里打上断点，再用浏览器访问服务器上的系统，触发对应接口，IDEA就能收到调用栈，像调试本地项目一样看变量值、观察执行路径。我其中一次排查“管理端列表接口返回数据为空”，就是靠远程调试发现服务器上的数据库配置文件里表名被改了，一条条断点跟下来很快定位到，比翻日志快十倍。

重要提醒：这个调试端口会直接暴露给网络，只建议在内网或调试阶段使用，一旦项目要长期运行，记得关闭调试参数。哪怕你云服务器的安全组只放行了8080，也最好别开5005，避免扫描风险。

4.2 打包、部署与常见问题排查

打包交付之前，先改好配置文件。数据库密码、端口这些不能硬编码在代码里，毕设可以直接写在application.yml，但你要知道自己改哪里。然后用Maven打包：

mvn clean package -DskipTests

打包完，target目录下会出现shaoxing-travel.jar。如果你用了Thymeleaf，静态页面和模板都会一起打进去，放心。

上传到服务器后，最稳妥的运行方式是：

nohup java -jar /home/app/shaoxing-travel.jar --spring.profiles.active=prod > app.log 2>&1 &

这里用nohup是为了让应用在关闭SSH会话后继续运行。生产如果你不想每次手动启停，还可以配置systemd服务，写一个/etc/systemd/system/travel.service：

[Unit] Description=Shaoxing Travel System After=network.target [Service] User=root WorkingDirectory=/home/app ExecStart=/usr/bin/java -jar /home/app/shaoxing-travel.jar ExecStop=/bin/kill -s QUIT $MAINPID Restart=always [Install] WantedBy=multi-user.target

然后执行systemctl daemon-reload && systemctl start travel即可。

部署的时候一定会碰见一堆问题，我给你列一份高频问题速查表：

这些错误有个共同点：第一次碰到都以为代码有问题，其实90%是环境配置问题。所以排查核心不是改代码，而是打开日志看清楚第一行异常。建议开发阶段把log-impl打出来，直接看SQL和异常。

4.3 源码、文档与答辩准备

现在“源码+文档+远程调试”这套毕设服务很常见，但买来的东西终究要变成你自己的。源码拿到手，先不要急着跑，按下面顺序过一遍：

1. 看pom.xml里依赖了哪些框架，版本号多少。
2. 看application.yml里的数据源、端口配置。
3. 打开数据库执行SQL，先建库再建表。
4. 打乱顺序去读代码：从启动类 → 到Controller → 到Service → 到Mapper。

搞清楚每个Mapper接口对应哪张表，每个Controller对应哪个页面，然后手动改一个功能点（比如把首页景点排序从“浏览量”改成“价格从低到高”）。你改一次系统，胜过读十遍代码，因为改的过程中你会真正碰到调用链。

论文和文档这一块，很多人头疼。我的建议是：按照“背景意义 → 可行性分析 → 需求分析 → 总体设计 → 数据库设计 → 详细设计 → 系统测试 → 总结”这个顺序写，和代码包里的模块一一对应。画图工具我推荐ProcessOn，数据库E-R图、系统用例图、活动图都能画，一份规范的E-R图能让答辩老师第一印象拉满。

答辩最容易被问这几个问题：

• Spring Boot自动装配原理是什么？
• 你对项目中的哪个功能最满意？为什么？
• 如果同时有1000个用户访问系统，怎么优化？
• 为什么选用MyBatis-Plus？

提醒一句，不要只背概念。你至少要在自己的电脑上能演示“项目从启动到登录再到订票”的完整流程。我见过有同学把代码背得滚瓜烂熟，但启动时数据库忘了开，直接翻车。答辩前三天，请每天完整启动一次项目，把关键功能走一遍。

5. 二次扩展：给这个旅游系统加Buff的几种思路

如果你的目标是拿优秀毕设，或者以后面试时想把项目亮点讲出来，光靠基础CRUD是不够的。我推荐三个性价比高的扩展方向。

**第一个是加Redis缓存。**景点列表和热门景点是高频访问数据，每次请求都打MySQL显然浪费。用Redis做缓存，热点景点可以缓存5分钟，这样既响应快，又能写进论文“缓存策略”一节。配置也不复杂，引入spring-boot-starter-data-redis，在ServiceImpl里先查缓存，命中就直接返回，没命中再查数据库并回填。

**第二个是统一文件上传。**景点图片现在都放在本地，开发时没问题，但服务器上重启就可能丢。可以把图片存到服务器某个目录，或者用云存储对象，在application.yml里配置一个自定义存储路径，再写一个上传Controller，返回图片可访问URL。注意文件类型校验和后缀白名单，不要直接接收任意文件。

**第三个是Docker部署。**能把这套系统打包成镜像，一行docker compose up -d就启动MySQL和Java应用，这在简历上就是亮点。写一个Dockerfile就几行：

FROM openjdk:8-jre COPY shaoxing-travel.jar /app/app.jar WORKDIR /app EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]

再配一个docker-compose.yml，把数据库和app两个service拉起来。但提醒你，这套配置需要Linux基础，等前面基本功能稳定了再玩，别一开始就折腾容器。

最后再分享一个小技巧：日志里埋点。在关键接口（登录、下单、评论）里加上简单的日志输出，用Spring Boot的Logger打印“谁在什么时间做了什么操作”。这个小细节，论文测试章节就有素材了，答辩还能顺带讲“系统可维护性”。你可以在登录的Service里加：

log.info("用户{}登录成功，IP：{}", username, request.getRemoteAddr());

别看这行代码简单，真正上线时它能帮你快速找回用户操作轨迹。我在实际调试中就靠这个日志发现有人批量调用评论接口，顺手加了限流。毕设不求复杂，但每个细节都体现你“真做过”，老师一眼就能看出来。