最近不少朋友找我要一套“能直接演示、能写进简历、又不会太复杂”的项目源码，Spring Boot 做的“线上线下动物园管理系统”是我经常推的一套。项目归档编号 61317，说白了就是个版本标记，不用过度解读。这类系统的需求量一直不小：高校课设、毕设、培训班综合实战，甚至一些中小型园区做数字化改造的轻量原型，都会拿 Spring Boot + 管理后台 + 游客端这套组合来打底。它和那种纯 CRUD 的“动物园信息登记表”最大的区别，就在“线上线下”这四个字上——游客在小程序或 H5 页面完成注册、购票、预约、查看动物科普，到园区后凭二维码入园；运营人员在后台维护动物档案、上架票种、核销门票、看经营数据。整个系统涉及库存扣减、订单状态流转、二维码防伪、接口幂等等一堆真实业务问题，用来练手和学习“企业级开发套路”，性价比非常高。

1. 项目定位：线上线下结合的动物园管理该怎么拆

1.1 这个系统到底在解决什么问题

我见过不少号称“某某管理系统”的项目，点开一看就是一张表的增删改查，页面倒挺多，业务逻辑等于零。这个动物园管理系统有意思的地方在于，它把“线上”和“线下”两条业务链路真实地串起来了。线上链路是游客端完成的：注册登录 -> 浏览动物和票种 -> 下单支付 -> 收到电子票二维码 -> 到园区门口出示二维码。线下链路是运营端完成的：检票人员登录核销界面 -> 扫描游客二维码 -> 校验订单是否有效 -> 标记已使用 -> 放行入园。游客在园区里还能扫码查看动物语音介绍、参与科普答题，这部分又和线上内容联动起来。

这两条链路对应的是两个完全不同的用户视角。线上面对的是 C 端游客，交互要轻、流程要短、下单要顺畅，页面挂了体验极差；线下面对的是运营人员，操作要快、状态要明确、异常情况要有兜底，比如二维码失效、重复扫码、网络中断，都得有明确提示。所以这个系统在架构上不能做成一张大表，而是要把用户、票务、核销、内容拆成相互独立的模块，再用订单号和二维码把线上和线下串起来。

需求分析可以用一张表格快速理清：

1.2 三类角色与三大核心流程

这个系统最典型的角色有三种：游客、运营/票务人员、系统管理员。游客的诉求很简单——快速买到票、入园不排队、能看点有意思的内容；运营人员的诉求是——今天卖了多少票、核销了多少人、哪只动物最受欢迎；系统管理员则要维护整个系统的基础数据：用户、动物、公告、票种配置。

围绕这三个角色，核心流程可以归纳成三段：

1. 购票预约流程：游客选择票种 -> 填写日期和人数 -> 创建待支付订单 -> 模拟支付或对接第三方支付 -> 支付成功后生成电子票二维码。
2. 入园核销流程：游客出示二维码 -> 检票员扫码 -> 系统校验签名和订单状态 -> 核销成功并记录入场时间 -> 游客入园。
3. 内容互动流程：游客进入动物详情页 -> 查看图文和语音讲解 -> 参与科普问答 -> 获得积分 -> 积分可在个人中心查看。

这三个流程里，购票和核销是强业务逻辑，内容互动是体验差异化。很多开发者在做这个项目时只关注了第一个流程，把订单表做得很完整，但核销流程直接跳过了，或者只是手动把订单状态改成“已入园”，这就丧失了这个项目最有价值的亮点。面试时被问“线上线下一体化怎么实现的”，你如果答不出二维码核销和防重复入园的设计，项目含金量会大打折扣。

1.3 “线上线下”不是噱头，而是业务流程的闭环

有人会问：直接做一个线上售票系统，再配一个后台管理系统不就行了吗？为什么非要强调“线上线下”？关键点在于数据闭环。线上购票量、支付金额、用户浏览行为、动物点击量，这些数据最终都要汇聚到管理后台的报表里，支撑运营决策。比如某只动物详情页点击率很高，但对应的线下展区排队人数很多，运营就可以通过后台数据发现“科普内容吸引人但展区承载不足”，从而引导游客错峰游览。又比如某天线上售票 500 张，但实际核销只有 300 人，说明游客爽约率挺高，需要设计预约提醒或改签机制。这些分析都依赖“线上行为数据”和“线下核销数据”打通后的同一份报表。

