SpringBoot景区服务运营平台实战：从数据库设计到部署答辩全流程

每年这时候都会有人问我同一个问题：Java 毕设做旅游景点管理系统，用 SpringBoot 到底靠不靠谱？我的答案一直是——靠不靠谱不取决于题目旧不旧，而取决于你把这个 SpringBoot 景区服务运营平台的边界划在哪。划成增删改查，三个页面就能写完；划成一条完整可演示的业务链路，够你折腾一个月还乐在其中。这篇就是我用 SpringBoot 做景区服务运营平台的全过程复盘，从技术选型、数据库设计、核心链路实现，到部署打包和答辩准备的细节，全部摊开讲。适合正在做或准备做旅游景区、票务类管理系统的同学，也适合想用一个完整项目串一遍 SpringBoot 核心知识点的朋友。

我做这类项目已经不止一次了，不管是带学生做毕设，还是自己拿来练手，都踩过不少坑。这里面的坑大多不是框架本身的，而是选题理解不到位导致的——你以为你在做一个“管理系统”，其实你在做一个“业务闭环”。如果把业务闭环想清楚，SpringBoot 只是帮你把代码组织起来的工具，真正的功夫在数据表、状态流转和接口边界上。

1. 为什么我推荐用 SpringBoot 做景区服务运营平台

1.1 毕设选题与真实平台之间的差量

旅游景点管理系统这个题目，第一眼看过去很“老”，百度一搜全是增删改查。但你把“景区服务运营平台”这七个字拆开看，就知道它不止是后台管理，还包括游客端的内容展示、在线购票、订单处理、核销入园、评价反馈，以及管理端的资源维护、订单审核、数据统计。换句话说，它是一条完整的业务链，而不是一个单纯的 CRUD Demo。

我用一张表把这个题目在毕设场景和真实平台之间的差异理清楚：

做毕设的时候，我建议你把注意力放在“业务闭环”上，而不是追求高并发。因为答辩导师最关心的不是你的系统能扛多少 QPS，而是你遇到问题时能不能说清楚为什么这么设计。你把订单状态机、库存防止超卖、权限控制这条链路讲明白，项目质量已经超过大部分人了。

1.2 技术栈选型：从 SpringBoot 到配套组件的取舍

技术栈这块，我的原则是“够用、主流、可解释”。你选的每一个组件，都要能回答“为什么用它，不用别的”。

后端主框架选 SpringBoot，这个没什么好争议的。但版本要注意：如果你用的是 JDK 8，老老实实选 SpringBoot 2.7.x；如果你电脑装的是 JDK 17 或 21，再用 SpringBoot 2.x 会有一堆依赖兼容问题，建议直接用 SpringBoot 3.x。现在很多教学视频默认 JDK 8 + SpringBoot 2.x，但新版本教程越来越多，很多同学一开项目就遇到 javax 和 jakarta 的报错，后面我会专门讲这个坑。

配套组件我一般这么选：

• ORM 用 MyBatis-Plus，代码生成快，分页、条件构造器、逻辑删除都内置了，省去大量重复劳动。
• 权限认证用 Sa-Token。相比 Spring Security + JWT，Sa-Token 的 API 更直白，登录、踢人、权限校验几行代码就能写完，特别适合毕设项目。如果你要面大厂，私下再去补 Spring Security 的原理。
• 缓存用 Redis。景区验证码、热点景点统计、接口限流都能用上。答辩时 Redis 是一个非常好的加分点。
• 前端：会 Vue 就用 Vue3 + Element Plus，不会就老老实实用 Thymeleaf 服务端渲染，千万不要为了“前后端分离”这个噱头硬拆，拆出来的跨域问题能让你多耗两天。
• 定时任务用 Spring 自带的 @Scheduled 就够，处理超时未支付订单。
• 搜索用 MySQL LIKE 就行，数据量不大根本不用上 Elasticsearch，但你要能说出“如果数据量大了可以平滑迁移到 ES”这句话。

选型不是越炫越好，而是每个组件都要有它存在的理由。你用自己的话说清楚“为什么要 Redis，为什么不直接用 Map 存验证码”，比堆十个框架有用得多。

2. 核心业务模块与数据库设计：先把地基打牢

2.1 系统该拆成哪些功能模块

