企业官网建设流程全解析

从零复刻一个东营特色景点旅游网站，还要把整个过程写成一篇能过审的论文——这是很多Java方向同学课程设计和毕业设计的真实处境。我当时选这个题目，核心原因就一个：东营的旅游资源足够独特，黄河入海口、湿地候鸟、石油工业遗存、孙子文化园，这些元素随便挑几个出来都比"通用旅游网站"有辨识度，论文里做需求分析、写系统设计时天然有内容可写。而技术侧就是标准的Java Web开发路线：Spring Boot做后端、MyBatis Plus操作数据库、前端用模板引擎渲染，难度适中，却能把Java基础、框架使用、数据库设计、论文写作全链路走一遍。这篇文章从选题逻辑聊起，把数据库设计、核心功能实现、论文撰写的完整思路，以及我实际踩过的坑全部摊开讲，打算做同类Java项目或者正在为毕业设计选题发愁的同学，可以直接参考着往下推。

1. 选题复盘：为什么是东营景点 + Java旅游网站

1.1 东营旅游资源的独特性与信息化痛点

先说选题。很多人一听"旅游网站"就觉得是烂大街的CRUD演示项目，但如果把范围限定到"东营特色景点"，整个项目的立意就不一样了。东营最核心的旅游名片是黄河入海口——河海交汇的黄色分界线、秋季的红海滩、迁徙季节的候鸟，都是全国独一份的生态景观。除了自然生态，还有两个容易被忽视的方向：一个是胜利油田衍生出来的工业旅游和石油文化资源，另一个是广饶的孙子文化旅游区，以兵圣文化和古典军事体验为主线。这三个方向各有明确的目标受众，做门户展示、做路线串联、做文化信息整合都有实实在在的内容支撑。

但我在前期调研时发现一个很矛盾的问题：东营景点的线上信息极其分散。官方旅游网站的信息更新慢，景点介绍停留在"千篇一律的百科词条"式文本；社交平台上又只有零散的游客攻略，缺少一个能把景区介绍、开放时间、票价、路线、游客评价串起来的统一入口。对做课程设计和毕设来说，这个痛点恰好是选题的金矿：既有真实的需求背景，又不会因为需求过大导致做不完。论文开头的"研究背景"和"研究意义"部分，把这些现状梳理清楚，就是一段思路非常完整的导入。

1.2 这个选题在课程设计/毕设中的角色定位

从技术难度来评估，这个项目非常适合作Java方向的课程设计或本科毕设。它不冷门，参考资料多得是；也不过分简单，核心模块覆盖了Java Web开发的几个关键层次：数据表设计、ORM框架使用、业务逻辑分层、前后端数据交互、权限控制。对学生而言，这套流程走完，Java基础、Spring Boot、MyBatis Plus、SQL这些硬技能基本都能串起来。

更重要的是，这个选题有充足的论文扩展点。比如景点检索可以引入排序算法和搜索策略，路线推荐可以做成基于热门度和地理位置组合的简单"推荐系统"，游客行为数据可以做简单的统计分析。这些点不用真做得多复杂，只要在论文里体现出"你在思考、有设计依据"，就已经比大部分模板化毕设高出不少了。我当时就是靠"结合热门度加权排序改进景点检索体验"作为创新点，把系统设计章节做厚了一些，答辩时老师明显更愿意往这个方向追问。

1.3 核心功能边界的划定

做这类系统最怕的一件事就是需求失控。旅游网站能搞的功能太多了：在线购票、酒店预订、拼团、支付、地图导航、虚拟导游……如果全往系统里塞，代码量先不说，论文里的需求分析就能把篇幅撑爆，但每个模块都浅尝辄止，答辩反而容易被问住。

我最终划定的功能边界是六块：景点展示与分类检索、景点详情页、用户注册登录、景点评论、景点收藏、旅游路线推荐。再加一个后台管理，用于维护景点数据和审核评论。这套功能集合非常"标准"：CRUD有了，关联查询有了，权限控制有了，一个接近真实落地的业务闭环也有了。而且实现难度都在可控范围内，不会出现"卡在某个技术点上一个月推进不了"的窘境。