所以我在搭建这个项目时，特意把“订单表”“核销记录表”“动物浏览记录表”都设计成独立的、可被统计的明细表，而不是简单地在订单表上加几个状态字段。这样既方便业务扩展，也为后面做数据大屏和经营分析预留了空间。这个设计思路，比单纯写几个接口更能体现你对业务的理解。

2. 技术选型与整体架构：为什么非 Spring Boot 不可

2.1 Spring Boot 在中小型管理系统里的统治力

做这类管理系统，技术选型其实没有太多悬念。Spring Boot 几乎是当前 Java 后端入门和中小型项目的标准答案。它把 Spring 家族里繁琐的 XML 配置基本干掉了，内置 Tomcat，打成一个 jar 包就能跑，配合 Maven 管理依赖，新手也能很快把环境拉起来。相比传统的 SSM，Spring Boot 的核心价值不是“功能更多”，而是“少写配置、快速集成”。这一点在项目实战中的体感差异非常明显，我把主要依赖往 pom.xml 里一放，写几个 starter，数据库连接、参数校验、JSON 序列化这些基础设施基本就齐了。

版本选择上建议用 2.7.x 系列，搭配 JDK 8 或 11。虽然 Spring Boot 3.x 已经普及，但很多高校和培训机构的课件还是基于 2.x，而且 2.7 的生态成熟，网上资料多，遇到问题很容易搜到答案。如果你是非科班转行或者刚开始做毕设，没必要追新版本，稳定压倒一切。我见过有人拿着 Spring Boot 3.2 写课设，结果 MyBatis-Plus 版本不兼容，折腾一晚上环境，这种时间成本完全不值得。

2.2 分层架构与代码组织方式

这个系统我推荐标准的 Controller -> Service -> Mapper 三层架构，再加一层 entity 放实体、dto/vo 放传输对象、config 放配置类、common 放统一返回体和异常处理。模块拆分上，按照业务领域划分包，而不是按技术类型堆在一起。比如：

com.zoo.manage ├── controller # 接口层：游客端、管理端分开 ├── service # 业务层：接口 + 实现 ├── mapper # 数据访问层 ├── entity # 数据库实体 ├── dto # 入参出参对象 ├── vo # 页面展示对象 ├── config # 配置类：Redis、拦截器、WebMvc ├── common # 统一返回体、异常、工具类 ├── utils # 二维码、JWT、日期工具 └── task # 定时任务：过期订单关单

为什么要强调这个分层？因为很多初学者喜欢把业务逻辑写在 Controller 里，一个方法几百行，接口一多就乱成一锅粥。分层的好处不只是“规范”，更重要的是可测试、可复用。比如订单过期关闭这个逻辑，既可以被定时任务调用，也可以在用户查询订单时懒触发，写在 Service 里就很自然。Controller 只负责参数接收和结果包装，业务判断全部下沉到 Service，这才符合真实项目里的协作习惯。

2.3 数据库设计：关键表与核心字段

数据库是这类系统的灵魂。我建议至少设计以下核心表：

订单状态是业务的核心，我通常用整数类型存状态码，配合状态机流转：0 待支付、1 已支付、2 已核销、3 已过期、4 已退款。不要小看这个状态机，它决定了所有业务判断的写法。比如核销接口只允许“已支付”的订单流转到“已核销”，退款接口只允许“已支付”流转到“已退款”，如果状态不对直接抛出业务异常。把状态流转画清楚，后面写代码几乎不会出逻辑漏洞。

库存字段建议用 int，配合乐观锁 version 字段。虽然也可以用 Redis 做库存扣减，但数据库层面的扣减逻辑更直观，适合课设和演示。后续我会专门讲超卖问题。

2.4 前端方案：管理后台、游客端与移动端怎么取舍

