最近在整理一套宠物成长监管系统的完整交付物说实话这类项目在毕业设计和Java练手作品里出现频率相当高但真正能做精做透的不多。我基于JavaSpringBootSSM这套组合把宠物档案、成长记录、健康监测、疫苗提醒、饲养管理全部串成了一条完整业务闭环配套源码、LW论文文档、调试文档和讲解视频都整理好了。这篇文章不打算讲那些通篇概念的东西而是直接从我实际操作的角度把技术选型为什么这么做、数据库怎么建模才不返工、核心接口怎么落地、调试和答辩时最容易踩的坑一次讲清楚。如果你正准备做宠物健康监管系统、宠物饲养管理系统或者只是一个想用SpringBoot整合MyBatis做点正经东西的初级开发又或者是帮宠物门店做内部管理工具的小团队这篇文章都值得看完。我不光会写功能怎么实现更会解释每个关键选择背后的原因——比如为什么用SpringBoot还要提SSM为什么成长记录表必须留时间戳而不是只存日期为什么疫苗提醒不能只靠数据库查询。1. 项目定位与技术选型为什么是SpringBootSSM1.1 这套技术栈为什么能长期霸榜先说结论宠物成长监管系统这种业务典型的中小规模信息管理系统数据量不大、并发也不高但业务逻辑杂、功能模块多、开发周期短恰恰是SpringBootSSM这类单体应用最擅长处理的场景。在最初选型时我其实认真纠结过要不要上微服务毕竟现在搜索里随便一翻都是SpringCloud、分布式、高并发之类的词。但实际看下来一套给宠物主人和门店管理员用的系统撑死几十个并发你要是硬上一套微服务光服务拆分、配置中心、注册中心就够你折腾半个月。系统复杂度应该和业务复杂度匹配这是我一直坚持的原则。单体应用把所有功能放在一个工程里部署一个jar包就能跑调试时一步到位这对毕业设计和个人项目来说是真正的“性价比之选”。这里要特别解释一下“SpringBootSSM”到底是什么意思。很多新手一看就蒙了SpringBoot本身不是已经把Spring和SpringMVC包含进去了吗为什么还要说SSM实际上这个组合里的SSM指的是SpringSpringMVCMyBatis这套经典持久层方案。在传统SSM时代你要手写一堆XML配置数据源、配置事务管理器、配置Mapper扫描、配置视图解析器每一步都有可能踩坑。到了SpringBoot时代这些活大部分由自动装配完成你只需要加依赖、写配置、然后用注解把SpringMVC和MyBatis串起来。所以“SpringBootSSM”本质上是用SpringBoot这个底座去跑一套更精简、更现代的SSM栈。我见过不少人纠结另一个问题到底用官方MyBatis还是MyBatis-Plus。我的实际感受是如果业务里有大量单表CRUDMyBatis-Plus可以把Controller到Mapper的样板代码省掉一半分页、条件构造器也都现成。但如果你更关注SQL掌控力希望锻炼手写SQL的能力原生MyBatis配合XML也没什么问题。我这次用的是SpringBoot MyBatis-Plus的组合毕竟项目很快要交付效率放在第一位。1.2 版本选择千万别上来就追最新选版本这事我吃过不少亏。SpringBoot的版本迭代很快网上搜“springboot版本太高”这类问题时十有八九是依赖冲突或者配置类方法找不到。这次我选择了SpringBoot 2.7.x版本原因有三个稳定、生态成熟、跟MyBatis-Plus和相关套件兼容性好。很多人一上来就选SpringBoot 3.x结果发现javax包变成了jakarta包某些第三方组件还没适配项目连启动都困难。所以我建议除非你的项目必须用JDK17和虚拟线程这些新特性否则先求稳。我这里用的是JDK 8配套SpringBoot 2.7.18,mybatis-plus 3.5.3这套组合在大量生产项目里验证过出问题的概率最低。前端我这次没有做得很重因为后台系统的核心价值在后端接口和业务逻辑。我用了Thymeleaf服务端渲染做简单页面然后配了一个Vue的轻量管理端如果你只是想快速跑通Thymeleaf就够了如果毕设需要展示前后端分离VueSpringBoot是主流但要注意后端跨域配置和Token鉴权。2. 功能模块拆解与业务闭环设计2.1 用户端要做什么宠物成长监管系统核心用户是宠物主人和宠物门店/医院工作人员。用户端最基本的功能包括登录注册、宠物档案管理、成长记录、健康记录、疫苗提醒、饲养记录。登录注册就不多说了正常做就行。宠物档案是整个系统的地基字段包括宠物名称、品种、性别、出生日期、是否绝育、初始体重、主人信息。这里我特别提醒出生日期和年龄别只存一个年龄字段因为年龄是动态变化的会随时间推移而失真用出生日期计算才是正解。成长记录是整个系统的灵魂我把它看作宠物版的“时间序列数据”。每次记录时采集体重、体长、胸围、体温、精神状态、毛色状态、当次照片再加上一条备注。为什么这些字段重要因为宠物是否健康不能只看一次数据要看趋势。比如一只猫连续三周体重下降系统就应该给主人一个健康预警提示。健康记录则是一个“事件型”数据比如宠物生病了、做了手术、有了异常症状都要在这里登记内容包含就诊时间、症状描述、诊断结果、用药记录、下次复诊时间。疫苗记录也是类似不过它天然带着“到期时间”属性和提醒逻辑结合得非常紧密。饲养管理模块我做了喂食记录和饮水记录两个子模块。喂食记录里记录食物品牌、种类、克数、时间点这样长期下来可以分析出宠物的饮食规律和食欲变化。如果宠物食欲持续下降配合健康记录基本能提前发现问题。2.2 管理端要做什么管理端的核心是给门店或管理员提供运营视图。我设计了几个管理功能用户管理、宠物总览、健康预警列表、疫苗接种到期列表、数据统计看板。用户管理就是查看所有注册用户和他们的宠物支持按手机号、宠物名模糊搜索。宠物总览可以看全部宠物档案也可以按品种、性别、是否绝育做筛选。健康预警列表更偏实用它会把体重异常下降、连续多天未记录、体温异常这些情况集中展示管理员可以一键联系主人。数据统计看板是我很推荐的加分项。用ECharts展示宠物数量趋势、品种占比、健康状态分布、疫苗接种率。别小看这个看板答辩或者给门店老板做汇报的时候一个直观的可视化比十页Word文档都更能说明问题。2.3 提醒闭环是关键很多系统挂在这很多类似系统做完了功能都有但用起来总觉得“不智能”问题就出在提醒闭环上。宠物成长监管系统除了记录更重要的价值在“主动提醒”。我定义了三个维度的提醒疫苗接种提醒、体检/复诊提醒、日常记录缺失提醒。疫苗提醒根据疫苗记录里的下次接种日期提前7天和当天各提醒一次。体检提醒是管理员后台统一配置比如三个月体检一次。日常记录缺失提醒则是检测主人连续超过3天没有新增成长记录就推送消息让主人补录。这个闭环为什么重要因为宠物健康数据如果不持续采集做出来的趋势分析就是无源之水。我把提醒任务用Spring的Scheduled定时任务配合数据库查询来实现每天凌晨跑一次扫描把满足条件的提醒写入消息表用户在登录后就能看到待办事项。3. 数据库设计成长数据怎么建模才不返工3.1 核心表清单数据库设计在整个项目中我认为是比代码更重要的一环。宠物成长监管系统的核心表我梳理出来大概有下面这几张表名作用关键字段user用户表存宠物主人信息id, username, password, phone, real_namepet_info宠物档案表id, user_id, pet_name, breed, gender, birth_date, neuter_status, avatargrowth_record成长记录表id, pet_id, record_date, weight, body_length, chest_size, temperature, status, photo_url, remarkhealth_record健康记录表id, pet_id, symptom, diagnosis, treatment, visit_date, next_visit_datevaccine_record疫苗记录表id, pet_id, vaccine_name, inoculate_date, next_date, vet_namefeed_record喂食记录表id, pet_id, food_name, food_amount, feed_time, notesremind_task提醒任务表id, pet_id, remind_type, remind_date, content, status这套表设计的原则概括起来就是“主体表流水表”。pet_info是主体表描述宠物这个静态对象growth_record、health_record、feed_record是流水表记录围绕主体的动态事件。这个设计的好处是查询灵活要分析宠物成长趋势就按pet_id和时间取grow_record要看某只宠物一生的健康经历就按pet_id查health_record两张表各司其职不会混在一张巨型表里。3.2 建表SQL与字段说明我实际用的建表SQL核心部分是这样的CREATE TABLE pet_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 主键ID, user_id BIGINT NOT NULL COMMENT 所属用户ID, pet_name VARCHAR(50) NOT NULL COMMENT 宠物名称, breed VARCHAR(50) COMMENT 品种, gender TINYINT COMMENT 性别0公 1母, birth_date DATE COMMENT 出生日期, neuter_status TINYINT DEFAULT 0 COMMENT 是否绝育0否 1是, avatar VARCHAR(255) COMMENT 头像URL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, deleted TINYINT DEFAULT 0 COMMENT 逻辑删除0正常 1删除, KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT宠物档案表; CREATE TABLE growth_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 主键ID, pet_id BIGINT NOT NULL COMMENT 宠物ID, record_date DATE NOT NULL COMMENT 记录日期, weight DECIMAL(5,2) COMMENT 体重kg, body_length DECIMAL(5,2) COMMENT 体长cm, chest_size DECIMAL(5,2) COMMENT 胸围cm, temperature DECIMAL(4,2) COMMENT 体温℃, mental_state TINYINT COMMENT 精神状态1差 2一般 3良好, hair_state TINYINT COMMENT 毛色状态1差 2一般 3良好, photo_url VARCHAR(255) COMMENT 照片URL, remark VARCHAR(500) COMMENT 备注, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, KEY idx_pet_date (pet_id, record_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT成长记录表;注意到growth_record表里我建的是联合索引idx_pet_date(pet_id, record_date)这个索引非常关键。因为系统里最常见的查询就是“查某只宠物某段时间的成长记录”有了这个索引MySQL可以直接按pet_id定位再按record_date排序效率非常高而且天然避免了filesort。索引建得好不好在数据量小的时候看不出来到几万条记录之后就会天差地别。所有表我都加了deleted逻辑删除字段、create_time和update_time。为什么要逻辑删除而不是物理删除因为宠物健康数据属于过程数据如果你删了历史趋势就断了而且一旦误删很难找回。逻辑删除只是在查询时统一加一个deleted0条件配合MyBatis-Plus的TableLogic注解操作成本很低换来的是安全性和可追溯性。3.3 主键、时间字段和字符集三件容易被忽视的事主键我统一用BIGINT自增而不用UUID。虽然UUID在分布式环境下有优势但在这种单体系统里UUID的随机性会导致索引页频繁分裂写入性能变差而且主键太长还会让二级索引变大。自增主键是顺序写入性能最好在座各位如果是新手别被网上那些“分布式ID”的文章带偏了先分清适用场景。字符集一定要用utf8mb4不要用utf8。utf8在MySQL里最多存3个字节遇到表情符号就会报错而现在的宠物主人给宠物起名、写备注动不动就用emoji用utf8mb4才能完整存储。连接数据库的JDBC URL里也必须带上characterEncodingutf8否则中文很容易变问号。时间字段方面我坚持用DATETIME而不用TIMESTAMP。因为TIMESTAMP的范围到2038年就截止了虽然短期用不会出问题但作为一套可能长期维护的系统没必要埋这个雷DATETIME的存储范围明显更宽松。4. 后端实现SpringBootSSM组合拳4.1 工程结构与分层思想后端工程我建议按经典的三层架构组织Controller负责接收请求和返回结果Service负责业务逻辑Mapper负责数据库操作。我实际用的包结构如下com.pet.demo ├── controller // 接口层只做参数接收和结果返回 ├── service // 业务逻辑层 │ └── impl ├── mapper // MyBatis Mapper接口 ├── entity // 实体类对应数据库表 ├── dto // 数据传输对象 ├── vo // 视图返回对象 ├── config // 配置类跨域、定时任务等 ├── common // 统一返回体、全局异常等 └── utils // 工具类很多朋友一开始会把业务逻辑全写在Controller里接口方法上百行这种写法当时跑得通后面加需求、做调试就非常痛苦。我给的这套分层核心思想就是“Controller薄、Service厚”。Controller只管拿到参数、调用Service、把VO返回给前端真正的判断、计算、事务都在Service里。这样不管将来是加接口还是换前端框架Service层都不需要动。4.2 统一返回体和全局异常处理接口设计上我用了统一的返回体Result 前端的每个请求都能拿到固定的数据结构。这样做的好处是前端处理逻辑统一不用每个接口单独判断字段代码一眼就能看懂。Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }全局异常处理我用RestControllerAdvice来实现好处是所有Controller抛出的异常都统一在这里处理不让异常页面直接暴露给前端。我捕获了业务异常、参数校验异常、数据库异常分别返回不同的提示信息。最表面的收益是前端拿到的永远是好解析的JSON底层的收益是排查问题时能通过日志和异常类型一眼定位。4.3 宠物档案与成长记录接口实现宠物档案模块是典型的CRUD但我把“增删改查”做成了更适合业务理解的样子。新增宠物时Service层会先校验用户是否存在、宠物名是否重复然后才写入数据库。下面是我Controller层的一个核心接口例子它处理的是“分页查询当前用户的宠物列表”RestController RequestMapping(/api/pet) public class PetController { Autowired private PetService petService; GetMapping(/list) public ResultPageResultPetVO list(RequestParam Long userId, RequestParam(defaultValue 1) Integer pageNum, RequestParam(defaultValue 10) Integer pageSize) { // 实际逻辑在Service层 PageResultPetVO result petService.pagePetList(userId, pageNum, pageSize); return Result.success(result); } PostMapping(/add) public ResultVoid add(RequestBody Valid PetAddDTO dto) { petService.addPet(dto); return Result.success(null); } }成长记录模块是我重点做的。新增成长记录时除了把记录本身插进growth_record我还会同时做两件事查询最近一条历史记录计算体重环比变化如果体重下降超过上一期的5%且精神状态评分低于3就自动生成一条健康预警提醒写入remind_task表。这段业务逻辑是宠物健康监管系统的“智能化”核心也是答辩时评委最感兴趣的地方。Service Transactional public class GrowthRecordServiceImpl implements GrowthRecordService { Override public void addGrowthRecord(GrowthAddDTO dto) { // 1. 插入成长记录 GrowthRecord record new GrowthRecord(); BeanUtils.copyProperties(dto, record); this.save(record); // 2. 查询上一条记录计算体重变化 GrowthRecord lastRecord this.getLastByPetId(dto.getPetId()); if (lastRecord ! null lastRecord.getWeight() ! null dto.getWeight() ! null lastRecord.getWeight() 0) { BigDecimal rate dto.getWeight() .subtract(lastRecord.getWeight()) .divide(lastRecord.getWeight(), 4, BigDecimal.ROUND_HALF_UP); if (rate.compareTo(new BigDecimal(-0.05)) 0) { // 体重下降超5%生成预警 this.createHealthWarning(dto.getPetId(), 体重连续下降请关注宠物饮食与精神状态); } } } }这里有个事务细节为什么加Transactional因为新增记录和生成预警是两个数据库操作任何一个失败都不能留下半截数据。Spring事务默认只在RuntimeException下回滚如果方法里抛的是受检异常事务不会回滚——这个坑非常隐蔽我在这个项目里踩过一次后面在调试文档里专门写了一条警示。4.4 疫苗提醒与定时任务疫苗提醒是我觉得这个系统最容易被夸“贴心”的地方。疫苗记录里存了下一次接种日期next_date我用SpringBoot的Scheduled定时任务每天凌晨2点扫描一次把未来7天内需要接种的宠物找出来生成提醒任务。代码如下Component public class VaccineRemindTask { Autowired private VaccineRecordService vaccineRecordService; Autowired private RemindTaskService remindTaskService; Scheduled(cron 0 0 2 * * ?) public void scanVaccineDate() { Date today new Date(); Date sevenDaysLater DateUtils.addDays(today, 7); ListVaccineRecord list vaccineRecordService .findByNextDateBetween(today, sevenDaysLater); for (VaccineRecord record : list) { RemindTask remind new RemindTask(); remind.setPetId(record.getPetId()); remind.setRemindType(1); // 1疫苗提醒 remind.setRemindDate(record.getNextDate()); remind.setContent(您的宠物需要接种 record.getVaccineName() 请尽快安排); remind.setStatus(0); remindTaskService.save(remind); } } }定时任务要想方便控制开关我建议在配置文件中加一个开关属性比如remind.enabledtrue然后在定时任务类上用ConditionalOnProperty来配合这样部署到测试环境时可以临时关闭不至于每天被打扰。另外一个容易忽略的问题定时任务如果处理时间较长默认只会有单线程串行执行万一任务没跑完下一个时间点又来了可能会堆积。我这里相对简单扫描逻辑快所以没有用分布式锁。但如果你后期把系统部署到多台服务器上同一个定时任务会在每台机器都执行一遍那时候就必须引入分布式锁方案了。5. 调试、文档交付和常见坑5.1 调试环境三项必查这个项目在我实际调试过程中遇到过几个高频问题首先就是数据库连接问题。如果项目启动时提示Cant connect to MySQL或Access denied八成是数据源配置不对。我这里用的配置是spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/pet_system?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456serverTimezoneAsia/Shanghai这个参数非常关键。MySQL驱动8.x版本要求必须指定时区否则会报Server returns invalid timezone错误。时区设置不对还会导致时间数据差8小时这是很多朋友头疼的“查询时间总不对”的元凶。其次要查的是Maven依赖版本。搜索里总有“springboot版本太高”、“maven项目构建方法”这些问题我这次的踩坑记录是MyBatis-Plus的SpringBoot3适应版本叫mybatis-plus-spring-boot3-starter而不是老版本的mybatis-plus-boot-starter。如果你用的是SpringBoot2.7.x就只能用后者两者名字不同混用会导致自动配置不生效。第三如果启动后出现白名单报错或Mapper相关报错先检查启动类上的MapperScan注解。我习惯在启动类上写MapperScan(com.pet.demo.mapper)这样MyBatis就能自动扫描到Mapper接口。如果你之前写过加载XML文件的mybatis.mapper-locations配置请确保XML里的namespace和接口全限定名完全一致。5.2 LW论文文档怎么组织才不空洞说起LW很多人的文档是到最后一天才开始赶结果写出来通篇是“系统功能强大、技术先进”这类空话。我总结的文档结构是直接跟着开发流程走的第一章是绪论写背景和意义第二章是需求分析把用户需求拆成功能模块列表第三章是系统设计先画总体架构再画功能结构然后是数据库设计第四章是实现对应每个模块的核心代码和截图第五章是测试写几个测试用例和结果最后是总结和展望。我特别提醒文档里的数据库设计部分不要只贴建表SQL要把每个表的每个字段含义说明白还要画ER图。很多人以为ER图是形式工作其实不然它是评委快速理解你整个系统数据关系的最好入口。我用的工具是PowerDesigner和draw.io都是很常见的免费版也够用。调试文档这里多说一句。我把配置怎么改、数据库导入怎么做、启动顺序是什么、常见报错怎么解决全部写成了一个README级别的手册。这份东西不仅我自用也在和同学交接项目时省了无数口水——你写完代码三个月后自己可能都会忘了某个启动项的配置调试文档就是你大脑的外挂。5.3 高频报错排查速查表我把自己跑这套系统时遇到的高频问题整理成了一张表每个情况都有具体的解决思路现象可能原因解决办法接口返回中文问号JDBC URL缺少characterEncodingutf8在数据源URL中强制指定utf8登录接口空白无响应跨域配置缺失或session失效配置CorsFilter检查请求是否携带Cookie时间字段差8小时数据库时区与JVM时区不一致统一设置serverTimezoneAsia/Shanghai修改数据后查询没变化遇到MyBatis二级缓存或事务未提交排查Transactional范围清缓存或重启编写定时任务不执行启动类未加EnableScheduling在启动类或配置类显式开启定时任务前端传的参数后端拿不到实体类没有无参构造或字段名不一致检查Data注解对比JSON字段名和实体属性表字段deleted逻辑删除不生效实体未加TableLogic注解在实体逻辑删除字段上添加TableLogic其中“修改数据后查询没变化”这个坑我印象最深。有一次帮朋友排查他在Service方法里insert了一条记录然后立刻调用另一个Mapper方法去查询汇总数据结果返回的还是没有新记录的数。我一看发现他把两个操作都写在一个方法里但先执行的那个查询Mapper在一个事务里却因为MyBatis的一级缓存把同一条SQL的查询结果缓存了第二次查询没有刷新。后来通过清掉SqlSession缓存并让查询走新的SQL问题才解决。这个细节如果不懂缓存机制真的很难排查。6. 让系统更好用的一点个人建议6.1 加入导出与可视化整体质感立刻不一样系统基本功能跑通之后我强烈建议加上报表导出和可视化图表。这个系统如果只是个“录入查询系统”说实话和Excel表格没太大差别但一旦把成长趋势做成折线图把体重变化、疫苗到期情况做成图表展示整个系统的专业度立刻就不一样了。我用的是ECharts它上手快、图表类型丰富。后端提供统计接口返回某只宠物近半年的体重序列前端直接渲染。代码倒是次要的关键是思路趋势图不是简单地画数据点而是要把“异常波动”高亮出来。比如体重大幅度下降的时间点用红色标记这样使用者一眼就能看出问题区间这个设计在评审时非常加分。Excel导出方面我用的是阿里EasyExcel代码量极小。核心接口就是查询列表、写入OutputStream、设置响应头前端拿到文件流后下载。导出的内容至少包含宠物基本信息表、成长记录表、疫苗记录表三张覆盖系统的主要数据。用户用起来会感觉很完整有点像“系统能出报告了”的感觉。6.2 留好扩展点别把路堵死最后一个建议是给代码留扩展点。我这次系统做下来最大的心得就是硬编码一时爽维护火葬场。比如宠物状态、精神状态这些字段我全部用字典值来管理在数据库里建一张dict表而不是把“1代表良好”直接写死在代码里。这样后续要增加“极好”“较差”这类状态只需加字典数据不用改代码。文件上传路径也要做成可配置的不要把图片存到项目内部绝对路径万一将来要迁移服务器路径一换就全乱了。我把上传文件路径配置在application.yml里用相对路径存储数据库记录相对URL这样做最灵活。消息推送的渠道也尽量抽象成接口。目前用的是站内信提醒但后续完全可能接入微信公众号推送或短信服务。我在提醒模块定义了一个MessageSender接口现在实现类是本地Sender以后再扩展连Service层的调用点都不需要改。把系统交付出去之前的检查清单文章最后把我每次交付这套系统前必做的一套检查罗列出来省得到现场翻车先清测试数据保留几条演示数据确保一只宠物有你完整成长记录方便展示趋势图。启动前确认MySQL库名、用户名、密码和配置完全一致。上传功能测试一下确认图片真的能存储、能访问。定时任务记得等时间跑一遍别在演示时才发现提醒记录是空的。最后把数据库导出成SQL文件连同项目压缩包一起放到交付目录并在调试文档里写明导入步骤。这些听起来都是小事但任何一个环节出问题都可能让你在评审或客户面前很被动。根据我个人经验把上面这些检查项走一遍大概率比临时抱佛脚背十遍代码有效得多。这套系统做完之后我明显感觉到真正让你成长的不是某个框架新特性而是把每一个平凡功能都做成完整的业务闭环再把这个闭环打磨到顺手。希望这篇文章能帮你把宠物成长监管系统做成一个真正“能跑、能讲、能交付”的东西。