给正在选型的同学一个建议：如果你的毕设周期只有三个月，功能模块最好控制在5到8个之间。核心功能做扎实，比堆砌十几个残废模块对你更有利。

2. 技术底座搭建：Spring Boot + MyBatis Plus的选型与踩坑

2.1 框架选型逻辑

技术选型就一句话：稳定、资料多、上手快。我当时定的是 Spring Boot 2.7.x + MyBatis Plus 3.5.x + MySQL 8.0，前端用 Thymeleaf 模板引擎加 Bootstrap 做样式。这套组合在Java课程设计和毕设里几乎是最不出错的选择。

后端框架没选Spring Cloud那套微服务，原因很简单：单机部署的单体项目用微服务架构是自找麻烦，服务拆分、注册中心、配置中心全加上，光环境配置就能消耗掉大量时间，而且答辩时老师很可能会问"你这里为什么要拆这么细"，答不上来反而扣分。Spring Boot单体应用足够优雅，自动化配置省心，内嵌Tomcat让部署也变得非常简单。持久层选MyBatis Plus而不是原生MyBatis，是因为通用Mapper和条件构造器真的能省掉大量重复的CRUD代码——对一个以业务逻辑为主的项目来说，把时间花在景点检索、评论互动这些地方比手撸每一句SQL更有价值。

前端为什么不用前后端分离？主要是考虑到项目体量。旅游门户站点以服务端渲染为主，Thymeleaf直接渲染页面，天然对搜索引擎友好，也省去了搭建前后端分离工程需要处理的跨域、接口文档、构建部署等一系列问题。Bootstrap负责快速把页面样式撑起来，写几个列表页、详情页完全够用。

2.2 环境准备：JDK多版本共存与配置陷阱

Java开发的第一步是环境，而环境问题往往是最先卡住人的地方。我记得不少同学在"java环境配置"上载过跟头，尤其是机器上已经装了多个JDK版本的情况。

我的环境用的是 JDK 8。选择 JDK 8 而不是 JDK 17，主要考虑是Spring Boot 2.7对JDK 8的支持最成熟，学校机房、老师电脑上的环境兼容性也最好，网上能找到的教程参考基本都是JDK 8为主的。如果你要用JDK 17，建议直接配Spring Boot 3.x，两者是配套的，强搭在一起版本冲突会找得你怀疑人生。

多个JDK版本共存时，核心是环境变量切换。Windows机器上，JAVA_HOME 指向哪个JDK，命令行里的 java -version 就是哪个版本。但坑也在这里：很多人改了JAVA_HOME，命令行执行 java -version 结果还是旧版本，这是因为 Path 环境变量里配置的路径比 JAVA_HOME 的优先级更高。我当时就是折腾了半天，最后把 Path 里写死的 C:\Program Files\Java\jdk1.8.0_xxx\bin 删掉，改成 %JAVA_HOME%\bin，才彻底解决。

还有一个容易被忽略的点：IDEA 里配置的 Project SDK、Project language level、Maven 的 JDK for importer 这三处要保持一致。经常出现的情况是命令行 java -version 是8，IDEA 里Project SDK却选的17，编译时用旧语法倒是没报错，但一旦用了高版本API，就会冒出 weird error，且不容易追溯到源头。

2.3 工程目录结构与配置文件的坑

工程结构按 Maven 的标准分层来，我用的包名是 com.dongying.travel，下面按 controller、service、mapper、entity、config、common 分层。这种分法本身没有技术含量，但对后面写论文帮助很大——系统设计章节里画"软件层次架构图"，直接拿包结构改一下就是一张很规范的图。

配置文件用 application.yml。第一次接触这个文件的同学最容易栽在缩进和空格上：YAML 对缩进敏感，写错一个空格，Spring Boot 启动时直接报解析错误，而且报错信息往往指向"内存溢出"或"Caused by: while scanning a directive"，包装得和真正的配置问题毫无关系，非常劝退。我当时的建议是：id 开头的前两行你都手打，不要复制网页上排版乱掉的配置文件。

