框框框子每年毕业季都能看到一堆人抱着“超市管理系统”“员工考勤系统”这类题目，代码写得再完整，答辩评委也提不起兴趣。如果你手里正好有这个题目——SpringBoot旅游景区门票售卖微信小程序，别急着把它当成又一个平平无奇的CRUD练习。它之所以能做，恰恰是因为它把当前行业里最常被问到的几样东西都揉在了一起：小程序端、Java后端、支付流程、数据可视化，甚至还能捎带手展示一点防爬虫和接口安全的手段。这篇文章不打算给你讲怎么安装IDEA，也不从JDK配置开始啰嗦，我直接把做这个项目时要面对的决策点、业务设计和容易翻车的地方拆开讲清楚，给准备拿它当毕业设计或者练手项目的人一条能直接走通的路。完整源码在很多毕设分享社区和教学视频的配套资源里都能找到，但源码拿到手只是第一步，能讲明白为什么这样设计，才是答辩时真正值钱的部分。
1. 这个毕业设计选题为什么值得做
1.1 评委想看到的不是CRUD，而是完整的技术闭环
先说个很现实的判断标准。本科毕业设计查重、看系统、听答辩，最怕的就是“功能都对，但没有一个可以拿出来讲的技术点”。门票售卖小程序恰好能覆盖一条完整的链路：用户在微信小程序里浏览景区和票种、下单、支付，订单状态实时更新，后台根据订单数据刷新销售报表。这中间涉及微信登录鉴权、接口幂等、库存扣减、订单超时关闭、数据统计与可视化展示。往深了说，每一个点都能单独拎出来讲十分钟。
拿“库存扣减”来说，五一这种大假期景区门票瞬间被抢光是常态。如果你只写一行 UPDATE stock SET count = count - 1 WHERE id = ?，那这叫没考虑并发。要是你用了乐观锁加版本号，或者用Redis做预扣再异步落库，这就是值得写进论文里的技术方案。评委想听到的是“我遇到了什么问题、为什么这么设计、有什么取舍”，而不仅仅是“我用了什么框架”。
1.2 全栈项目对求职和考研复试都有直接帮助
这个题目的第二个好处在于，你做出来的是一个可以在简历上写明“独立开发”的真实项目。小程序端涉及原生WXML和JavaScript的页面编写，后端有SpringBoot的接口设计、MyBatis-Plus操作数据库、Redis缓存热点数据，管理端页面还能用Vue加ECharts把销售数据做得像模像样。面试官问Java、问前端、问数据库，你都能从这个项目里找到回答的素材。
哪怕是准备考研复试，老师问到你本科期间做过什么实践，你也能从“完整实现过一个售票系统，经历过订单并发和支付回调的坑”这个角度去讲。比起说“我做过课设”，这个项目的分量完全不同。
1.3 工作量和难度可控，适合个人独立完成
这点很重要。有的同学一上来就想做秒杀系统、要做推荐算法，结果连SpringBoot的自动配置原理都没搞懂，最后代码全靠复制粘贴，出了问题根本不知道从哪改起。门票售卖系统的工作量大概是这样的：
- 小程序端核心页面：首页、景区列表、门票详情、下单页、订单列表、个人中心，大约6个页面
- 后端核心模块：用户登录、景区与票种管理、订单与支付、数据统计，大约4个模块
- 管理端：登录、数据看板、订单管理、景区管理，做成简单网页即可
按照一天写3到4个小时的节奏，差不多三周能把核心功能做完，再留一周做收尾和文档。这个节奏对一个准备毕业设计的学生来说是健康的，不至于最后通宵赶工。
1.4 加分项的扩展空间很大
如果你做完了基础功能还有富余时间，有两条扩展路径性价比很高。一是接天地图或高德地图的景区导览，在景区列表页展示地理位置，甚至做路线规划；二是引入蓝牙信标的室内导览，在小程序里实现“走到某个景点附近自动播报介绍”。这两项都属于“别人没做、但你做了”的创新点，能在答辩时形成比较明显的区分度。文章后面我会把蓝牙这块单独展开一下，因为微信小程序做蓝牙开发其实没有想象中那么复杂。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型的五个关键判断
2.1 后端为什么是SpringBoot而不是SSH或SSM
很多学校的课程还在教SSM，就是Spring加SpringMVC加MyBatis。如果你问老师，他可能说SSM打基础更好。但从务实角度说，SpringBoot是现在Java服务端开发的事实标准，招Java岗的公司不会问你怎么配Spring的XML，而是问你SpringBoot的自动配置、starter机制和 actuator 监控。对于毕设来说，SpringBoot能省掉大量XML配置，让你把精力放在业务代码上，而业务逻辑才是答辩时能讲清楚的东西。
用SpringBoot写这个项目，需要你用到的核心依赖其实就这几个：
spring-boot-starter-web：处理HTTP接口mybatis-plus-boot-starter：数据访问层，自带分页插件spring-boot-starter-data-redis：做缓存和分布式锁lombok：减少实体类的样板代码jjwt或hutool：生成和校验token
不需要引入消息队列，不需要搞微服务，也不用碰Flink那类大数据组件。我在实际带项目的过程中见过一些人为了“显得高级”硬加了一堆中间件，最后代码量翻了好几倍，自己都看不完。选型的核心准则是，你引入的每个组件都要能说清楚它解决什么问题，否则就是给自己挖坑。
2.2 小程序端用原生还是uniapp
如果你只做微信小程序，我最直接的建议是：用原生小程序开发，不要上uniapp。两个原因：第一，原生小程序调试和查看文档最直接，出现问题你能立刻定位是框架问题还是业务问题；第二，微信开发者工具对原生项目的支持最完善，体验最好的演示效果自然就出来了。
但有个例外，如果你想同一个项目同时发布成微信小程序和支付宝小程序，或者你有Vue开发经验想复用组件，那可以选uniapp。这里面的取舍是：uniapp打包到微信小程序之后，有些组件样式和交互会跟你预期的不一致，你依然得懂原生小程序才能修问题。对我带过的大多数学生来说，原生学会查文档就够了，学习曲线更平缓。
2.3 关系型数据库与非关系型的搭配
MySQL是必须的。景区表、门票表、订单表、用户表、支付流水表这些都是强关系数据，需要用事务保证一致性。Redis在这个项目里不是必须的，但建议加，因为它在两个场景里作用明显：一是首页景区列表和热门门票的缓存，降低MySQL查询压力；二是库存扣减时用Redis的 decrement 命令做预扣，解决并发超卖。
数据库设计上别搞太复杂，字段够用清晰最重要。下面是我整理的一套核心表结构，可以拿来直接用：
sql复制-- 景区表
CREATE TABLE scenic_spot (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100) NOT NULL COMMENT '景区名称',
description TEXT COMMENT '景区介绍',
address VARCHAR(255) COMMENT '地址',
cover_url VARCHAR(255) COMMENT '封面图',
status TINYINT DEFAULT 1 COMMENT '1上架 0下架',
create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);
-- 门票类型表
CREATE TABLE ticket_type (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
scenic_id BIGINT NOT NULL COMMENT '所属景区',
type_name VARCHAR(50) NOT NULL COMMENT '票种名称，如成人票/学生票',
price DECIMAL(10,2) NOT NULL,
stock INT NOT NULL COMMENT '库存',
version INT DEFAULT 0 COMMENT '乐观锁版本号',
create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);
-- 订单表
CREATE TABLE orders (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
order_no VARCHAR(32) NOT NULL UNIQUE COMMENT '订单号',
user_id BIGINT NOT NULL COMMENT '下单用户',
ticket_id BIGINT NOT NULL,
scenic_id BIGINT NOT NULL,
quantity INT NOT NULL COMMENT '购买数量',
total_amount DECIMAL(10,2) NOT NULL,
status TINYINT NOT NULL COMMENT '0待支付 1已支付 2已使用 3已取消 4已退款',
expire_time DATETIME COMMENT '待支付订单过期时间',
pay_time DATETIME COMMENT '支付时间',
create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
KEY idx_user_id (user_id),
KEY idx_scenic_id (scenic_id)
);
-- 支付流水表
CREATE TABLE payment_record (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
order_no VARCHAR(32) NOT NULL,
transaction_id VARCHAR(64) COMMENT '微信支付交易号',
pay_amount DECIMAL(10,2) NOT NULL,
pay_status TINYINT NOT NULL COMMENT '1成功 0失败',
callback_time DATETIME COMMENT '回调时间',
create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);
这个结构里门票表加了 version 字段做乐观锁，订单表用 order_no 做唯一键配合幂等，都属于能在答辩时主动讲出来的细节。
2.4 数据可视化工具的选择
管理端的数据看板是这个项目的鲜明加分项。我推荐直接用ECharts，原因是它上手快、中文文档全、社区例子多。你不需要自己从零画图表，照着官方示例改数据格式就行。在这个项目里真正有价值的几张图是：门票日销量折线图、景区门票收入占比饼图、热门景区排行榜柱状图。这三张图做完，整个管理端看板的完整度就不一样了。
2.5 部署方式不求花哨，但求稳定
别一上来就搞Docker、搞Kubernetes，那是给自己找事。一台云服务器或者本地虚拟机，装好JDK和MySQL，把SpringBoot打成jar包运行，小程序端开发时用微信开发者工具的“不校验合法域名”选项把请求指向你的IP加端口，整套环境就能跑通。演示时候如果怕网络不稳定，本地部署一套最稳妥。
3. 门票售卖系统的核心业务设计与数据库建模
3.1 从用户视角梳理业务流程
做任何系统，先画清楚用户路径，再谈代码。这个项目的核心流程可以拆成几条：
- 游客打开小程序，浏览首页景区列表，点进门票详情，选择票种和数量，下单，微信支付，收到电子凭证，到景区核销
- 用户查看自己的订单列表，看到待支付订单可以继续支付或者取消，已支付订单可以查看凭证码
- 管理员登录后台，查看销售数据看板，管理景区和票种的上架下架信息，处理退款请求
这条主链路看起来简单，但真正落地时会遇到几个隐藏问题：用户支付后微信回调没有及时到达怎么办、订单超过15分钟没支付要不要自动关闭、用户同一时间下单同一张票会不会把库存扣成负数。这些都是业务设计的核心矛盾点。
3.2 订单状态机设计
实体类的状态字段绝不能随便定义，一定要用状态机去约束状态流转。以订单为例，我的设计是：
| 状态值 | 含义 | 允许流转到 |
|---|---|---|
| 0 | 待支付 | 1（支付成功）、3（取消） |
| 1 | 已支付 | 2（已使用）、4（已退款） |
| 2 | 已使用 | 无 |
| 3 | 已取消 | 无 |
| 4 | 已退款 | 无 |
之所以这样设计，是为了防止代码里出现“从已取消跳到已支付”这种非法状态变化。实现上可以写一个状态机工具类，或者至少在每个更新状态的Service方法里先做状态校验，不要直接在Mapper层裸更新。
3.3 库存扣减的两种方案对比
库存扣减是这类交易系统必考题目。我先说暴力做法：代码里先查库存，判断足够再执行更新。并发一上来，两个请求同时查到库存剩1，都以为够卖，最后库存变成负数，这就叫超卖。
解决办法有两个思路。第一个是乐观锁：
java复制@Update("UPDATE ticket_type SET stock = stock - #{quantity}, version = version + 1 WHERE id = #{ticketId} AND stock >= #{quantity} AND version = #{version}")
int deductStock(@Param("ticketId") Long ticketId,
@Param("quantity") Integer quantity,
@Param("version") Integer version);
更新行数等于0说明扣减失败，抛异常或者提示用户“手慢了，票已被抢完”。这个方案适合库存量没那么大、并发量可控的场景，胜在实现简单，不依赖额外组件。
第二个是Redis预扣。提前把库存加载到Redis里，下单时 decrby，支付失败或订单取消时 incrby 回补。但这里有个坑：Redis里的库存和MySQL里的库存怎么保持一致？我在项目里的做法是先用Redis做扣减，然后用MQ或者定时任务异步把订单落库，同时更新MySQL库存。对于毕设项目，没有消息队列时可以用Spring的 @Scheduled 定时同步，虽然有一定延迟，但足够应付演示场景。
3.4 待支付订单的关闭策略
门票这种商品时效性强，用户下单15到30分钟内不支付，理论上就应该关闭订单把库存释放掉，不然库存一直被无效订单占着。
实现方式有两种：一是用户再次查看订单时判断 expire_time 是否已过，过了直接改成取消状态，这叫懒关闭；二是后台用定时任务每30秒扫一次超时订单，批量关闭，这叫定时关闭。演示场景下用懒关闭就能应付，因为用户大概率会在订单列表页看到超时状态，触发更新逻辑。但如果你想答辩时候多讲一点，可以两种都写上，说明各自的使用场景。
4. 后端接口的三个硬骨头：防刷、幂等与行级权限
4.1 Controller层怎么防爬虫
做小程序最怕什么？接口被爬虫或脚本刷，导致库存数据混乱、短信接口被恶意调用、服务器流量被刷爆。尤其是门票价格和库存这类数据，被竞对爬走是常有的事。所以我强烈建议在接口设计中把防刷考虑进去，这也是热词里“java controller层如何防护防止爬虫”指向的核心问题。
先说最基础的方案。在后端写一个拦截器，对所有接口做IP维度的频控：
java复制@Component
public class RateLimitInterceptor implements HandlerInterceptor {
private static final long LIMIT = 100; // 每分钟最大请求数
private final Cache<String, Long> counter = CacheBuilder.newBuilder()
.expireAfterWrite(1, TimeUnit.MINUTES).build();
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
String ip = getClientIp(request);
Long count = counter.getIfPresent(ip);
if (count != null && count > LIMIT) {
response.setStatus(429);
response.setContentType("application/json;charset=UTF-8");
response.getWriter().write("{\"code\":429,\"msg\":\"请求过于频繁\"}");
return false;
}
counter.put(ip, count == null ? 1 : count + 1);
return true;
}
}
这里的思路是内存版滑动窗口，按IP限流。但光限IP不够，同一台手机换网络IP就能绕过，所以更稳妥的办法是结合用户维度限制：登录用户按 userId 限流，未登录用户只能访问极少量的公开查询接口。
高阶一点的做法是给接口加 sign 签名校验。小程序端将请求参数加上一个秘钥做MD5，后端用同样的秘钥重新计算，不一致就拒绝请求。这样爬虫即使拿到参数也不知道签名算法，伪造请求的难度大增。需要强调的是，签名只能增加爬取成本，不能完全阻止，真实业务里还要配合验证码、风控策略等多层手段。
4.2 下单接口的幂等处理
用户在下单页点了“提交订单”没反应，又点了一下，结果生成了两笔订单，这是线上事故。解决思路是引入幂等键：小程序端在下单前先生成一个 client_token（比如UUID），下单请求把这个值带给后端，后端在生成订单前先查这个幂等键是否已经存在，存在就直接返回已有订单。
落库层面还应该靠数据库的唯一索引兜底。我在前面表结构里把 order_no 设成了唯一键，同一客户端的多次提交最终只有一笔订单能插入成功，其余的都触发约束异常，程序捕获后返回“订单已提交，请勿重复操作”。这个设计讲出来，就是很好的答辩素材。
支付回调也有幂等问题。微信支付服务器可能因为网络重试给你同一个支付结果回调两次，如果你的回调逻辑不是幂等的，就可能出现订单被重复置为已支付、用户积分重复发放的情况。处理办法是在 payment_record 表里用 transaction_id 做唯一约束，处理前先查流水是否存在。
4.3 行级权限：用户只能看到自己的数据
很多人在写订单查询接口时直接这样：
java复制@GetMapping("/list")
public Result list(@RequestParam Long userId) {
return Result.success(orderService.listByUser(userId));
}
后台管理系统的角色最好是真实存在的，我给的例子是：用户端订单查询接口根本不接受前端传来的userId，token校验通过后从当前登录上下文里取。可以用 ThreadLocal 配合 HandlerInterceptor 维护一个当前登录用户上下文：
java复制public class UserContext {
private static final ThreadLocal<Long> HOLDER = new ThreadLocal<>();
public static void setUserId(Long userId) { HOLDER.set(userId); }
public static Long getUserId() { return HOLDER.get(); }
public static void clear() { HOLDER.remove(); }
}
然后订单接口只需要写：
java复制@GetMapping("/list")
public Result list(@RequestParam(defaultValue = "1") Integer page) {
Long userId = UserContext.getUserId();
return Result.success(orderService.pageByUser(userId, page));
}
这样即使有人恶意传别人的 userId 也查不出数据，因为查询条件永远来自登录态，而不是请求参数。这个就叫行级权限控制，回答“如何防止越权访问”时非常好用。
4.4 微信登录态与token有效期设计
小程序端调用 wx.login() 拿到临时 code，后端拿着 code 去微信接口换 openid 和 session_key，这是标准流程。但这中间有几个容易踩的细节：后端换到 openid 后不能用它做用户登录凭证直接返回给前端，因为 openid 是用户的永久标识，泄露了不安全。正确做法是把 openid 存在服务端，用自己的token体系维持会话。
我在这个项目里的做法是，用户表里存 openid，登录成功后用 userId 生成JWT，过期时间设为7天。小程序端每次请求在请求头带 Authorization: Bearer <token>，后端拦截器校验token并解析出 userId，放入 UserContext。
还需要注意token续期问题。用户连续用了一个星期后token过期，突然要求重新登录，体验很差。我用的是双token方案：access_token 有效期短但用来请求业务接口，refresh_token 有效期长用来换取新的access_token。当然答辩时你只做单token也可以，只要把利弊讲清楚就行。
5. 小程序端最容易翻车的三个细节
5.1 顶部导航栏高度适配
小程序开发中不少人被顶部导航栏坑过，安卓和iPhone的刘海屏、胶囊按钮高度不一样，用固定 navigationBarHeight 写死会导致内容被遮挡或间距不协调。正确做法是用微信提供的 wx.getWindowInfo() 或 wx.getMenuButtonBoundingClientRect() 动态获取胶囊按钮位置和状态栏高度，然后计算导航栏实际高度。
javascript复制const windowInfo = wx.getWindowInfo();
const menuButton = wx.getMenuButtonBoundingClientRect();
const navBarHeight = (menuButton.top - windowInfo.statusBarHeight) * 2 + menuButton.height;
const statusBarHeight = windowInfo.statusBarHeight;
把这两个值放到全局数据里，页面顶部留白就统一了。这个细节虽然小，但很影响演示观感，毕竟答辩评委用的手机屏幕不一定和你一样。
5.2 列表页面的加载更多
门票或景区列表页数据量一大，一次性全查回来体验很差。标准的“下拉刷新、触底加载更多”逻辑，很多新手会写错，核心问题是分页参数的维护。我的写法是：
javascript复制Page({
data: {
list: [],
page: 1,
pageSize: 10,
hasMore: true,
loading: false
},
onReachBottom() {
if (this.data.hasMore && !this.data.loading) {
this.setData({ page: this.data.page + 1 }, () => this.fetchList());
}
},
async fetchList() {
if (this.data.loading) return;
this.setData({ loading: true });
const res = await request.get('/scenic/list', { page: this.data.page, pageSize: this.data.pageSize });
const list = this.data.page === 1 ? res.data.records : this.data.list.concat(res.data.records);
this.setData({ list, hasMore: res.data.records.length > 0, loading: false });
}
});
这里一个容易忽略的问题：如果第一页返回的条数小于pageSize，说明没有更多数据了，可以把 hasMore 置为false。不然用户一直往上滑，你一直在发空请求，白白消耗流量。
5.3 支付流程与订单倒计时
支付倒计时要在前端展示，但过期关闭逻辑一定要以后端为准。我的做法是下单接口返回 expireTime，前端用这个时间做倒计时显示；倒计时归零时前端跳转订单列表并提示“订单已超时关闭”。同时后端在查询订单和调用支付时都会判断订单当前状态，双保险避免前端绕过倒计时直接发起支付。
这里还要注意一点：微信支付需要 wx.requestPayment，参数里的 timeStamp、nonceStr、package、signType、paySign 全部由后端生成并返回，前端不要自己拼。我在测试阶段经常看到一个错误——时间戳用了字符串但格式不对，导致支付拉起失败。这个排错时可以用微信开发者工具里的调试面板查看完整的支付参数，逐项比对。
5.4 小程序端请求域名和调试工具的使用
在开发阶段，微信开发者工具默认不允许请求不合法域名，你需要勾选“不校验合法域名”才能在本地调试接口。但注意这只是在工具里生效，真机预览时必须把后端域名配置到微信公众平台的小程序后台，并完成ICP备案，才能正常请求。如果你本地演示用手机预览，必须保证手机和电脑连同一个局域网，后端服务的端口保持运行，请求地址写电脑的局域网IP。
在排查接口问题时，一个很好用的工具是Charles。它的原理是在PC上启动一个本地代理，然后把小程序的请求指到代理端口，就能在PC上看到小程序发出的每一个HTTP请求的URL、Header、RequestBody和ResponseBody。当年我排查一个支付回调问题，就是靠Charles抓到微信服务器回调的具体报文才定位到参数名配错了。使用Charles时的几个基本步骤：打开SSL Proxying设置、手机WiFi代理指向PC的IP和8888端口、安装并信任Charles根证书。配置好以后你就能像看浏览器开发者工具一样看小程序的网络请求，定位是前端参数问题还是后端返回问题，效率高很多。
6. 数据可视化与运营看板：让答辩有明显亮点
6.1 图表服务于决策，不是为了炫技
管理端的看板页面，不少学生喜欢铺一堆图表，什么图都往上堆，结果评委问“这张图说明了什么”答不上来。我的建议是三张图加一组核心指标数字，每张图都能说清楚业务含义：
- 近7日门票销售趋势折线图：看出销量波动，配合景区活动解释波峰出现原因
- 各景区收入占比饼图：反映哪几个景区是主力营收来源
- 门票分类销售排行榜柱状图：看出成人票、学生票、家庭套票的实际售卖比例，指导后续定价策略
上面再放今天销售额、今日订单量、待支付订单数、总库存余量这四个数字卡片。信息量足够支撑一段有逻辑的运营分析，答辩时可以顺着图表讲数据背后的业务故事。
6.2 ECharts接入后端数据的完整链路
管理端假设用Vue加ECharts，你需要设计几个统计接口。我用得最多的是一个综合统计接口，返回一天内各个维度的数据：
java复制@GetMapping("/admin/dashboard")
public Result dashboard() {
Map<String, Object> result = new HashMap<>();
result.put("todaySaleAmount", orderService.sumTodayAmount());
result.put("todayOrderCount", orderService.countTodayOrders());
result.put("sevenDayTrend", orderService.sevenDayTrend());
result.put("scenicIncomeRatio", orderService.scenicIncomeRatio());
result.put("ticketTypeRank", orderService.ticketTypeRank());
return Result.success(result);
}
前端拿到数据以后，折线图和饼图的配置项直接参考ECharts官方示例改。有一点写论文时需要注意：图表纵轴和横轴的单位必须标注清楚，金额要带币种，日期要带范围。很多人的图表被挑毛病，不是数据错了，而是轴标签和单位缺失，显得不严谨。
6.3 演示数据生成器：让图表看起来更真实
新系统刚上线没订单，后台看板空荡荡的，论文截图不好看。你可以写一个模拟数据生成器，随机生成过去30天的订单数据，生成时控制在合理范围内，比如周末销量比工作日高、五一这类节假日前一周开始预售量上升。用 java.time 生成日期，用 ThreadLocalRandom 生成订单数，然后批量插入数据库。
这里我必须提一句合规问题：模拟数据只能用于系统演示和论文写作，如果你拿真实景区的名字和真实价格做数据，但实际并未与该景区合作，论文里要明确写清楚“演示数据为模拟生成，用于功能验证”。这样既诚实也安全。用模拟数据填充时注意不要影响真实订单统计，可以在景区表加一个 is_demo 字段，统计SQL里过滤掉演示数据。
6.4 地图类可视化可选方案
如果想让管理端看板更有格调，可以引入天地图或高德地图的JS API，用散点图把各个景区的订单量标记在地图上，点的颜色和大小对应销量高低。这个实现不复杂：地图组件加载后，把景区经纬度和销量数据绑定到Marker上，再用ECharts的scatter图层和地图底层叠加。项目里考虑过接入天地图微信小程序SDK，把景区位置展示做到小程序端，实测下来在真机上运行稳定，坐标拾取也很方便。
7. 搭建部署过程中实测踩过的坑
7.1 SpringBoot版本过高导致的配置不兼容
前两年Spring Boot 3.0刚出的时候，很多人图新鲜直接上了最新版本，结果发现3.0基于Jakarta命名空间，原来 javax.servlet 的依赖全部要换，MyBatis-Plus的旧版本又不兼容。我带的项目里有人被这个卡了整整两天。
我的建议是：毕业设计不要追求版本最新。SpringBoot 2.7.x版本稳定、资料多、兼容性好，网上搜到的问题都能找到对应答案。如果你确实要用SpringBoot 3.x，那就要做好以下心理准备：javax换成jakarta、MyBatis-Plus要用3.5.3以上、部分配置文件写法变了、老教程的代码粘贴过来可能直接编译不过。不是不能用，是成本更高，你要判断自己有没有时间去填这些坑。等到开发完核心业务，还有余力再升级版本，那才算有意义的尝鲜。
7.2 小程序端真机预览时的常见问题
真机调试无线调试时报错 “request:fail url not in domain list”，十有八九是域名白名单没配上。现场演示最保险的做法是提前把域名在小程序后台配好，并把后端部署到有公网IP的服务器上。如果只有本地环境，那就让手机和电脑连同一个WiFi，请求地址写电脑的局域网IP，同时勾选开发者工具里的“不校验合法域名”。这个方法只能在开发版小程序里用，体验版和正式版都会拦请求。
另一个我在现场见过的问题：手机演示连不上后端，检查发现Windows防火墙把8080端口拦了。处理方法是提前在防火墙里放行对应端口，或者直接在命令行临时关闭防火墙（注意这是开发环境做法，生产环境不要这么干）。
7.3 Maven构建和打jar包
项目快完成的时候，你可能会想把它部署到服务器上演示。Maven打包的命令要写对：
bash复制mvn clean package -DskipTests
打出来的jar包在target目录下，用 java -jar xxx.jar 就能启动。这里常遇到两个问题：一是打包后配置文件里的数据库连接还是本地地址，到了服务器上连不上，需要把数据库连接信息改成服务器的；二是上传到服务器跑起来后发现静态资源访问不到，检查是不是没把前端打包后的dist文件放到SpringBoot的 src/main/resources/static 下面。
如果你采用了前后端分离，Vue项目打包后的 dist 目录内容可以直接复制到SpringBoot的 static 目录，这样后端发布一个jar包就能托管管理端页面，免去单独部署Nginx的麻烦，对演示场景来说够用了。
7.4 答辩演示的防翻车清单
最后一条经验，出于我在答辩现场看到过足够多的“演示翻车”，给你一份简单但有效的检查清单：
- 提前把后端服务启动，数据库确认连接上，Redis确认启动
- 手机微信小程序打开后，先把首页的图片、列表都刷一遍，确保网络通畅
- 准备一个备用网络方案，比如手机热点，以防演示现场WiFi出问题
- 展示支付环节时预先准备好一个测试用的微信支付商户号，或者提前构造一个“已支付”状态的演示订单，避免大屏现场等待支付回调
- 真机预览时手机调成勿扰模式，防止来电打断演示
这些看起来琐碎，但关键时刻可以避免你在台上对着白屏手足无措，同时给评委留下一个“这学生做事靠谱”的印象。
8. 完整源码获取与后续扩展方向
如果你现在决定做这个题目，想找一套结构清晰、可扩展的参考代码，不妨从GitHub、码云以及一些计算机毕设资源社区里搜索“SpringBoot 微信小程序 景区门票”。拿到源码后你要做的第一件事不是跑起来，而是花两天时间通读代码结构，理清控制层、服务层、数据访问层的划分逻辑，把每个依赖的用途搞明白，再对照本文讲的订单状态机、库存扣减、token校验这几个关键点去验证代码确实实现了。只有你自己能讲清楚每一步为什么这么写，这套代码才真正属于你。
后面如果还想让它变得更有竞争力，有两条我非常推荐的路：一是给用户增加一个“年卡会员”体系，用户购买年卡后预约入园时间，后端用定时任务统计每日预约人数、控制承载量，这个需求在真实景区很常见；二是完善退改签流程，把部分退票、改签到不同日期的逻辑做成状态机的一部分，复杂度上来了但技术含金量也上来了。这两条路跟现有的门票模块衔接都比较顺畅，工作量在一个可控范围内。
回到最初那个问题，这个题目的价值不是它名字里有“SpringBoot”和“小程序”，而是它迫使你把一个真实业务完整地走了一遍：从数据库建模到接口设计，从小程序交互到支付回调，从库存并发到数据可视化。这套经验哪怕以后不做旅游行业，放到任何一套交易类系统里照样适用。希望这篇文章能把你的思路理清，少走我认为可以避开的弯路。有具体卡住的地方，欢迎在评论里把你的报错信息发出来，我可以顺着你的实际问题再写一篇排查记录。