景区服务运营平台我通常拆成两端：游客端和管理端。游客端包含注册登录、景点列表、景点详情、票种选择、下单支付、订单查询、评论点赞、收藏、公告查看。管理端包含用户管理、景点管理、票种管理、订单管理、核销入园、评论审核、公告发布、数据统计。

很多同学上来就想着加“智慧导览”“AI 推荐”这些花活，我的建议是先把基本功做扎实。一个景点管理系统的核心是“门票卖得出去、订单对得上、库存不超卖”，你先把这三个目标实现，再来谈扩展。

管理端的数据统计也不要一开始就上图表库，先用表格把核心指标列出来：今日订单数、今日销售额、本月游客量、热门景点 Top5。后面有富余时间再去集成 ECharts。

2.2 表结构设计的几个关键点

表结构是这套系统的灵魂。我见过不少同学把所有信息塞进七八张表，看似简单，一到订单退款、库存恢复就写成一团浆糊。下面是我验证过的一版核心表结构：

这里有一个特别容易被忽略的设计：不要直接在 ticket_type 表里减库存。因为景区门票是分日期售卖的，你卖的是“8月20日的成人票”，而不是一个笼统的票种。所以我单独建了 ticket_stock 表，用 ticket_type_id + visit_date 唯一约束一段日期的库存，下单扣减的时候带上 remain_stock >= 购买数量的条件，才能从根本上防止超卖。

订单状态我推荐用整数状态机：0 待支付、1 已支付、2 已入园、3 已取消、4 已退款。不要用字符串，也不要只写注释，直接在代码里建一个 OrderStatusEnum，把状态流转规则固定下来。比如待支付可以流转到已支付或已取消，已支付可以流转到已入园或已退款，不允许跳状态。这样后面写核销接口、退款接口的时候，逻辑会清晰很多。

还有两个细节：表之间不要加物理外键，用逻辑外键加普通索引就够了，否则测试数据删除起来非常痛苦；每张表加 create_time、update_time、deleted 三个公共字段，配合 MyBatis-Plus 的自动填充和逻辑删除，实际操作会顺手很多。

2.3 查询性能与演示效果的平衡

景区列表要做分页查询。景点表、票种表的数据量在毕设阶段不会太大，但查询接口最好还是带上条件分页，避免一次性把全表数据拉出来。景点名称和描述字段加大于等于 5 的建普通索引，或者用 MySQL 的 FULLTEXT 索引做简单全文检索。你可以在答辩时说“如果数据量大，会考虑迁移到 Elasticsearch”，这句话本身就能体现你有架构意识。

另外一个很加分的点是热门景点排行。我用 Redis 的 ZSET 存储景点 id 和访问量，每次景点详情被访问时执行 ZINCRBY，排行榜接口直接从 Redis 取 Top10。这个方案实现成本很低，但能在答辩时展示你对缓存的理解。

演示数据也值得花点心思。我一般会准备 20 个景点、5 种票型、几十条订单，覆盖待支付、已支付、已入园、已退款各种状态。这样打开后端管理页面时，图表和表格不会空荡荡，演示效果立刻提升一个档次。

3. 从登录到下单：关键链路的代码实现思路

3.1 认证与权限：Sa-Token 还是 Spring Security

权限模块我推荐 Sa-Token，不是因为 Spring Security 不好，而是因为 Sa-Token 能把毕设里需要的登录、权限校验用最少的代码写出来，你能把更多时间花在业务逻辑上。

Sa-Token 的核心思路是：登录成功后在服务端生成 token，把用户会话信息存到 Redis，前端每次请求通过请求头携带 token，后端通过 StpUtil 校验登录状态并获取当前用户。登录接口大致是这样的：

java复制@PostMapping("/login")
public SaResult login(@RequestBody LoginDTO dto) {
    SysUser user = userService.getOne(new LambdaQueryWrapper<SysUser>()
            .eq(SysUser::getUsername, dto.getUsername()));
    if (user == null) {
        return SaResult.error("用户名或密码错误");
    }
    if (!BCrypt.checkpw(dto.getPassword(), user.getPassword())) {
        return SaResult.error("用户名或密码错误");
    }
    StpUtil.login(user.getId());
    return SaResult.data(StpUtil.getTokenInfo());
}