多环境配置也值得一开始就做。我设置了 application-dev.yml 和 application-prod.yml 两个文件，本地开发连本地MySQL，部署到服务器时通过启动参数 --spring.profiles.active=prod 切换。这个习惯养成以后，换一份答辩演示环境会从容非常非常多。

2.4 数据库选型：MySQL还是SQL Server

数据库选型上，我的答案很明确：MySQL。安装简单、社区资料多、Navicat连接方便、MyBatis Plus对MySQL支持最完善。字符串需要支持中文和emoji时，建库显式指定 utf8mb4 字符集就行：

CREATE DATABASE dongying_travel DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

但是有一个现实情况必须提：很多学校机房或老师的演示环境还是老旧的 SQL Server 2008。如果毕设的部署环境被指定为SQL Server，连接方式就要换成 jdbc:sqlserver://localhost:1433;DatabaseName=dongying_travel，驱动依赖改用：

<dependency> <groupId>com.microsoft.sqlserver</groupId> <artifactId>sqlserverjdbc</artifactId> <version>4.2</version> </dependency>

不过SQL Server 2008的年代比较久远，JDBC驱动兼容性偶尔会出幺蛾子，而且它不支持比较新的分页写法，MyBatis Plus的分页插件性能也会受限。我的建议是：除非导师明确强制，否则优先用MySQL。

3. 数据库设计与实体类逆向工程

3.1 核心表结构设计

数据库设计是这个项目里最值得花时间的一部分。旅游网站的实体关系并不复杂，核心是"用户—景点"之间的关联关系。我最终确定了7张核心表，列一下主表的结构：

景点表里我特意设计了 hot_score 这个字段。它可以由管理员在后台手动调整，也可以通过一个定时任务根据浏览量、评论数、收藏数加权计算出来。这个字段的价值在于：排序功能不用每条请求实时去聚合统计，直接按hot_score倒序查就行，对一个小型网站来说性能完全够，代码也简洁。

另一个用心的地方是 favorite 表。如果只做"用户收藏"功能，一张表就够了，但我额外在 favorite 上加了联合唯一约束 UNIQUE KEY uk_user_scenic(user_id, scenic_id)，防止因重复点击或接口被重复调用而插入两行相同记录。这个设计在论文测试章节里是一个非常好的"异常数据处理"案例，老师问到重复提交问题时可以直接拿它来答。

3.2 MyBatis Plus实体类生成SQL的技巧

关于"根据Java实体类生成建表SQL"这件事，网上讨论非常多。实际项目里我建议分两个方向来理解，一个是正向的，一个是逆向的。

正向：先用SQL写DDL建表，然后使用MyBatis Plus的代码生成器（AutoGenerator）反推出实体类、Mapper接口、Service、Controller。这是最稳妥的做法，因为数据库字段类型、长度、索引、注释都在你手里，生成出来的实体类符合预期。代码生成器的核心配置大概是：

# 生成器配置里指定要生成的表和包名 url = jdbc:mysql://localhost:3306/dongying_travel username = root password = 123456 strategy: include: - scenic - sys_user - comment

逆向：如果你已经写好了实体类，希望自动生成CREATE TABLE语句。说实话，MyBatis Plus并没有一个开箱即用的官方组件做这件事，但实现原理很简单，就是利用JDBC的 DatabaseMetaData 或者直接反射实体类的注解拼DDL——解析 @TableName 拿到表名，解析 @TableField 拿到列名和类型，再拼上主键、长度、注释，输出SQL文本。如果你的论文需要一个"亮点"，这个自制工具类可以作为一个独立章节，展示你对注解机制和反射的掌握，比业务CRUD更能体现基础功底。

实际开发中我强烈建议采用正向流程，建表先行。实体类只是数据库的映射，让数据库来主导设计，表里数据多了以后你才会明白一个有注释、有索引、有统一命名规范的表结构有多重要。

3.3 常见实体设计误区

实体类设计有几个容易翻车的地方，我一个个说。

第一个是字段类型映射。Java和MySQL类型不是一一对应的，尤其注意 LocalDateTime 对应 datetime 类型，BigDecimal 对应 decimal，Text 类型在MyBatis Plus里默认映射为 String 没问题，但5000字以上的大文本字段如果用 varchar(255)，插入时会直接报"Data too long for column"。我当时在景点简介字段上就吃过这个亏，后来统一改成 TEXT，才解决了长文本存不进去的问题。