前端方案是这个项目最容易纠结的地方。常见组合有三种：第一种是纯后端模板引擎，用 Thymeleaf 渲染页面，简单但交互弱；第二种是管理后台用 Vue + Element Plus，游客端用 H5 页面，前后端分离；第三种是管理后台用 Vue，游客端做成微信小程序。

我的建议是：如果你是用于毕设或简历展示，选第二种最稳妥。管理后台用 Vue + Element Plus 非常成熟，表格、表单、弹窗这些后台组件开箱即用，页面整洁；游客端用 H5 页面放在同一个前端工程里，路由分开，部署简单。如果非要做小程序，工作量会明显上升，需要处理微信登录、审核、域名校验等问题，对于一个练手项目来说性价比不高。当然，如果项目演示场景需要“扫码”，H5 页面生成的二维码完全够用，不必上小程序。

前后端分离就要面对跨域问题。开发环境下用 Vite 或 Webpack 的代理转发解决，生产环境由 Nginx 统一反向代理，把 /api 路径转发到后端服务。我在下面部署章节会给出具体配置，照着抄就行。

3. 核心功能模块实操解析

3.1 注册登录与角色权限：一个拦截器讲清楚

用户模块看起来简单，实际做起来有不少细节。密码必须加密存储，推荐 BCrypt，不要用 MD5。登录成功之后签发 token，这个系统适合用 JWT，把用户 id 和角色放进 token 里，后端通过拦截器统一解析。

我的实现思路是这样：

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } String token = request.getHeader("Authorization"); // 解析 token，失败则返回 401 LoginUser loginUser = JwtUtils.parseToken(token); // 放行游客可访问的接口，管理端接口校验管理员角色 request.setAttribute("loginUser", loginUser); return true; } }

注册登录流程里最容易忽略的是 token 过期和注销问题。JWT 本身无状态，服务端无法直接让它失效，所以我在 Redis 里维护了一个黑名单，注销时把 token 的剩余有效期写入 Redis，拦截器查一下命中就直接拒绝。这个细节虽然代码量不大，但能体现出你对“无状态认证”的理解。

