做毕设选管理系统很多同学第一反应都是图书馆、宿舍、校园二手交易做完自己都提不起劲。猪场管理系统听起来好像有点土但只要你把它当成一个真实的规模化养殖业务平台来设计它反而比那些烂大街的选题更能体现功力。猪场管理系统的核心价值在于它覆盖了从猪只档案建立、转栏、配种、产仔、防疫、饲料出入库、销售结算到经营统计分析的完整闭环同时还有人员权限、数据报表等企业级系统的典型需求非常适合用来展示你对 SpringBoot 技术栈、数据库设计、业务流程建模的综合掌握能力。这篇文章我按一个标准毕设项目的实际推进路径来拆解从需求怎么定、表怎么设计、接口怎么写到实测中容易踩的坑、怎么把系统讲得让答辩老师挑不出毛病。内容基于常见的毕设需求和工程实践你可以直接参照这个思路去搭自己的系统不用照搬但能省掉很多弯路。1. 项目整体设计与需求拆解1.1 规模化猪场的核心业务痛点和系统定位先说为什么不用传统的小农户散养模式来做需求。散养猪场可能就几十头猪一个人管全部Excel 就能记完账。规模化猪场的核心问题是存栏几千头甚至上万头猪只分布在不同的猪舍、不同的批次、不同的生长阶段人的记忆和纸质台账根本撑不住。这个时候系统要解决的不是“记录有没有”而是“记录能不能反映真实经营状态”。所以你设计系统时要站在场长的角度看问题今天有多少猪可以出栏哪个猪舍的饲料消耗异常高这批母猪的配种成功率是多少防疫记录是不是完整上个月的销售利润构成是怎样的这些问题如果系统都能答得上来你这个系统的业务价值就成立。系统的定位就是“给规模化猪场提供数字化管理工具”目标用户是场内管理人员包括场长、技术员、饲养员、仓管、销售等角色。系统从技术上可以是单机部署但设计上要面向多用户、多角色协作。这也是毕设答辩时能讲出彩的地方你不是在做“单表增删改查”而是在做“有角色的业务系统”。1.2 技术选型分析SpringBoot 是当前毕设中最稳妥的选择。它最大的优势是开箱即用内嵌 Tomcat不用像传统 SSM 那样写一堆 XML 配置对用来完成课程设计和毕业设计来说非常友好。配合 MyBatis-Plus 可以极大减少 SQL 编写量分页、条件构造器这些常用功能都有现成实现。前端常见的搭配有两种一是服务端渲染的 Thymeleaf二是前后端分离模式Vue Element UI。如果你时间紧、想快速跑通就用 Thymeleaf Bootstrap甚至直接用一个个 HTML 页面配合 Ajax 也能实现。但如果你想在答辩中展示更多的现代开发技能建议使用 Vue 3 Vite Element Plus 做成前后端分离后端提供 JSON 接口。这个方案对前端能力有一定要求但做完以后整个系统的代码结构更清晰也能体现出“前后端分离架构”的设计思想。数据库选 MySQL这个不用犹豫。Redis 在毕设里可加可不加如果要做验证码、缓存统计报表数据可以引入一个简单的 Redis 缓存模块但注意不要为了加而加必须能讲清楚它解决了什么问题。文件存储可以用本地上传目录也可以接入云存储服务毕设阶段用本地存储加 Nginx 映射即可。这里列一下我建议的基础技术栈层次技术用途后端SpringBoot 2.7.x基础框架持久层MyBatis-Plus 3.5.x数据访问简化数据库MySQL 8.0持久化存储前端Vue 3 Element Plus管理后台界面认证JWT登录状态管理构建Maven项目构建部署Docker / 手动 jar环境部署1.3 功能模块拆分根据真实业务需求我建议把系统分成七个核心模块够完整又不会撑爆开发时间用户与权限管理登录、退出、密码修改、角色分配、菜单权限控制。猪只档案管理添加猪只、猪耳标号、所在猪舍、品种、性别、出生日期、当前状态保育、育肥、怀孕、哺乳、待配种等。猪舍与批次管理猪舍信息、栏位数量、当前批次、批次入栏与转出记录。养殖业务管理配种记录、产仔登记、断奶记录、转栏操作、死亡淘汰登记。防疫与用药管理疫苗计划、免疫记录、用药记录、兽药库存。饲料与库存管理饲料入库、领用出库、盘点、库存预警。销售与统计报表销售登记、销售明细汇总、存栏统计、出栏率统计、饲料消耗统计、月度经营汇总。每一个模块都不是独立存在的。猪只状态的变化会触发批次记录的变更产仔登记会影响母猪状态和仔猪数量饲料领用会减少库存并记录到对应批次的消耗销售出栏会改变猪只状态并生成销售利润统计。这种联动关系是你的系统区别于“学生作业”的关键。2. 数据库设计与核心表结构2.1 关键实体关系梳理数据库设计是整个项目的地基很多同学喜欢把表拆得很碎一对多、多对多乱建最后写查询时嵌套一堆关联性能又差又难理解。我的建议是以“猪只”为核心实体围绕它建立业务流转记录。核心实体包括猪只pig存栏猪的基本档案。猪舍pig_house物理空间信息。批次batch同一时间进入同一阶段的一组猪用于经营统计。配种记录breeding_record母猪繁殖业务过程。产仔记录litter_record产仔数量、存活数、健仔数等。防疫记录vaccine_record疫苗类型、日期、操作人。用药记录medicine_record疾病治疗记录。饲料出入库feed_stock / feed_record饲料库存台账。销售记录sale_record销售结算数据。用户表sys_user和角色表sys_role系统权限基础。实体之间的关联可以这样梳理猪只属于猪舍猪只可以被划入批次母猪有多次配种记录每次配种可能产生一次产仔记录猪只会有多条防疫记录和用药记录销售订单关联出栏猪只饲料出入库记录关联操作人和批次。用你熟悉的 ER 图工具画出来整体结构其实并不复杂。2.2 主要表设计重点说几张关键表的字段设计这是答辩时最容易深挖的地方。猪只信息表CREATE TABLE pig_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 主键ID, ear_tag VARCHAR(32) NOT NULL UNIQUE COMMENT 猪只耳标号, pig_type TINYINT NOT NULL COMMENT 猪类型0母猪1公猪2仔猪3育肥猪, breed VARCHAR(32) COMMENT 品种, house_id BIGINT COMMENT 所属猪舍ID, batch_id BIGINT COMMENT 所属批次ID, birth_date DATE COMMENT 出生日期, entry_date DATE COMMENT 入场/转栏日期, weight DECIMAL(8,2) COMMENT 当前体重(kg), status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0正常1配种中2怀孕3哺乳4隔离5死淘, remark VARCHAR(255), create_time DATETIME, update_time DATETIME );这张表里有些关键点要想清楚。耳标号是业务上的唯一标识类似人的身份证号必须加唯一约束这个是猪只档案的唯一性保障。猪只类型和状态是核心字段状态直接控制后续操作是否允许。比如一头猪状态为“隔离”时不能参与配种、不能转栏、不能销售出栏这个校验逻辑要在 Service 层做。产仔记录表CREATE TABLE litter_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, pig_id BIGINT NOT NULL COMMENT 母猪ID, breeding_date DATE COMMENT 配种日期, farrow_date DATE COMMENT 分娩日期, total_count INT COMMENT 产仔总数, live_count INT COMMENT 活仔数, healthy_count INT COMMENT 健仔数, weak_count INT COMMENT 弱仔数, stillborn_count INT COMMENT 死胎数, mummy_count INT COMMENT 木乃伊数, create_by BIGINT, create_time DATETIME );产仔记录中的死胎数、木乃伊数看着琐碎却是规模化猪场很关注的生产指标这些字段的存在能反映出你确实了解业务而不是简单地写一个“数量”字段糊弄过去。在答辩时如果能准确说出健仔率、死胎率怎么算会很加分。饲料出入库表建议拆成两张一张库存表保存当前库存量一张流水表记录每次入库和出库明细。流水表通过库存表的外键关联出库时要校验库存是否充足并在事务内完成扣减。这是典型的进销存设计不只是在猪场系统里几乎所有库存管理场景都是这个套路。2.3 为什么这么设计很多同学只看表结构不看设计思路结果答辩时被老师问一句“为什么 status 不直接存字符串”就懵了。这里我给几个常见的解释方向你可以直接用状态字段用数字枚举而不是字符串是为了查询性能和存储体积同时在代码里用枚举类定义保证状态流转可控。把产仔指标拆成多个字段而不是一个 JSON 字符串是为了方便统计聚合比如select avg(healthy_count) from litter_record就能算出平均健仔数。流水表与主表分离是为了保留完整历史轨迹。比如猪只死亡后档案不能直接删除而是通过“死淘记录”保存原因、时间、操作人这样才能做死淘率分析。业务表统一加 create_time、update_time并且通过 MyBatis-Plus 的自动填充来处理保持所有表的数据时间一致性。数据库命名上保持一致的下划线风格表名用复数也不建议统一用单数即可。字段名不要用 MySQL 关键字比如desc、rank、status在有些场景下容易出问题避免使用。3. 核心业务逻辑与接口实现3.1 猪只档案的引入与状态流转猪只管理是系统的根其他所有模块都围绕它转。添加猪只时除了基本的档案信息还建议把“入场/转栏日期”做成业务轨迹。一个可复用的做法是将猪只的每次状态变化都记录到一张pig_status_log表中包含pig_id、from_status、to_status、operator_id、reason、remark、create_time。这样做的好处是你随时可以查每一头猪经历了什么变化比如它什么时候从保育转到育肥什么时候被隔离什么时候配种成功。在统计层面也能很方便地计算出“当前存栏结构”和“状态流转效率”。后端新增猪只接口的核心逻辑如下Transactional public Long createPig(PigAddDTO dto) { // 检查耳标号是否已存在 PigInfo exist pigInfoMapper.selectOne( new LambdaQueryWrapperPigInfo().eq(PigInfo::getEarTag, dto.getEarTag())); if (exist ! null) { throw new BizException(耳标号已存在); } PigInfo pig new PigInfo(); BeanUtils.copyProperties(dto, pig); pig.setStatus(PigStatusEnum.NORMAL.getCode()); pigInfoMapper.insert(pig); // 记录状态日志 PigStatusLog log new PigStatusLog(); log.setPigId(pig.getId()); log.setFromStatus(PigStatusEnum.UNKNOWN.getCode()); log.setToStatus(PigStatusEnum.NORMAL.getCode()); log.setOperatorId(CurrentUser.getId()); pigStatusLogMapper.insert(log); return pig.getId(); }事务注解Transactional必须加在 public 方法上并且这个方法要由 Spring 容器通过代理调用否则事务不会生效。很多同学直接在 Controller 里调 Service 方法或者同一个类内部调用带事务的方法事务都没有实际拦截这是一个必踩的坑。3.2 批次管理与转栏流程批次管理在规模化猪场特别重要它本质上是一种分组策略。你可以把一个批次理解为一栋楼里的房间猪只入住后它们的饲料消耗、防疫计划、出栏时间都跟着批次走这样统计报表就不用一头猪一头猪地汇总直接按批次聚合即可。批次的状态也应该是一个枚举在养、已出栏、已空置。只有“在养”状态的批次才能继续转入猪只出栏操作会同时更新批次内猪只状态和批次存栏数。转栏的核心逻辑是选择来源批次、目标批次、转出猪只列表、转栏原因。代码上大概是这样Transactional public void transferBatch(Long sourceBatchId, Long targetBatchId, ListLong pigIds, String reason) { Batch source batchMapper.selectById(sourceBatchId); Batch target batchMapper.selectById(targetBatchId); // 校验批次状态 if (!BatchStatusEnum.ACTIVE.getCode().equals(source.getStatus()) || !BatchStatusEnum.ACTIVE.getCode().equals(target.getStatus())) { throw new BizException(仅能转入在养批次); } // 批量更新猪只批次 PigInfo update new PigInfo(); update.setBatchId(targetBatchId); update.setHouseId(target.getHouseId()); pigInfoMapper.update(update, new LambdaQueryWrapperPigInfo().in(PigInfo::getId, pigIds)); // 记录转栏流水 batchTransferLogMapper.insert(new BatchTransferLog(sourceBatchId, targetBatchId, pigIds.size(), reason)); // 更新批次存栏数 source.setStockCount(source.getStockCount() - pigIds.size()); target.setStockCount(target.getStockCount() pigIds.size()); batchMapper.updateById(source); batchMapper.updateById(target); }这里有一个细节当我更新猪只的批次和猪舍时不需要遍历每个猪只单独 update而是在 SQL 层通过in条件一次完成。很多新手会写for循环逐条 update不仅慢而且一旦中间某条失败部分数据已变更事务回滚又没做好数据就乱了。3.3 自动统计存栏数、出栏率、饲料消耗统计报表是很多同学觉得难的部分实际上大部分统计可以拆成三类当前状态统计比如现在存栏多少、母猪怀孕的有多少直接通过 group by 查询。区间变动统计比如本月出栏多少、本月死亡多少需要通过业务记录表加上时间范围条件来筛选。比率计算出栏率、配种成功率、健仔率等需要先查两个指标再计算。以存栏统计为例你可以用一个接口直接返回不同状态的猪只数量public ListMapString, Object countPigByStatus() { return pigInfoMapper.selectMaps( new QueryWrapperPigInfo() .select(status as status, count(*) as num) .groupBy(status)); }用 MyBatis-Plus 的 selectMaps 比自定义 VO 更方便前端拿到后直接渲染。不过如果报表查询复杂涉及多表关联和分组建议直接写 XML SQL可读性和执行计划可控性更好。不要迷信 MyBatis-Plus 能解决一切它擅长单表 CRUD多表统计还是写原生 SQL 更清晰。出栏率的一个简便算法是一段时间内销售出栏的头数除以这个时间段开始时存栏加上期间转入的总数。这个定义可能和实际生产指标有差异但答辩时只要你能说清楚自己的公式以及为什么这么算就是有效的业务建模。3.4 权限控制与操作日志管理系统没有权限控制就缺少灵魂。最简单的权限模型是用户-角色-菜单三张表。用户登录后获取角色角色关联菜单权限前端根据权限动态渲染菜单按钮后端接口用 Spring 的拦截器或切面校验。在 SpringBoot 中可以用自定义注解 切面实现接口权限控制例如Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequirePermission { String value(); }在 Aspect 里检查当前用户是否拥有该权限码没有就抛异常。这种做法比每个 Controller 里手写 if 判断要优雅得多也方便统一管理。操作日志我建议记录关键操作比如配种、转栏、销售、库存调整。日志字段至少包括操作人ID、操作类型、业务对象ID、操作内容、操作时间。可以用 AOP 统一截取不需要每个业务方法里手动写日志代码。这个模块的独立性很强也是很多评委老师喜欢追问的设计点。4. 实测过程与踩坑记录4.1 环境搭建与项目结构开发环境方面我推荐直接用 IntelliJ IDEA 社区版或专业版都可以。JDK 1.8 或 11 都行SpringBoot 2.7 配 JDK 11 很稳。MySQL 8.0 要注意驱动版本和时区设置连接串里最好加上serverTimezoneAsia/Shanghai否则插入时间比实际时间差八个小时很多同学在这上面吃过亏。项目分包建议按功能模块来分而不是所有类堆在一起com.example.pigfarm ├── common // 通用结果封装、异常、常量、工具类 ├── config // 配置类跨域、拦截器、自动填充 ├── controller // 接口层 ├── service // 业务层 ├── mapper // 数据访问层 ├── entity // 实体类 ├── dto // 入参对象 ├── vo // 出参对象 └── aspect // 切面权限、日志这样分包的好处是职责清晰答辩时你也能很流畅地说出每个目录的作用。Controller 层只做参数接收和结果包装不写过重业务Service 层实现业务逻辑Mapper 层只做数据访问。严格分层虽然会多写几个方法但代码可维护性会好很多。4.2 典型 BUG时间字段、事务失效、分页插件第一个高频 BUG 是日期格式化。前端传字符串日期后端用Date接收时经常报格式错误。解决方式是全局配置JsonFormat和 Spring 的日期转换器或者直接用LocalDate/LocalDateTime类型配合 Jackson 的 JavaTimeModule。建议后端统一返回字符串格式的日期不要直接返回对象让前端自己格式化这样可以避免浏览器的时区偏移。第二个高频 BUG 是分页失效。MyBatis-Plus 使用分页要先配置分页插件Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }如果忘了配分页插件Page对象返回的数据永远是全量不会报错但结果不对调试时非常隐蔽。另外分页查询一定要调用selectPage方法不能用selectList自己手动截取。第三个高频 BUG 是事务失效。常见原因有三个一是没有被 Spring 代理比如同类内部调用二是Transactional加在 private 方法上三是异常被 catch 掉了你 try-catch 里吞掉异常事务感知不到自然就不会回滚。正确做法是让异常向上抛出或者用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()手动回滚但这种手动回滚不优雅不太推荐。4.3 性能优化报表查询慢怎么办当数据量到达一定规模比如猪只信息几万条、出入库流水十几万条时单表查询可能变慢。常见的优化实践加上正确的联合索引比如pig_info表的(house_id, status)因为“查某栋猪舍里所有正常状态的猪”是个高频查询。大报表不要实时统计而是用一个缓存表每天晚上定时汇总当日数据报表接口直接查汇总表。分页查询不要使用LIMIT 100000, 10这种深分页要用WHERE id 上一次的最大ID LIMIT 10的方式。不过毕设阶段数据量不大真正的性能瓶颈很少出现。你只需要在答辩时能说出你考虑了哪些优化点体现出工程思维就够了。4.4 部署与演示注意事项毕设项目最终要演示提前准备一份傻瓜级部署文档很关键。后端打包成 jar直接java -jar运行前端构建后丢到 Nginx 的 html 目录下配置一下反向代理/api到后端端口数据库导出 SQL 文件新建库导入即可。如果本地跑不起来至少保证有一台开发机可以正常演示。演示时最怕的就是现场炸数据。建议准备一套干净的演示数据包含不同状态的猪只、完整的配种产仔记录、几条销售记录确保每个模块点开都有内容可看。同时把数据库备份好万一演示时误删了数据也能快速恢复。5. 常见问题与避坑指南5.1 开发期的高频问题问题原因解决方法插入数据报主键重复没用雪花ID依赖自增且手动指定了ID实体主键统一用TableId(type IdType.ASSIGN_ID)或让数据库自增前端请求跨域前后端分离时端口不一致后端配置全局 CORS或者通过 Nginx 反向代理时间显示不正确时区/序列化问题统一使用LocalDateTime 全局格式化上传文件找不到路径相对路径在不同启动方式下变化使用绝对路径配置存入数据库时保存相对路径供访问拼接登录失效JWT 过期时间太短或未处理拦截设置合理过期时间并在前端统一处理 401 状态跳转登录这些问题如果你在开发时就注意能省下很多调试时间。我每次搭后端项目第一步先配统一返回结构、全局异常处理、跨域配置、时间格式化然后才写业务代码。基础配置不打好后面全是坑。5.2 答辩前必做的自测清单每个接口都用 POST 工具或前端页面试一遍不只是看返回成功还要检查数据是否真正落库。测试异常场景重复添加同一个耳标号、出库数量超过库存、删除有业务关联的猪只。这些地方如果后端没有拦截数据就会不一致。用不同角色账号登录确认权限生效。比如饲养员账号不应该能删除销售记录。演示时把浏览器控制台打开如果某个按钮没反应先看是不是接口报错避免现场不知所措。5.3 扩展方向让项目从 80 分到 100 分猪场管理系统是一个典型的业务管理系统如果只做 CRUD答辩的深度可能不够。以下扩展方向优先级高、实现成本低、亮点明显引入消息队列或定时任务比如每天定时生成“待配种母猪提醒”“临期疫苗提醒”这会让系统看起来更智能。引入可视化图表统计使用前端图表库将存栏结构、出栏趋势、饲料消耗绘制成折线图或饼图可视化能力是很多毕设项目最缺的东西。设计一个简单的“经营预警”模块比如饲料库存低于阈值时向管理员发送站内信体现了系统闭环。如果有余力做一个微信小程序扫码查看猪只档案的轻量端只读数据不需要太复杂的交互能展示移动端接入能力。不过要提醒一句扩展功能要适可而止。先保证主流程完整没有 BUG再增加扩展。很多同学为了加物联网设备对接结果硬件调试了半个月主系统反而不稳定这就本末倒置了。6. 文档与答辩素材的组织这个项目在交付时一般都包含“程序文档讲解”三件套。文档方面建议至少准备这几份需求分析说明书包括业务背景、角色定义、功能清单、用例图。数据库设计文档包括 ER 图、表结构说明、字段注释。系统设计文档包括技术架构图、接口设计、核心流程时序图。测试报告包括功能测试用例、测试结果截图、异常场景说明。部署文档包括环境要求、安装步骤、演示账号。答辩时不要照着 PPT 念需求一定要讲清楚三个问题你这个系统解决了什么具体问题你凭什么技术方案解决的你怎么证明它解决问题用这个思路组织你的讲解评委老师自然会觉得你做的是完整项目而不是一个空壳。我个人在给开发者做技术复核时最常看到的一个情况就是代码写得还行但讲不清设计思路。所以我建议你写开发日志每完成一个模块就简单记录一下“这个模块为什么这么设计有什么前置条件和哪些模块有联动”。等答辩前把这些日志整理一下就是现成的讲稿素材。技术能力是一回事能不能清楚表达是另一回事两者结合才是好毕设。