第二个是保留字冲突。表字段如果叫 order、desc 这类SQL保留字，写SQL的时候必须加反引号，如order。MyBatis Plus如果配置了驼峰映射，默认生成的SQL也有概率踩到。最好的规避方式就是设计表时避开保留字，例如订单日期字段直接叫 create_time，不要叫 order_date。

第三个是逻辑删除。MyBatis Plus默认逻辑删除需要给表加一个 deleted 字段，并在实体类上用 @TableLogic 注解标注，然后在配置里写：

mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

配置好之后，业务层执行 deleteById 时真正跑的是 UPDATE 语句，把 deleted 置为1。这样评论表、收藏表的"删除"操作都能保留痕迹，论文里谈数据安全性与可追溯性时这是很值得写的一笔。但注意别在关联查询里忘记加"deleted=0"的条件，如果配置没有问题，MyBatis Plus会自动帮你带上的。

4. 核心功能实现拆解

4.1 景点展示与检索：排序算法与分页落地

景点列表页是整个系统的门面，也是实现最密集的模块之一。我做的是：首页推荐热门景点、分类页按分类筛选景点、搜索页按关键字模糊匹配景点名称和简介，三个入口最终都汇聚到同一条分页查询逻辑上。

分页直接用MyBatis Plus的分页插件，配置一个拦截器：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

然后查询时传入 Page 对象和 LambdaQueryWrapper：

Page<Scenic> page = new Page<>(current, 10); LambdaQueryWrapper<Scenic> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Scenic::getCategoryId, categoryId) .eq(Scenic::getStatus, 1) .orderByDesc(Scenic::getHotScore) .orderByDesc(Scenic::getCreateTime); scenicService.page(page, wrapper);

这里有个细节值得展开讲讲，就是排序。很多人在论文里写"实现了热门景点排序"，实现方式却是 Java 代码里把所有景点查出来，然后用 Collections.sort 或者手写冒泡排序手动排一把。这种做法在小数据集上能跑，但一旦数据量上来了，全量加载 + 手动排序的效率很差。正确的思路是把排序下推到数据库，用 SQL 的 ORDER BY 完成。数据在数据库侧就排好序，再按页码取10条返回，性能完全不是一个量级。

那 Java 的排序算法到底用不用得上？其实要用的，但不是用在这个地方。比如旅游路线推荐模块里，我需要把某个分类下面的所有景点按 hot_score 和 rating 做综合加权，再筛选出前3个作为推荐路线。这个加权计算如果全部写在 SQL 里会很别扭，我就是在 Service 层查出候选景点列表后，写一个基于 Comparable 接口的排序方法，用 Collections.sort 或 stream().sorted() 按综合分值排序取前三名。论文里可以理直气壮地写"排序算法在路线推荐中的应用"，代码简单，逻辑清楚，还能引申到 Comparator 自定义排序规则。

模糊搜索也有坑。直接用 MySQL 的 LIKE '%关键字%'，由于关键字出现在开头，走不了索引，数据量一大就会扫全表。对于这个毕设级别的项目来说，数据量撑死几千条，直接 LIKE 问题不大。但如果要答好"怎么优化搜索"，可以从三个方向展开：为 name、location 字段建联合索引；搜索词做前后缀修剪；用 Redis 缓存高频搜索词结果。论文里把其中任意一个方案实现并展示测试对比，都是加分项。

4.2 用户注册登录与权限控制

用户模块我实现了注册、登录、退出、修改密码、个人中心，以及管理员后台的景点数据维护和评论审核。权限控制简化为两个角色：ROLE_ADMIN 和 ROLE_USER。

密码存储方面，有一个很多教程还在误导人的做法：用 MD5 加盐。MD5 本质上是摘要算法，暴力破解成本极低，现在随便一个彩虹表网站就能反查弱密码。我当时用的是 Spring Security 自带的 BCryptPasswordEncoder，加盐是随机的、蕴含在结果里的，每次加密的结果都不一样，安全性比 MD5 高一个档次。如果你不想把完整的 Spring Security 引入项目，只为了用密码加密，完全可以单独引入 spring-security-crypto 这个轻量级依赖，只使用 BCryptPasswordEncoder 类。