密码不要用 MD5 明文存储。现在面试和答辩都会问密码安全，MD5 已经是被淘汰的做法，我用的是 BCrypt 加盐哈希。Spring Security 里自带 BCryptPasswordEncoder，如果你只用 Sa-Token，也可以单独引入 spring-security-crypto 这个包，只用它的加密工具类。

权限控制方面，Sa-Token 支持在 Controller 方法上加 @SaCheckLogin 和 @SaCheckRole("admin")，实现游客和管理员的接口隔离。管理端登录账号在 sys_user 表里通过 role 字段区分，游客默认 role 为 user，管理员维护数据时使用独立的管理员账号。这个设计简单直接，答辩也容易解释。

3.2 景点搜索与推荐：如何合理处理关键词匹配

景点搜索是用户端一个很常见但也很容易写歪的功能。最简单的实现是用 MyBatis-Plus 的模糊查询：

java复制List<ScenicSpot> list = scenicSpotService.list(
    new LambdaQueryWrapper<ScenicSpot>()
        .like(StringUtils.hasText(keyword), ScenicSpot::getName, keyword)
        .or(StringUtils.hasText(keyword))
        .like(StringUtils.hasText(keyword), ScenicSpot::getDescription, keyword)
        .eq(ScenicSpot::getStatus, 1)
);

这段代码在数据量只有几十条时完全没问题，但你要知道它的问题：前置百分比的 LIKE 查询会让索引失效，数据量大了以后性能会掉得很快。所以答辩时不要只说“我用了模糊查询”，要补一句“当前规模下 MySQL LIKE 足够，如果后续景点数达到百万级别，会引入 Elasticsearch 或先对关键词做分词处理”。

如果你想让这个模块更亮眼，可以引入 HanLP 对搜索词做分词，把用户输入切分成 “北京 景点 门票” 这样的词项，再用每个词项去做查询条件的拼接。这个方案不会增加太多复杂度，但能体现搜索引擎的核心思路，导师听了会有印象。

推荐算法不要写复杂了。用 Redis 的热度排行，或者按评分排序、按浏览量排序就够了。你可以说“推荐策略后续可以引入协同过滤”，但项目里别真去实现，否则会失控。

3.3 购票流程与库存扣减：防止超卖的落地方案

购票链路是整个系统最核心的部分，也是最容易出 bug 的地方。流程可以拆成这几步：

1. 前端选择景点、票种、游玩日期、购票数量，提交订单。
2. 后端校验用户登录状态和参数合法性。
3. 查询对应日期的库存记录，判断剩余库存是否充足。
4. 使用乐观锁扣减库存，如果更新行数为 0，说明库存不足或已售罄。
5. 扣减成功后创建订单，状态为待支付。
6. 游客模拟支付成功后，订单状态改为已支付。
7. 定时任务扫描超过 30 分钟未支付的订单，将其置为已取消，并将库存加回来。

扣减库存的核心代码可以这样写：

java复制boolean success = ticketStockService.update(
    new LambdaUpdateWrapper<TicketStock>()
        .setSql("remain_stock = remain_stock - " + quantity)
        .eq(TicketStock::getId, stockId)
        .ge(TicketStock::getRemainStock, quantity)
);
if (!success) {
    throw new BizException("当前日期余票不足");
}

这里的关键是 setSql 里直接执行“剩余库存 = 剩余库存 - 数量”，再配合 where 条件 remain_stock >= 购买数量。这样在数据库层面就保证了不会扣成负数，比“先 select 再 update”的方式安全得多。

为什么要用这样的“乐观锁”而不是直接给整张表加锁？因为高并发下直接锁表会导致大量请求排队，接口响应时间飙升。而 UPDATE 语句自身的行锁已经能保证同一段库存不会被并发扣超，对毕设来说这个方案是最合适的。

事务和定时任务要配套好。扣库存和创建订单必须放在同一个事务方法里，任何一步失败都要回滚。定时任务可以这样写：

java复制@Scheduled(cron = "0 */1 * * * ?")
@Transactional(rollbackFor = Exception.class)
public void closeExpiredOrders() {
    List<ScenicOrder> orders = orderService.list(
        new LambdaQueryWrapper<ScenicOrder>()
            .eq(ScenicOrder::getStatus, 0)
            .lt(ScenicOrder::getCreateTime, DateUtil.offsetMinute(new Date(), -30)));
    for (ScenicOrder order : orders) {
        order.setStatus(3);
        orderService.updateById(order);
        // 恢复对应库存，需要根据订单明细处理
    }
}