角色权限采用简单的方式：用户表里有 role 字段，取值可以是 0 游客、1 运营、2 管理员。在拦截器里判断请求的接口路径前缀，比如 /admin/** 必须要求管理员角色，否则返回 403。对于小项目，这种方式比引入 Spring Security 更简单直观，也更容易在答辩时讲清楚。如果非要引入安全框架，Shiro 比 Spring Security 上手更快，但拦截器的实现已经足够，没必要徒增复杂度。

3.2 线上购票与订单状态机：库存、支付回调与退款

购票是这个系统技术含量最高的模块，没有之一。核心难点在于防止库存超卖，以及订单状态与支付结果的一致性。

先说库存。ticket_type 表里有 stock 字段，下单时不能先查库存再扣库存，因为并发场景下两个请求可能同时查到剩余 1 张，然后各自生成订单，最后就超卖了。正确做法是使用数据库的原子更新：

int count = ticketTypeMapper.deductStock(ticketTypeId, quantity); if (count == 0) { throw new BusinessException("库存不足"); }

对应的 SQL 是：

UPDATE ticket_type SET stock = stock - #{quantity}, version = version + 1 WHERE id = #{ticketTypeId} AND stock >= #{quantity}

只有受影响行数为 1 时，才说明库存扣减成功。这是最朴素也最可靠的防超卖方案，比“先 select 再 update”安全得多。如果你还想更贴近企业实践，可以在下单前用 Redis 的 DECR 做预扣，超时未支付再回补库存，但这种方案复杂度高，课设阶段用数据库扣减已经足够。

扣减库存之后立即生成待支付订单，并设置过期时间，通常 15 到 30 分钟。这里我用了一个定时任务，每分钟扫描一次待支付且创建时间超过 30 分钟的订单，把订单状态改成已过期，同时把扣掉的库存回补。回补库存必须也要加 where 条件，避免订单已经支付了定时任务还在回补：

UPDATE ticket_type SET stock = stock + #{quantity} WHERE id = #{ticketTypeId}

支付环节，课设项目通常不会真的接入支付平台。比较专业的做法是预留一个 payment 接口，内部模拟支付成功回调，把订单状态从待支付改成已支付，并记录支付时间。对接真实第三方支付时，只需要替换支付实现类，核心订单逻辑不动。有能力的可以加一个简单的“钱包余额”支付：用户在系统里预充值，下单时扣余额，余额不足则支付失败，这样也是一个完整的资金闭环，答辩时很好讲。

3.3 电子票二维码：从生成到线下核销的完整链路

线上购票完成之后，最关键的线下环节就是二维码核销。二维码不能直接存一个订单号，因为容易被伪造。我的做法是生成一个签名串，把订单号、票种、游玩日期拼接后，用 HMAC-SHA256 生成签名，再把订单号和签名拼起来作为二维码内容。

生成核心代码大概是：

String content = orderNo + "|" + sign; QrCodeUtil.generateQrCode(content, 300, 300);

核销时的流程是这样：扫码 -> 解析内容 -> 校验签名是否合法 -> 查询订单 -> 校验订单状态必须是已支付 -> 更新订单状态为已核销 -> 插入一条核销记录。这里最坑的就是重复扫码。游客第一次核销成功后，不小心退出了页面，再次扫码，如果系统没有做幂等处理，就会变成“重复核销”。更严重的是，如果两个检票口同时扫同一张票，只有一次能成功，另一次必须被拒绝。

幂等处理的正确姿势：在更新订单状态时加上状态条件，让数据库保证原子性：

int count = orderMapper.updateStatusByCondition(orderNo, 1, 2); if (count == 0) { throw new BusinessException("该订单已核销或状态异常"); }

where 条件同时限定“当前状态必须是已支付”和“目标状态是已核销”，这样即使并发请求同时进来，也只有一个查询能更新成功。而且核销记录表要唯一索引，用 order_id 做唯一约束，从数据层面再加一道防线。

3.4 动物档案与科普答题：让游客不只是“看一眼”

动物档案模块是内容差异化所在。我在 animal 表里放了分类、栖息地、习性描述、图片 URL 等字段，后台可以维护，前台展示卡片。这个模块本身不复杂，但有一个扩展点值得做：动物喂养记录。饲养员可以每天记录喂食时间、食物、备注，游客在动物详情页能看到这些记录，这就从静态展示变成了动态运营。

科普答题模块我采用的方式是：每只动物关联几个题目，游客进入动物详情页后可以参与答题，答对得积分，积分累计可以兑换虚拟勋章。答题记录表关联用户和题目，避免同一个人反复刷同一道题。这个模块的好处是能带来用户粘性，而且在数据统计里可以看到“最热门动物”和“答题正确率”，让系统不只是卖票工具。

答题接口要注意一个细节：题目答案不能直接返回给前端。我提供的接口只返回题目和选项，前端提交用户答案后，由后端判断对错并返回得分。如果你把正确答案放在接口返回体里，游客用浏览器 DevTools 一抓包就能全部答对，这个设计就失真了。

3.5 管理端数据统计：几张聚合报表看园区经营情况

统计模块是管理后台的收尾重点。我用三个报表撑起整个驾驶舱：门票销售趋势、客流核销统计、热门动物 TOP10。

门票销售趋势本质上就是按日期分组求和：

SELECT DATE(pay_time) AS day, COUNT(*) AS order_count, SUM(amount) AS total_amount FROM ticket_order WHERE status IN (1, 2, 4) GROUP BY DATE(pay_time) ORDER BY day

客流核销统计则要关联核销记录表，按小时或按日统计核销人数，用来评估园区高峰时段。热门动物 TOP10 可以通过统计 animal_feed_record 的访问次数或者答题记录数量得到，我实际上是在动物表里加了一个 view_count 字段，游客点击详情页时异步 +1，简单有效。

前端用 ECharts 展示折线图和柱状图，管理端首页放四个指标卡：今日订单量、今日销售额、今日核销人数、在园人数估算。这个“在园人数”可以由今日核销总人数减去已离园标记来近似，如果没有离园数据，直接显示今日累计入园人次也是一种合理的业务口径，需要在页面注明。

4. 踩坑实录：代码走查和部署过程中最常见的问题

4.1 票务超卖：乐观锁并不万能

我刚拿到这套源码时，第一件事就是看库存扣减。结果发现很多初版项目写的是：

TicketType ticketType = ticketTypeMapper.selectById(ticketTypeId); if (ticketType.getStock() >= quantity) { ticketType.setStock(ticketType.getStock() - quantity); ticketTypeMapper.updateById(ticketType); }

这个写法在单线程测试时很正常，但用 JMeter 或者直接写个多线程脚本一压，超卖马上就出现了。两个线程同时读到 stock=1，都满足条件，都执行了扣减，最终 stock 变成 -1。我在前面已经给出了正确写法，核心就一句话：把“检查库存”和“扣减库存”合并成一条原子 SQL。这不是什么高深技巧，就是数据库的 compare-and-set。如果用了 MyBatis-Plus 的乐观锁插件，也可以给实体加 @Version 注解，但还是要提醒，乐观锁解决的是“更新丢失”，不是“超卖”，真正防超卖靠的是 where stock >= quantity 这个条件。

4.2 核销接口的幂等：重复扫码不能重复入园

上线前测试时，我让同事拿同一张票连续扫码两次，第一次成功，第二次直接返回 500。为啥？因为核销记录表没有做唯一约束，代码里又是先查询订单状态再更新，两个请求同时进来，都能查到“已支付”，然后都去更新状态，其中一次更新成功，另一次更新时状态已经变成已核销，但代码里没有对这个结果做判断，直接抛了异常。

排查以后，我做了两层修复。第一层是在业务代码里把状态条件带上，更新影响行数为 0 时抛出明确的业务异常“该票已使用，请勿重复扫码”；第二层是在核销记录表给 order_id 加唯一索引，即使并发穿透到数据库层，也只会有一条记录插入成功。这两层一加，重复核销的问题彻底解决。修复完我才意识到，核销接口这个场景非常适合作为面试题提问，它考察的就是并发下的数据一致性意识。

4.3 LocalDateTime 序列化之后少了 8 小时

这是前后端分离项目中反复出现的经典问题。后端用的是 LocalDateTime，默认序列化格式是数组或者带 T 的 ISO 格式，前端解析很容易出问题，更麻烦的是时区。数据库连接串我没写 serverTimezone=Asia/Shanghai 之前，从库里查出来的时间直接少了 8 小时，导致订单过期时间计算错乱，明明刚创建的订单，定时任务一看已经超时，直接关单了。

解决方式有两处。第一，JDBC 连接串必须显式指定时区：

jdbc:mysql://localhost:3306/zoo_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

第二，在 application.yml 里统一配置 JSON 序列化格式：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai

另外，实体类里的时间字段统一用 LocalDateTime，不要有的用 Date 有的用 LocalDateTime，混用会让排序和比较变得很痛苦。这是我在代码走查时发现的高频问题。

4.4 文件上传：本地能传，服务器上就 500

动物图片和用户头像都涉及文件上传。本地开发时，我直接把文件写到项目根目录下的 upload 文件夹，一切正常。部署到 Linux 服务器后，同样的代码直接 500。原因很简单：项目 jar 包运行时的相对路径和本地不一样，而且每次重新部署，jar 包内的临时目录会被清空，上传的头像隔天就没了。

正确做法是把上传目录配置成绝对路径，放到 application.yml 里：

custom: upload-path: /data/zoo/upload

Controller 里从配置读取路径，然后用 FileOutputStream 写文件，再把可访问的 URL 存到数据库。为了让图片能通过浏览器访问，我用 Nginx 把 /upload/ 路径映射到磁盘目录，这样前端拿到的图片链接就是https://域名/upload/xxx.jpg。千万不要把上传的文件放在 classes 目录里，那是新手最容易踩的坑。

4.5 权限拦截放行静态资源：一个粗心导致登录页白屏

配置拦截器时，我发现登录页和静态资源全部被拦截了，页面白屏，控制台一堆 401。排查后确认是拦截器配置写得太宽：

excludePathPatterns("/login", "/register")

但没有把静态资源路径排除掉。前端资源如果是单独部署，不受后端拦截器影响；如果是用 Thymeleaf 或把前端打包到后端一起部署，就必须显式放行 /static/、/css/、/js/、/images/、/favicon.ico 等路径。这个坑很小，但能浪费你半小时，在搭建环境时留意一下就好。

5. 从源码 61317 到真正部署：环境准备与启动步骤

5.1 本地跑起来需要的环境清单

拿到源码 61317 之后，先别急着打开 IDEA。先把环境对齐，能省掉 90% 的启动报错。我建议的环境组合是：

数据库初始化一般会提供 sql 脚本。我建议手工执行脚本，然后打开 application.yml 确认数据库名称、用户名、密码是否匹配。最常见的启动失败就是 root 密码不一致、数据库没建、Redis 没启动。

5.2 配置文件的坑：数据源、Redis、文件路径

application.yml 是启动前必须逐个核对的配置文件。我需要重点检查三块。第一块是数据源：

spring: datasource: url: jdbc:mysql://localhost:3306/zoo_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456

第二块是 Redis 连接，如果本机 Redis 默认端口 6379 但没有密码，配置里就留空，不要随手填一个密码。第三块是自定义文件上传路径，我刚才提过，改成你本地真实的目录，比如D:/zoo/upload或/data/zoo/upload。

还要确认 MyBatis-Plus 的日志输出级别，开发阶段建议开启 SQL 日志：

logging: level: com.zoo.manage.mapper: debug

这样能在控制台直接看到执行 SQL，排查数据库问题非常方便。

5.3 Linux 生产部署：jar 包 + 守护进程 + Nginx

本地跑通之后，部署到 Linux 服务器也很直接。先在项目根目录执行：

mvn clean package -DskipTests

构建成功后在 target 目录下得到 xxx.jar。我习惯把 jar 放到 /data/zoo 目录，然后用 systemd 写一个守护进程，确保服务宕机后自动拉起：

[Unit] Description=Zoo System After=network.target [Service] User=root ExecStart=/usr/bin/java -Xms512m -Xmx512m -jar /data/zoo/zoo-manage.jar SuccessExitStatus=143 Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

前端工程构建后生成的 dist 目录，放到 Nginx 的 web 目录下，然后反向代理后端接口：

server { listen 80; server_name your.domain.com; location / { root /data/zoo/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /upload/ { alias /data/zoo/upload/; } }

这里有一个安全细节：生产环境一定要给后台管理端加访问限制，最简单的方式是改默认端口、限制内网访问，或者至少把默认密码改掉。很多课设项目部署后裸奔在公网，后台密码还是 admin/123456，这是非常危险的。你把这个注意事项写进 README，既体现安全意识，也是加分项。

5.4 拿到源码之后，先别急着跑

最后给拿到源码 61317 的朋友一个建议：下载代码后先花一个小时通读项目结构，不要一上来就点运行。先看数据库脚本，理清表关系；再看 controller 层的接口清单，了解系统有哪些功能；然后看 service 里订单和核销部分的实现，理解状态流转。如果你能画出一张“购票 -> 支付 -> 核销”的时序图，说明你已经把这个项目吃透了。接着再去运行，遇到问题也更容易判断是环境问题还是代码问题。

运行起来以后，重点测这几组场景：正常购票支付核销；购票后不支付等超时关单；同一订单重复核销；库存只剩 1 张时并发下单；管理员修改票种价格后游客端是否同步。这些场景测试完，你对这个系统的理解会远超单纯“跑起来”的人。

我个人在这个项目上最大的收获，其实是“状态设计”。订单状态、核销状态、用户状态，每个字段背后都对应一条业务规则。很多初学者写代码只关注功能点通没通，忽略了状态边界，结果就是测试时这漏一个那漏一个。如果你正在用这套源码做毕设，建议把状态机画在文档里，答辩的时候直接展示这张图，比念代码有说服力得多。还有一个小技巧：把常见的异常提示统一封装成业务异常类，Controller 里就不需要到处写 try-catch，代码会干净很多。这个项目后续的扩展空间也很大，比如接入真实支付、做园区热力图、增加会员年卡、对接小程序推送，都是顺手就能加的方向。