登录状态我这里选的是传统 Session 方案。为什么不用 JWT？因为我的系统是 Thymeleaf 服务端渲染，Session 天然契合，服务端可以直接控制会话生命周期，也不需要处理 token 过期刷新问题。JWT 的优势主要在于无状态、跨域、前后端分离，放在我这套架构里反而是多余的复杂度。这个选型逻辑答辩时常被问，回答好它就是展示你"比较过、权衡过"的证据。

登录校验我用的是拦截器实现。写一个 LoginInterceptor，重写 preHandle 方法，从 Session 里取登录用户，没有就重定向到登录页：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); Object user = session.getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } return true; } }

再在 WebMvcConfigurer 里注册拦截器，把需要登录才能访问的路径（收藏、评论、个人中心、后台管理）通过 addPathPatterns 和 excludePathPatterns 精确控制好。这套方案代码量很少，但能清晰展示 Spring MVC 的拦截器机制，论文里花半页配一张拦截器处理流程图，整个"系统设计"章节就活了。

4.3 评论、收藏与路线推荐：关联查询的实战训练

评论模块是典型的关联查询场景：评论表保存 user_id 和 scenic_id，前端展示时需要把用户名和头像联出来。MyBatis Plus 的简单 CRUD 做不到自动联表，我有两种写法可供选择：一是先查评论列表再批量查用户信息填回去，二是直接在 Mapper 里写自定义 SQL 做 join。我选了第二种，因为评论列表需要同时按时间排序和按热度排序，join 写法在 SQL 层直接完成排序，逻辑上更好维护。

收藏模块要解决的核心问题是"重复收藏"和"取消收藏"。我在 favorite 表上设计过联合唯一索引，所以业务代码里用一条规则就够了：用户点击收藏时先查一下记录是否存在，存在则执行删除（取消收藏），不存在则执行插入。配合唯一索引，这个操作的幂等性就有了双重保障。收藏数显示也是常见坑，直接在列表里每个景点子查询一次"count(favorite)"，N+1问题就来了。我采用的方法是：给 scenic 表加一个 favorite_count 字段，收藏成功时 UPDATE favorite_count + 1，取消时 -1。虽然引入了数据一致性维护成本，但对小项目来说收益远大于风险。

旅游路线推荐是系统里最"有想法"的功能。我没有做复杂的协同过滤，而是采用一套基于规则的热门组合策略：用户选择一个景区分类后，系统取出该分类下 hot_score 前三的景点，按"上午下午晚上"的节奏拼成一个一日游路线；如果用户选择了多个分类，就按分类权重取各分类前两名组成两日游路线。这个实现非常轻量，但完整模拟了推荐系统的核心流程——候选集构建、打分排序、TopN截取。论文里可以在这块画一个"路线生成流程图"，并把热度计算公式展开成表格，技术含量足够支撑一个章节的篇幅。

事件：收藏数扣减时别忘了先判断当前值是否大于0，防止并发场景下 favorite_count 被减成负数。加一个 SQL 层的约束：UPDATE scenic SET favorite_count = favorite_count - 1 WHERE id = ? AND favorite_count > 0，这样一个语句就能兜住边界。

5. 从项目代码到论文：论文章节安排与写作技巧

5.1 需求分析章节怎么写得有深度

论文和代码是两套体系。代码讲究实现，论文讲究"证明你想清楚了"。需求分析章节如果只写"用户可以注册登录、浏览景点、发表评论"，三行就没了，整章塌掉。要写出深度，关键是和东营场景做深度绑定。

我当时的需求分析分三层来写。第一层写用户角色分析：游客、注册用户、管理员，每种角色能干什么，用表格列清楚。第二层写功能性需求，每个模块从"功能描述、优先级、使用场景、前置条件"四个维度拆解。比如"景点检索"这个功能，使用场景是"游客想找东营境内适合亲子游的景区"，前置条件是"景区分类数据和热度数据正确维护"，这一拆下来，一个模块就能写小半页。第三层写非功能需求，从性能（页面响应时间不超过3秒）、安全（密码加密存储、后台接口防越权）、可用性（浏览器兼容、移动端适配）三个角度配数据目标。