有一个非常容易踩的坑：定时任务方法不要直接写在 Controller 里，也不要写在 Service 实现类的内部私有方法上，否则 @Transactional 可能不生效。我把这些定时任务单独放在一个 task 包下面，用 @Component 标注，职责清晰，也方便调试。

3.4 景点图片上传与资源映射的配置细节

景点图片上传功能看似简单，但很多同学会在这里卡一天。最典型的问题是：开发环境图片能正常显示，打包部署后图片全部 404；或者上传的图片保存在 target/classes 目录下，每次重新打包就丢了。

解决思路是不要把图片存到项目代码目录里，而是存到一个独立的本地磁盘路径，然后通过 Spring Boot 的资源映射把该路径暴露成静态资源。首先在 application.yml 里配置：

yaml复制file:
  upload-dir: /data/scenic/upload/
  url-prefix: /upload/**

spring:
  servlet:
    multipart:
      max-file-size: 20MB
      max-request-size: 100MB

然后实现一个配置类，把磁盘路径映射成 URL 访问：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Value("${file.upload-dir}")
    private String uploadDir;

    @Value("${file.url-prefix}")
    private String urlPrefix;

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler(urlPrefix)
                .addResourceLocations("file:" + uploadDir);
    }
}

上传接口用 MultipartFile 接收文件，把文件写入 uploadDir 目录，文件名用 UUID 重新生成，避免中文名和重名问题。保存成功后返回 /upload/xxx.jpg 这样的相对路径，前端在景点详情页直接拼接这个路径显示图片。这里还要注意 uploadDir 目录要提前创建并且有写入权限，否则上传时会报 FileNotFoundException。

关于大文件上传，Spring Boot 默认最多只允许 1MB 文件上传，所以我上面把 max-file-size 调整到了 20MB。如果还要支持更大的文件，比如景区宣传视频，那就建议用前端分片上传加后端合并，但毕设阶段把图片这块做好就够了，视频相关可以在答辩里提一句“后续可扩展”。

4. SpringBoot 开发中的高频坑：从版本到打包

4.1 SpringBoot 版本太高引发的 javax/jakarta 事故

SpringBoot 版本过高带来的问题，我在指导项目时几乎每周都能遇到一次。SpringBoot 3.0 之后，Java EE 的包名从 javax 迁移到了 jakarta，最典型的就是 javax.servlet 变成 jakarta.servlet。如果你在网上找的老代码里写的是 import javax.servlet.http.HttpServletRequest;，在 SpringBoot 3.x 下就会直接编译报错。

这个问题的根源不只是代码里的 import，很多第三方依赖也需要同步升级。比如某些旧版 MyBatis-Plus 不兼容 SpringBoot 3，需要换成 mybatis-plus-spring-boot3-starter；某些旧版 Shiro 不兼容 SpringBoot 3，需要换框架。

我建议你在一开始就定好版本组合，不要东一点西一点拼。下面是我验证过比较好用的组合：

如果你用的是 SpringBoot 3.x，写代码时遇到 HttpServletRequest、HttpServletResponse 这类东西，统一用 jakarta 前缀，不要再用 javax。如果你不确定当前环境支持哪个版本，最稳的方法是用 Spring Initializr 生成项目，它会自动匹配 JDK 和依赖版本。

4.2 自动装配不生效的原理与排查方法

SpringBoot 自动装配是面试和答辩都爱问的高频点。简单说，@SpringBootApplication 它本身由三个注解组成：@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan。其中 @EnableAutoConfiguration 负责去加载 META-INF 下的自动配置类，SpringBoot 3 读取的是 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports，SpringBoot 2 读取的是 META-INF/spring.factories。

很多同学遇到的问题是：自己写的配置类不生效，或者引入了某个 starter 后功能没启用。排查的方法按照优先级做这几步：

1. 确认依赖确实引入了，用 mvn dependency:tree 看依赖树。
2. 确认配置类是否被 SpringBoot 的默认扫描路径覆盖。主启动类在 com.example.demo，你的配置类在 com.example.config，默认扫描不到，需要在启动类上加 @ComponentScan。
3. 确认自动配置类是否被条件注解挡掉了。比如 @ConditionalOnProperty、@ConditionalOnMissingBean，如果条件不满足，自动配置就会跳过。
4. 确认代码里没有手动 exclude 掉某个自动配置类。

这里我要特别提醒：自定义配置类不要乱写在启动类同包外面。很多教程会建议“配置类要放在子包下”，这句话不准确。SpringBoot 默认只扫描主启动类所在包及其子包，凡是超出这个范围的类，除非显式指定 @ComponentScan，否则都不会被加载。排查这个问题的常用技巧就是看启动日志里的“Negative matches”和“Excluded auto-configuration classes”。

4.3 上传大文件和跨域问题的处理

前后端分离项目最常遇到的第二个问题是跨域。前端的地址是 http://localhost:5173，后端的地址是 http://localhost:8080，浏览器的同源策略会直接拦截请求。解决方式有很多，最省事的是在后端写一个 CORS 配置类：

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

这里有一个容易忽略的点：如果使用 allowCredentials(true)，allowedOrigins 不能写 ""，必须用 allowedOriginPatterns("")，否则浏览器会报错。跨域请求还有一个预检 OPTIONS 请求，如果你在 Spring Security 或者 Sa-Token 的拦截器里没有放行 OPTIONS，就会出现“请求已发送但后端不处理”的现象。

文件上传大小限制也属于常见坑。Spring Boot 默认限制是 1MB，如果前端上传多次表单或者大图片，会直接报 MaxUploadSizeExceededException。我在 application.yml 里已经把 max-file-size 和 max-request-size 调大了，但要注意 max-request-size 要大于 max-file-size，否则多文件上传时容易踩坑。如果连 20MB 都不够，可以考虑前端做图片压缩后再上传，或者改成分片上传。

4.4 Docker Desktop 打包部署踩坑记录

毕设做到最后，通常要把系统打包部署上线展示。本地跑通了不算完，Docker 打包这一步隐藏的坑非常多。下面是我整理后的一个多阶段构建 Dockerfile，可以同时用于 SpringBoot 3.x + JDK 17：

dockerfile复制FROM maven:3.8-openjdk-17 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline -B
COPY src ./src
RUN mvn clean package -DskipTests

FROM openjdk:17-jdk-slim
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar
ENV TZ=Asia/Shanghai
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

第一个常见的坑是容器时区。默认的 openjdk 镜像是 UTC 时区，订单创建时间、定时任务执行时间都会比北京时间慢 8 小时。我在 Dockerfile 里加了 ENV TZ=Asia/Shanghai，如果还不行，可以在启动命令里加 -Duser.timezone=Asia/Shanghai。

第二个坑是文件上传目录没挂载。容器内部的文件系统在容器删除后会丢失，所以上传的景点图片必须在启动容器时通过 -v /data/scenic/upload:/data/scenic/upload 把宿主机的目录挂载进去。我见过不少人部署后能访问页面，但一上传图片就跑不起来，最后发现是容器里没有对应目录的写入权限。

第三个坑是 Docker Desktop 在 Windows 下内存和磁盘资源默认给得不大，如果项目依赖复杂，构建时可能直接 OOM 或者构建超时。需要在 Docker Desktop 设置里把内存调大到 8GB 以上。用 Docker Compose 把 MySQL、Redis、SpringBoot 三个容器编排起来也是加分项，一条 docker-compose up -d 就能把整套环境拉起来，在论文部署章节里写这个，阅感会好很多。

5. 从开发到验收：给毕设加分的实操准备

5.1 演示数据与场景脚本的设计

很多同学到最后一步才发现，系统跑起来了，但页面空空如也，答辩时点来点去都是“暂无数据”。这个问题非常好解决，就是提前做演示数据和场景脚本。

我建议准备一份“演示脚本”，像讲故事一样走完整条链路。演示流程可以这样设计：

1. 游客注册一个账号，登录后进入景点列表页。
2. 搜索某个关键词，找到目标景点，进入详情页，看到景点图片、介绍、票种、评论。
3. 选择一个游玩日期，选择两张成人票，提交订单，模拟支付成功。
4. 在“我的订单”里看到已支付订单，点击查看订单详情。
5. 管理员登录后台，在订单管理里对这笔订单进行核销，状态变为已入园。
6. 回到数据统计页，看到今日订单数和销售额都有变化。
7. 演示超时取消：把系统时间调到 30 分钟前创建一个未支付订单，等待定时任务把它取消，库存恢复。

这份脚本不是让你死记硬背，而是帮你把模块之间的逻辑串起来。答辩时导师打断你问细节，你也不要慌，因为脚本里的每一步你都能补充实现原理。

5.2 论文里放什么图、讲什么代码

论文质量直接影响最终分数，但很多同学把论文写成“代码截图大全”，这是大忌。真正的项目论文重点应该是设计过程和关键问题的解决思路。

论文里值得放的核心图包括：功能结构图、系统架构图、数据库 E-R 图、关键流程时序图（下单流程、退票流程）、部署架构图。画图时不用追求华丽，但要保证每个图的模块名称和代码里的类名、表名能对上。

代码部分不要贴整段源码，而是挑三个核心代码块讲透：一个是登录认证的过滤器或拦截器实现，一个是库存扣减的乐观锁逻辑，一个是文件上传与资源映射配置。每个代码块配 3 到 5 句解释，说明“为什么这么写”和“解决了什么问题”，这比堆 30 页源码有用得多。

论文结构我建议按这个顺序展开：绪论（背景、意义、国内外现状）、需求分析（角色、功能需求、非功能需求）、系统设计（总体架构、功能模块设计、数据库设计、接口设计）、系统实现（分模块描述）、系统测试（功能测试用例、结果分析）、总结。这是一个标准的软件工程论文结构，按这个骨架写，逻辑不会乱。

5.3 答辩时导师最爱追问的几个问题

答辩最怕的不是不会，而是答非所问。下面是这个题目下导师最常问的几个问题，我把我自己整理的作答思路也写出来。

第一问：为什么使用 SpringBoot？它相比传统 SSM 有什么优势？作答思路是：SpringBoot 基于 SSM 封装，通过自动装配简化了配置，内嵌 Tomcat 支持独立运行，生态丰富。这时候顺便把自动装配原理讲出来，基本就能拿到这部分分数。

第二问：权限控制怎么实现的？如果你用 Sa-Token，直接说登录后服务端生成 token 存 Redis，前端请求头携带 token，通过拦截器校验登录状态，接口通过角色注解控制访问权限。要能对比一下 Sa-Token 和 JWT 的区别：JWT 无状态但不好做服务端主动失效；Sa-Token 有状态、可主动踢人，毕业设计里更可控。

第三问：库存超卖怎么解决？这个问题几乎是必考。你先把“先查库存再更新”的写法作为反例，然后引出乐观锁的做法，强调 update 语句加了 remain_stock >= quantity 的条件。如果能再说一句“生产环境可以配合 Redis 预扣库存和消息队列异步落库”，导师会认为你确实有扩展思维。

第四问：系统安全方面做了哪些措施？你可以说密码使用 BCrypt 加盐存储，文件上传做了类型和后缀校验，管理接口通过角色权限隔离，重要操作有操作日志。千万别说“我做了 SQL 防注入”，因为你用的是 MyBatis-Plus 模板参数，这本来就是预编译处理，要是能说出“MyBatis 的 #{} 是预编译占位符，可以防 SQL 注入”，就很加分。

第五问：如果并发量大了怎么办？你可以说当前项目定位是中小景区运营平台，单机部署基本够用。如果后续扩展，会在入口层使用 Nginx 做负载均衡，Redis 缓存热点数据，RabbitMQ 削峰填谷，数据库引入读写分离和分库分表。不要展开太深，但要让导师知道你理解系统瓶颈在哪。

再补充一个建议：答辩前一定要在自己的电脑上把项目从零启动一遍，把 MySQL、Redis、前端依赖、配置文件这些环境问题全部过一遍。我见过太多人答辩当天因为 Redis 没启动或者端口被占用，系统直接演示失败，前面所有努力都白费。

最后说点项目之外的东西。这套景区服务运营平台做完之后，我最大的体会是：毕设系统的价值不在功能数量，而在于你能不能把一条完整业务链路讲圆。SpringBoot 只是载体，真正帮你毕业的是你对自己系统的理解深度。如果你正在做类似的项目，建议先把订单、库存、权限这条主链路跑通，再考虑加各种花活。项目不怕小，就怕做完之后你连“为什么这样设计”都说不出来。希望这篇复盘能帮你少走点弯路，把时间和精力花在真正重要的事情上。