三十六陂接手动物园动物饲养管理系统这个项目的时候，不少朋友第一反应都是“这不就是个普通管理系统嘛，增删改查而已”。但真把需求理一遍你会发现，事情没那么简单：动物档案要有状态流转、饲养记录要按时间线归档、喂食计划到点要提醒、健康指标波动要预警，甚至笼舍容量和饲养员排班之间还有关联。所以这篇不打算只讲“怎么把Spring Boot和Vue搭起来”，而是把这个系统的核心设计思路、表结构、后端接口、前端页面和踩坑过程完整过一遍。如果你正在做同类的信息管理系统，或者准备从传统单体项目切换到Spring Boot前后端分离，这篇可以直接当参考手册。
1. 项目整体设计与技术选型
1.1 为什么是Spring Boot + Vue这套组合
做这类企业级信息管理项目，Spring Boot + Vue现在基本属于主流标准答案。原因其实很朴素：后端Spring Boot的生态足够成熟，配合MyBatis-Plus能把单表CRUD的重复代码压到最低，做业务校验和定时任务也顺手；前端Vue的组件化开发加上Element Plus这类UI库，后台管理页面很快就能搭出统一风格。对动物园这种业务方来说，最关心的是流程清晰、界面直观、后期能改，不需要太花哨的技术，这套组合正好。
有朋友会问，为什么不直接做一个单体Web项目，让后端把页面也渲染了？如果只是给内部两三个人用的表格工具，那确实没必要拆。但这个系统涉及的模块跨度很大，有动物档案、饲养记录、健康医疗、繁殖管理、笼舍清洁、人员排班，后面大概率还要接大屏可视化。一旦业务往前推进，前后端分离的优势就体现出来了：前端改样式不碰后端，后端加接口不碰前端，两边可以并行开发。实际项目里，我这边写接口的同时，前端同事已经拿着约定好的接口文档开始拼页面，整体工期能缩短三分之一左右。
还有层考虑是部署。前端构建完只是一堆静态文件，扔到Nginx里就行；后端是一个独立的Java应用，按标准打包部署。就算以后要横向扩展，把后端服务多挂几个实例也不影响前端。这种结构对后期运维和团队协作都友好。
1.2 系统模块划分与总体数据流
整个系统按业务拆成了几个核心模块：基础档案、饲养管理、健康管理、繁殖记录、统计报表、系统管理。基础档案管动物种类、动物个体、笼舍、饲养员；饲养管理管喂食计划、饲养记录、饲料库存；健康管理管体检、病历、疫苗和预警；繁殖记录单独成模块，因为它的数据形态和普通记录差别很大，涉及配对、孕期、幼崽登记一连串流程。
整体数据流不复杂：Vue页面通过Axios调用后端RESTful接口，Spring Boot处理业务逻辑后用统一返回体封装结果，MyBatis-Plus操作MySQL。认证用JWT，前端把Token存在本地，请求时由Axios拦截器自动附加到请求头。角色上分管理员、饲养员、兽医三种，不同角色看到的菜单和按钮不一样。
这里要专门说一句，我见过不少小项目一上来就堆Nacos、Redis、消息队列这类中间件。对单机部署、日均访问量几百次的内部管理系统，这些东西除了增加部署成本，几乎没有实际收益。这套系统里我只用了MySQL做存储，加上Spring Boot自带的定时任务处理喂食提醒和健康预警，最多再加个Redis做验证码缓存，有需要时再说，别为“技术先进性”买单。
1.3 工程初始化与目录结构
后端工程我习惯直接用Spring Initializr生成，依赖选Spring Web、MySQL Driver、Lombok，然后手动把MyBatis-Plus和JWT加进去。核心依赖如下：
xml复制<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-boot-starter</artifactId>
<version>3.5.3</version>
</dependency>
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt</artifactId>
<version>0.9.1</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<scope>runtime</scope>
</dependency>
前端用Vite创建Vue3项目，命令行三行搞定：
bash复制npm create vite@latest zoo-admin -- --template vue
npm install element-plus axios pinia vue-router
npm install echarts
目录组织上，后端按 controller / service / mapper / entity / dto / config / common 分包，前端按 views/animal、views/feeding、views/health、views/system 分页面。分包规则越简单越好，别搞太深，不然新同事进来找人要翻半天。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库建模：把动物园业务翻译成表结构
2.1 动物档案与状态流转设计
动物档案是整个系统的主档案，不能设计成简单一张表。一方面，一只动物属于某个物种，要关联种类信息；另一方面，动物当前在哪个笼舍、由谁负责、处于什么健康状态，这些字段都直接影响日常操作。animal表我保留了：动物名称、个体编号、所属物种ID、性别、出生日期、体重、入园日期、健康状态、所在笼舍ID、饲养员ID、照片URL、备注，以及逻辑删除标记。
状态字段用 status，取值大概有正常、观察、病休、离园四类。这里的关键设计是，状态不能只靠手改，而应该触发对应的操作流程。比如一只动物进入“病休”，后端Service层应当自动在健康档案里生成一条待处理记录，同时通知对应饲养员调整喂食计划。这个逻辑必须收拢在Service里，而不是散落在各个页面按钮上，后面维护会省非常多事。
个体编号我建议单独一个 code 字段，规则可以是“物种缩写+入园年份+序号”，比如某个灵长类动物入园编号是 PR-2024-017。为什么要单独编号？因为数据库主键ID自增后一旦分页或者跨系统同步，用户很难从ID认出动物，而业务人员习惯用可读性强的编号沟通。
2.2 饲养记录与健康档案的时序建模
饲养记录的关键是时序。我设计 feeding_record 时专门加了 plan_time 和 feed_time 两个时间字段。为什么是两个？因为喂食计划预先排好了计划时间，但实际执行可能因为各种原因延迟或提前，真正执行时间要单独存。这样后续就能对比计划与实际差多少，用来统计饲养任务是否按时完成，比如“最近一周按时喂养率98%”，靠的就是这两个时间字段。
健康档案表我设计成通用事件记录表，而不是每种记录建一张表。字段大概是：动物ID、记录类型、诊断内容、执行人员、记录日期、下次复查日期、处理状态。记录类型涵盖体检、接种、治疗、日常观察。用一张表的好处非常明显：所有健康事件可以按时间线统一展示，统计某只动物一年的病历故事也方便，只要按动物ID和时间排序就行。
2.3 核心建表SQL参考
下面给出一段关键的建表SQL，覆盖动物表、饲养记录表、健康记录表的核心字段：
sql复制CREATE TABLE `animal` (
`id` bigint NOT NULL AUTO_INCREMENT,
`code` varchar(32) NOT NULL COMMENT '个体编号',
`name` varchar(64) NOT NULL COMMENT '动物名称',
`species_id` bigint NOT NULL COMMENT '物种ID',
`gender` tinyint DEFAULT NULL COMMENT '性别 0雌 1雄',
`birth_date` date DEFAULT NULL COMMENT '出生日期',
`weight` decimal(8,2) DEFAULT NULL COMMENT '体重(kg)',
`arrival_date` date DEFAULT NULL COMMENT '入园日期',
`status` tinyint NOT NULL DEFAULT '1' COMMENT '状态 1正常 2观察 3病休 4离园',
`enclosure_id` bigint DEFAULT NULL COMMENT '笼舍ID',
`keeper_id` bigint DEFAULT NULL COMMENT '饲养员ID',
`photo_url` varchar(255) DEFAULT NULL COMMENT '照片地址',
`remark` varchar(500) DEFAULT NULL,
`deleted` tinyint NOT NULL DEFAULT '0' COMMENT '逻辑删除标记',
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `idx_species` (`species_id`),
KEY `idx_enclosure` (`enclosure_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='动物档案表';
这里给物种ID和笼舍ID加索引，是因为“按物种统计数量”和“查某个笼舍有哪些动物”是最常见操作，不加索引数据量上来后联表查询会明显变慢。逻辑删除我用 deleted 字段而不是物理删除，这样误删还能恢复，审计留痕也有依据。
sql复制CREATE TABLE `feeding_record` (
`id` bigint NOT NULL AUTO_INCREMENT,
`animal_id` bigint NOT NULL COMMENT '动物ID',
`keeper_id` bigint NOT NULL COMMENT '饲养员ID',
`plan_time` datetime NOT NULL COMMENT '计划喂食时间',
`feed_time` datetime DEFAULT NULL COMMENT '实际喂食时间',
`feed_type` varchar(32) NOT NULL COMMENT '饲料类型',
`feed_amount` decimal(8,2) NOT NULL COMMENT '喂食量',
`status` tinyint NOT NULL DEFAULT '0' COMMENT '0未执行 1已完成 2异常',
`remark` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_animal_time` (`animal_id`, `feed_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='饲养记录表';
健康记录表结构类似，核心就是 animal_id + record_type + record_date + next_date 这几个字段组合，按动物和时间检索非常高效。表与表之间关系也不复杂：animal多对一species，多对一enclosure，feeding_record多对一animal。关系不复杂，所以没必要上很重的建模工具，画一张简单的ER图让业务方确认，比写一百行文档有用得多。
3. 后端Spring Boot核心实现
3.1 项目初始化与通用配置
后端我用的是Spring Boot 2.7.x，配置文件里几个值得注意的点先列出来：
yaml复制server:
port: 8080
spring:
datasource:
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://localhost:3306/zoo_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
username: root
password: 123456
servlet:
multipart:
max-file-size: 10MB
max-request-size: 20MB
jackson:
date-format: yyyy-MM-dd HH:mm:ss
time-zone: GMT+8
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
jwt:
secret: 换成你自己的随机字符串
expire: 7200
jackson日期格式和MyBatis-Plus的下划线转驼峰这两项，我建议一上来就配好，不然后面大量时间会花在字段映射和日期显示上。框架默认行为和生产需求差得太远，提前配置属于花两分钟省两天。
通用返回体我习惯定义一个 Result<T>，包含code、msg、data三个字段。所有Controller统一返回这个对象。好处是前端Axios响应拦截器可以统一判断code，而不是每个接口单独处理200/500/业务异常。这个设计看似简单，但团队协作时能少扯很多皮。
登录接口我用的JWT，密码存库前用BCrypt加密，登录成功后生成Token返回给前端。这里我采用的是单Token加较短过期时间，内部系统完全够用，没必要为了追求“技术完整”上双Token刷新机制，增加了复杂度，实际收益却很低。
3.2 动物档案模块的接口实现
动物档案模块说白了还是CRUD，但有几个地方不是简单增删改查能糊弄过去的。
第一，新增动物时后端要自动处理初始状态。比如入园时状态默认正常，但如果录入时选择了“存在健康异常”，就得同时创建一条健康记录，把病休流程启动起来。第二，修改数据时前端可能只传部分字段，后端不能图省事把整个实体直接覆盖，要按需更新，做好必填校验。第三，列表查询一般支持关键词搜索、按物种筛选、按状态筛选、分页，我用MyBatis-Plus的LambdaQueryWrapper拼条件，代码很简洁。
下面给一个Controller写法片段：
java复制@RestController
@RequestMapping("/api/animal")
public class AnimalController {
@Resource
private AnimalService animalService;
@GetMapping("/page")
public Result<Page<AnimalVO>> page(AnimalQueryDTO dto) {
return Result.success(animalService.page(dto));
}
@GetMapping("/{id}")
public Result<AnimalVO> detail(@PathVariable Long id) {
return Result.success(animalService.detail(id));
}
@PostMapping
public Result<Void> save(@RequestBody @Valid AnimalSaveDTO dto) {
animalService.save(dto);
return Result.success();
}
@PutMapping("/{id}")
public Result<Void> update(@PathVariable Long id, @RequestBody @Valid AnimalSaveDTO dto) {
animalService.update(id, dto);
return Result.success();
}
@DeleteMapping("/{id}")
public Result<Void> delete(@PathVariable Long id) {
animalService.delete(id);
return Result.success();
}
}
Service层里再写具体业务逻辑。比如删除前要检查是否还有未完成的饲养计划；动物处于病休状态时不允许直接删除，要先结束健康流程。这些约束写成if判断，一两条还好，多了就提取成私有方法，保证可读性。列表查询拼VO时，我习惯先分页查出主表数据，再按ID批量查出关联的物种名、笼舍名、饲养员名，最后组装。这样避免for循环里逐条查数据库，性能差一个数量级。
3.3 饲养计划与健康预警的定时任务
饲养计划我做成每日自动生成。设计上有一张喂食计划模板表，记录每种动物每天喂几次、大致几点喂、喂什么饲料。定时任务在每天凌晨根据模板批量生成当天的feeding_record记录，状态为未执行。饲养员登录后看到当天的任务列表，逐条确认“已完成”。
这个定时任务最关键的是幂等性。如果服务器当天重启了两次，定时任务跑了两遍，不做幂等判断就会生成两天的重复记录。我的处理方式：生成前先查当天是否已经存在记录，存在就跳过。数据库层面上加唯一业务键，比如 animal_id + plan_date + 时间段，双保险保证不重复。
健康预警用的也是Spring自带的 @Scheduled 注解。每天上午8点扫描健康记录表，把 next_date 小于当天日期的记录筛选出来，生成一批“待复查提醒”。这个逻辑本身很简单，但扫描频率需要注意，一天跑一次足够，频率太高反而对业务人员形成提醒轰炸。
java复制@Component
public class HealthRemindTask {
@Resource
private HealthRecordMapper healthRecordMapper;
@Scheduled(cron = "0 0 8 * * ?")
public void remind() {
// 查询今天之前已过了复查日期的健康记录
// 生成待办提醒消息
}
}
每个定时任务的cron表达式，我建议加注释说明业务含义。不然过两周再看代码，没人记得这个定时任务是干嘛的，踩过的坑都写在注释里才算数。
4. 前端Vue页面开发实战
4.1 登录与权限控制的实现思路
前端用的Vue3 + Vite + Pinia + Element Plus，目录结构大致是：api目录放接口请求封装，router目录配路由，stores目录放Pinia状态，layout目录放侧边栏加顶栏的公共布局，views目录按业务模块分页面。
登录页是管理系统第一个入口。流程很标准：用户填账号密码，请求登录接口，后端返回Token和角色信息，前端存在Pinia里并持久化到localStorage。路由守卫里判断本地有没有Token，没有就跳转登录页。同时根据角色过滤菜单，普通饲养员只能看到动物档案、饲养记录、健康管理，管理员才能看系统设置和统计报表。
菜单权限这里有个小建议，内部管理系统的功能权限其实用“角色+前端路由meta”过滤就够了，不用一上来就做按钮级权限。等真出现“同一角色不同人操作范围不同”的需求，再考虑引入更细粒度的权限控制。管理系统最重要的是业务跑得通，不是权限模型多复杂。
4.2 动物列表与表单弹窗的实现细节
动物列表页核心是el-table加el-pagination加搜索栏。搜索栏一般包含动物名称关键词、物种下拉、状态下拉。下拉数据从接口加载一次，缓存在Pinia或组件里，避免每次搜索都重新请求。
这里有一个很多人忽视的细节：表格里的性别、状态这类枚举值，前端不要直接显示数字，要做翻译映射。我在页面里维护一个映射对象：
javascript复制const statusMap = { 1: '正常', 2: '观察', 3: '病休', 4: '离园' }
const genderMap = { 0: '雌', 1: '雄' }
表格列里用formatter函数转换显示。这样代码干净，以后要调整文案或者加多语言支持，只动一个对象即可。
新增和编辑我统一弹一个dialog，里面放el-form。表单校验用Element Plus自带的rules，比如动物名称必填、出生日期不能晚于今天、体重范围0-3000公斤。体重范围这个校验会让外行人觉得奇怪，但真实场景里一只小型动物和大型动物的体重差异巨大，卡得太死反而会在真实录入时添麻烦，所以放宽范围、侧重必填校验更合理。
照片上传组件用element自带的el-upload，通过action属性指到后端的上传接口。上传成功后把返回的URL存进表单字段，回显时直接拿这个字符串显示。整体流程通畅，但要注意设置上传接口的请求头，确认带上了Token，不然会出现“明明登录了，上传却401”的诡异问题。
4.3 饲养时间线与健康趋势图
饲养记录页面用了两种展示方式，一个表格，一个时间线。表格显示当天各动物的喂食状态和完成情况，方便批量操作。时间线组件则展示单只动物最近几天的喂食记录，视觉上非常直观，一眼就能看出“今天喂了几次、是否按时、有没有异常”。实现上后端需要提供一个按动物ID聚合的接口，返回时间线节点列表。
健康趋势图我用ECharts的折线图，展示某只动物的体重变化过程。在Vue3里可以直接用封装好的vue-echarts，也可以手动初始化。我偏好手动初始化，因为控制力更强，图表在弹窗里切换数据时，手动调用setOption更新比较顺手。这里有个坑必须先说：ECharts容器的高度的必须显式设置，比如style里写height: 300px，不然图表会渲染成0高度，页面看起来啥都没有，但控制台也不报错，排查半天发现是样式问题。
5. 开发中踩过的坑与排查方案
5.1 跨域与Token拦截的经典问题
前后端分离最经典的就是跨域问题。前端跑在5173端口，后端在8080端口，浏览器默认会拦截非同源请求。我一般把开发阶段和生产阶段分开处理。开发阶段用Vite的proxy代理，把 /api 转发到8080，这样浏览器访问的是同源地址，几乎没有跨域烦恼。生产阶段用Nginx反向代理，把前端静态资源和后端接口统一挂到同一个域名下。这种方式最省心，也是生产环境推荐做法。
如果坚持让前端直接请求后端，那就得在后端配CorsFilter：
java复制@Configuration
public class CorsConfig {
@Bean
public CorsFilter corsFilter() {
CorsConfiguration config = new CorsConfiguration();
config.addAllowedOriginPattern("*");
config.addAllowedMethod("*");
config.addAllowedHeader("*");
config.setAllowCredentials(true);
UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
source.registerCorsConfiguration("/**", config);
return new CorsFilter(source);
}
}
Token拦截的坑主要有两个。第一个，Axios上传文件时如果用了FormData，但拦截器里没有正确设置请求头，后端可能拿不到Token，结果就是“上传接口401”。第二个，后端JWT过滤器如果忘了放行 /api/login，用户会一直提示“未授权”。这两个问题排查方向不一样，但都容易让新手卡很久，所以我习惯在写代码时就把登录接口列入白名单，并顺便把验证码接口也放进去。
5.2 日期格式与JSON序列化的大坑
Spring Boot默认输出的LocalDateTime格式是类似 2024-06-13T10:20:30 的ISO格式，前端显示出来是一串带T的字符串，用户看到直接懵。我在 application.yml 里配置了jackson的date-format和time-zone，但这里有个细节必须讲清楚：date-format 对 java.util.Date 生效，对 LocalDateTime 不一定生效。如果实体字段用的是LocalDateTime，要么在字段上单独加 @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")，要么在全局配置里注册JavaTimeModule。我踩过这个坑之后，统一在实体类的日期字段上加了注解，避免其他同事再踩。
前端也有对应的问题，element的日期选择器返回的是Date对象，直接提交到后端经常出现格式不匹配。我一般在提交前统一调用工具函数，把日期字段格式化成 yyyy-MM-dd HH:mm:ss 字符串再发送。
5.3 图片上传与静态资源映射
动物照片上传后需要回显，这个需求看起来简单，实际坑不少。上传接口接收MultipartFile，存到服务器磁盘目录，返回可访问的URL。但在生产环境，前端页面域名和后端服务域名可能不同，直接用相对路径访问会404。解决办法是配置静态资源映射：
java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
registry.addResourceHandler("/upload/**")
.addResourceLocations("file:D:/zoo-upload/");
}
}
这个路径建议放到配置文件里，不要写死在代码中。Windows和Linux的路径分隔符不一样，部署到Linux服务器时经常因为盘符问题导致图片无法访问。
上传文件名不要用原始文件名。一是容易冲突，二是文件名里可能有特殊字符带来意外问题。我用UUID重命名加保留原始扩展名：
java复制String ext = StringUtils.getFilenameExtension(file.getOriginalFilename());
String newName = UUID.randomUUID() + "." + ext;
5.4 列表分页与查询性能问题
系统数据量不大时，分页查询随便写都能跑。但如果动物档案达到几千条、饲养记录达到几万条，有几个地方必须重视。
第一，列表查询避免查出大字段。比如备注、体检结论这种长文本，如果联表一次性全查出来，网络传输和渲染都会拖慢。MyBatis-Plus里可以用select方法指定列，只查当前页面需要展示的字段。
第二，联表查询尽量先过滤再分页。很多新手会把所有表join完再limit，数据库压力很大。正确做法是先对主表条件过滤并分页，得到当前页的主表ID列表，再根据ID去关联查询明细数据。也就是“先窄后宽”，查询计划完全不一样。
第三，统计接口不要和列表接口耦合。首页统计动物总数、今日喂食完成率这类数据，单独写统计接口，用聚合SQL处理，而不是把整个表数据load到内存里数。这个问题在报表模块开发时集中暴露，起初我也想省事，后来数据一多就超时，老老实实改成SQL聚合。
6. 一点实操体会
这个项目做下来，我感触比较深的是：动物园动物饲养管理系统这类业务，真正难的不是框架搭建，而是把业务规则梳理清楚。喂食计划怎么生成、健康预警怎么触发、动物状态怎么流转，这些想明白了，代码反而是最简单的那一环。很多时候项目延期不是因为技术难点攻克不了，而是需求边界没定清楚，做到一半改来改去。
最后分享一个我自己的小习惯：新接手这种管理系统，先别急着写代码，花一天时间把核心表结构画出来，给业务方过一遍。业务方不一定懂技术，但看到表结构往往能比看需求文档更直观地提出意见，很多需求歧义在“画表”阶段就暴露了。等表和接口设计确认，后面开发就是流水线。
如果你想扩展，可以考虑做一个可视化大屏，把动物分布、喂食完成率、健康趋势放到大屏上，对园区日常管理和对外展示都有帮助。也可以做个小程序端，让饲养员手机扫码打卡喂食记录，移动端操作会比在电脑上点来点去好用很多。不过那些都是后续迭代的事情了，当前这套系统的核心链路已经足够完整，先把基础打扎实，再谈花活不迟。