用例图是需求分析章节的标配。可以用 StarUML 或 ProcessOn 画，角色就三个，用例控制在15个以内，不要画得密密麻麻。图下面一定要配一段文字描述核心用例流程，拿"景点收藏"举例：用户登录→进入景点详情页→点击收藏按钮→系统校验登录态→校验是否已收藏→插入收藏记录→页面反馈成功。这样一条流程写下来，老师一眼能看出你是真的做了系统而不是套模板。

5.2 系统设计章节的图与表

系统设计章节的关键是"图比字管用"。我建议至少准备四类图，按顺序排列即是：系统架构图（表现浏览器、应用服务器、数据库的分层关系）、功能模块图（树状图，展示前台后台各模块组成）、数据库ER图（画清楚7张表之间的关系）、核心业务时序图（如"用户发表评论的完整时序"）。

画架构图时我给个建议：不要放出来一大坨技术术语就完事。每个层级都要配一行文字说明，比如"Controller层：参数校验、路由映射、统一异常处理"这样。图本身说明结构，文字补充职责，答辩时老师看图提问时，你回答的逻辑就是现成的。

数据库表结构说明部分，我在正文中放了一张主表的字段说明总表，然后把每张表的建表 SQL 放进附录，正文里用一页左右讲解表间关系和几处关键设计（联合索引、逻辑删除、冗余字段）。把前面提到的 favorite 联合唯一索引、scenic 表冗余热度字段拿来做专门讲解，这一章节就不愁没内容了。

5.3 测试章节与答辩准备

系统测试章节很多人随便写几句就过了，其实这里是"论文性价比"最高的地方。我做了两类测试：功能测试和性能测试。功能测试我列了一个测试用例表格，包含用例编号、测试步骤、预期结果、实际结果、是否通过，覆盖了登录、注册、景点检索、评论、收藏、后台管理这些核心流程，大概20条左右。这个表格可以显得非常规范，实际操作时我也是真的照着用例表一项项点过去的，截图附上效果图，这一章几乎不需要额外加工。

性能测试我对两个场景做了简单压测：首页景点列表接口和搜索接口。用 JMeter 模拟50个并发用户循环请求10次，记录平均响应时间、吞吐量、错误率。压测结果和优化前对比——比如搜索接口优化前平均响应850ms，加上索引和查询优化后降到210ms——这种数据放在论文里比一百句"系统性能良好"都有说服力。

答辩准备则要兼顾项目和理论两块。项目方面要能讲清每个模块"用了什么、为什么这么选、有没有替代方案"；理论方面就是积累常问的基础题，Spring 容器的生命周期、MyBatis 的缓存机制、HashMap 底层结构、Java 内存区域划分、线程池参数含义、索引为什么能加快查询——这些代码里不直接体现但必须答得上的问题，实际就是各类 Java 面试题集里反复出现的那些知识点，可以按"八股文"清单系统过一遍。

6. 实测中遇到的几个典型问题

6.1 启动失败：端口占用与配置缩进

项目做到后期，做的功能越来越多，启动 Spring Boot 报错的频率也上来了。最常见的一种是端口占用。我本地开发用8080端口，有一次项目启动直接报 Web server failed to start. Port 8080 was already in use。排查方法是命令行执行 netstat -ano | findstr 8080，找到占用进程的 PID，然后在任务管理器结束进程。后来我学聪明了，在 application.yml 里把端口改成 8081，同时配置了 server.port=${PORT:8081} 这种环境变量优先的写法，部署到服务器时可以通过环境变量随时调整。

另一种高频启动失败原因是 yml 文件格式。Spring Boot 对 YAML 缩进非常敏感，多一个空格或少一个空格，启动时直接报解析异常。这个报错信息经常被包装成其他样子，比如提示某个配置项类型不匹配。我的排查经验是：先从最后几行错误日志往上看，找到 Caused by 那一行，基本就是配置问题的根因；然后检查 yml 里所有缩进是否一致，统一用两个空格缩进，不要混用 Tab。

6.2 IDEA编译OOM的解决路径

有同学问过一个很典型的报错：IDEA 编译时进程堆大小调整到8000还是报 java.lang.OutOfMemoryError。这个问题不是单纯调堆就能解决的。

IDEA 里编译走的是独立的编译器进程，它的堆内存设置入口在 Settings → Build, Execution, Deployment → Compiler → Build process heap size (Mbytes)，默认只有700M。如果你只改了 IDEA 自身的 vmoptions 里的 -Xmx 参数，编译进程根本不受影响。我把编译进程堆大小改成2048后，大项目编译基本不再报 OOM。还有一种情况是 Maven 构建时 OOM，那就需要调 MAVEN_OPTS：

export MAVEN_OPTS="-Xmx1024m -XX:MaxMetaspaceSize=512m"

注意 Metaspace 参数，Java 8 之后方法的元数据放在 Metaspace，默认没有上限或上限设得很高，但物理内存有限时同样会撑爆。调参的方向最好是"给编译进程足够内存但不盲目给满"，留下给系统本身和数据库的内存，才会更稳定。

6.3 数据库连接的类型与驱动坑

MySQL 8 的 JDBC 连接串里最坑的参数是时区。我第一次配置 application.yml 时：

spring: datasource: url: jdbc:mysql://localhost:3306/dongying_travel?serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8

漏了 serverTimezone，启动直接报 The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。这个报错里的乱码就是因为字符集和时区没配对。用完好的连接串后，如果还是中文乱码，检查数据库连接参数是否带了 characterEncoding=utf8，以及建表语句是否显式用了 utf8mb4。

如果学校强制用 SQL Server 2008，还有一个隐藏坑：JDBC 驱动版本不能乱选。sqljdbc4.jar 只支持到 SQL Server 2008 是比较稳妥的，新版本驱动反而可能出现 TLS 协议不兼容导致连接失败。部署到低版本 SQL Server 时，尽量用项目仓库里已有的驱动，不要想当然下载最新版。

6.4 数据一致性与事务的坑

最后讲一个很多同学容易忽视的隐蔽问题：事务失效。Spring 的事务是基于 AOP 代理实现的，有一个著名的坑——同类内部方法调用 if (this.addFavorite(...)) 这种结构时，如果 addFavorite 方法是 @Transactional，它的 this 调用绕过了代理对象，事务注解完全不生效。解决办法是把需要事务的代码抽到独立的 Service Bean 里，或者用 AspectJ 编译期织入。这个知识点在很多 Java 面试里也会问，属于"代码跑得好好的但逻辑可能不对"的经典案例。

我实际遇到的事务问题是收藏数统计不一致。前面设计过 favorite_count 冗余字段，如果收藏插入成功但 UPDATE favorite_count 失败，两者就不同步了。我的处理方案是给这两步操作包在一个事务里：

@Transactional(rollbackFor = Exception.class) public void addFavorite(Long userId, Long scenicId) { favoriteMapper.insert(new Favorite(userId, scenicId)); scenicMapper.increaseFavoriteCount(scenicId); }

rollbackFor 要显式指定 Exception.class 而不是默认的 RuntimeException，因为业务代码里可能抛出受检异常，不写的话事务不会回滚，数据照样对不上。这个是实践里总结出的经验，常规教程里很少会提醒，但踩上一次就够你查三天。

最后再分享一点个人的感触。这类 Java 旅游网站项目，代码本身并不算高难度，真正拉开差距的是把每一步都当成"可解释的设计决策"来对待。为什么用 MyBatis Plus、为什么排序下推数据库、为什么收藏计数用冗余字段，每一个"为什么"都清楚，论文写起来就是水到渠成，答辩也不会心虚。做完这个项目之后，我最大的收获反而不是 Spring Boot 的 API 用得更熟了，而是学会了一种思维方式：先想清楚边界和理由，再动手写代码。这套方法论在之后做任何系统、写任何技术方案时都一直在用。