简介基于Spring Boot与Vue实现的一套宠物管理系统完整项目面向Java毕业设计、课程作业以及前后端开发初学者适合需要快速掌握业务系统整体构建流程、完成相似管理功能开发的读者参考。压缩包共471个文件整体约10.81MB包含154个Java后端源码和111个Vue前端组件另有JavaScript、CSS、XML等资源与配置以及SQL数据库脚本、YML环境配置和DOC说明文档能方便地初始化数据库并启动项目。已有132人学习使用。系统按常见管理业务划分模块包括用户注册登录与角色权限、宠物档案添加编辑与照片上传、健康档案与疫苗接种提醒、服务预约与评价、社区论坛与私信互动、日志审计与数据备份恢复等。通过学习该资源可直观理解Spring Boot接口与Vue页面的数据交互体会权限控制和业务分层的实现方式也能为课程设计报告撰写、系统功能演示提供完整的可运行示例。1. 一个宠物管理系统卡在前台 Excel 里的管理系统很多宠物医院、宠物店的前台到现在还在用 Excel 记宠物档案姓名、品种、疫苗日期、上次就诊记录全堆在几张表里查一次要翻半天换个电脑还得靠微信传文件。java宠物管理系统 设计与实现这个方向解决的就是这种「信息在表格里但不在业务里」的尴尬——用一套 Java Web 系统把宠物档案、预约、病历、疫苗接种提醒串起来让前台能查、医生能写、老板能看统计。这篇笔记按我实际做过的方案讲清楚技术选型为什么是 Spring Boot MyBatis、数据库怎么设计才能扛住后续扩展、核心功能的关键代码怎么写、以及那些不跑一遍根本发现不了的坑。适合正在做课程设计或毕业设计的同学也适合想拿管理系统练手 Java 后端的小团队。2. 技术选型Spring Boot MyBatis JWT哪里比老牌 SSM 更适合这个规模2.1 为什么是 Spring Boot 而不是 SSH 或 SSM早期做管理系统教科书里常见 Struts Spring Hibernate后来流行 SSMSpring Spring MVC MyBatis。这两个方案不是不能做宠物管理系统但你会发现大量时间花在「配置」而不是「业务」上。XML 里写一堆 bean 定义、数据源、事务管理器还没开始写宠物档案先折腾了两天环境——尤其是新手跟着教程走卡在 xml 命名空间报错的情况太多了。换成 Spring Boot 之后内嵌 Tomcat、自动配置、约定优于配置一个 main 方法起来就是一个可运行的 Web 服务这对「设计与实现」这种需要快速看到效果的项目来说价值非常大。我在选型时一般遵循两条原则第一团队里最熟的人用什么就用什么不要为了简历好看引入没人能维护的技术第二项目规模决定复杂度宠物管理系统的核心是宠物档案 CRUD、预约流程、病历记录、接种提醒这些用 Spring Boot MyBatis 已经覆盖得非常好杀鸡用不上微服务那一套。如果你在写毕业设计答辩老师问「为什么不用 SSH」回答「SSH 的配置成本高Spring Boot 的自动配置和生态更适合快速落地业务且社区活跃、遇到问题容易查」就是很稳的答案。2.2 工程分层与包结构设计做「设计与实现」类的项目最怕的是所有代码堆在 controller 里一按 CtrlShiftF 满屏的重复代码。这个项目我建议按常见的四层结构拆com.petms ├── controller // 接收 HTTP 请求做参数校验和结果封装 ├── service // 业务逻辑层事务边界在这里 ├── mapper // MyBatis 数据访问层对应数据库表 ├── entity // 数据库实体类 ├── dto // 与前端交互的数据对象避免直接暴露实体 ├── config // 全局配置JWT 拦截器、跨域、WebMvc 配置 ├── common // 统一返回结果、异常处理、常量 ├── utils // 工具类JWT 工具、日期工具 └── PetApplication.java这个结构对应的是「controller 只做转发和校验service 处理业务mapper 只管 SQL」的原则。县体到宠物管理系统宠物档案的新增可以拆成controller 接收 PetDTO 并校验必填项、service 层判断宠物主人是否存在并写入宠物表、mapper 执行 insert 语句。这样做的好处是后续加「同一主人最多登记 5 只宠物」这种规则时只改 service 层不碰 controller 和 mapper。有个容易被忽略的细节点entity 直接用 MyBatis-Plus 的注解映射数据库表而 controller 层接收的是 DTO两者不要混用。有个容易被忽略的细节点是entity 里的数据类型不要用基础类型 int、long要用包装类型 Integer、Long否则查询结果为空时会因为自动拆箱抛空指针异常。比如宠物表有个 owner_id 字段数据库为空时 MyBatis 会映射成 null实体类是 int 的话直接 NPE。2.3 认证选型JWT 还是 Session宠物管理系统的用户分两类前台接待和医生。权限其实不复杂但一定要有登录态校验否则任何人都能调接口删档案。Session 方案简单但前后端分离部署时跨域要处理 Cookie而且集群部署时要引入 Redis 共享 Session——对于这个规模有点重。我用 JWTJSON Web Token的常见做法用户登录成功后生成一个带过期时间的 token 返回给前端前端每次请求在 Header 里带 token后端用一个拦截器解码 token 并校验用户身份。JWT 在宠物管理系统这种内部系统里的好处是「无状态」后端不需要存 Session重启服务不丢登录态扩展多实例时也不用配置 Session 同步。坑在于 token 一旦签发在过期之前是控制不了的所以过期时间不要设太长管理后台的场景 8 小时比较合适。另外校验 token 的拦截器要排除登录接口和静态资源不然用户第一次访问就被拦在门外。拦截器里拿到用户信息后放到 ThreadLocal 或直接塞进请求参数service 层再拿去读当前的用户 id用来做操作日志的登记人字段。3. 数据库设计五张表撑起宠物档案与就诊闭环3.1 核心表拆解owner、pet、record、appointment、vaccination宠物管理系统的数据库设计是整个项目的根基。表设计错了后面写代码全是补丁。我按业务闭环拆成五张核心表宠物主人表owner、宠物表pet、就诊记录表medical_record、预约表appointment、疫苗接种表vaccination。为什么不把宠物和主人的信息塞在一张表里因为一个主人可以带多只宠物来就诊一对多在这种场景里是明确的业务语义拆成两张表后续统计「每位主人名下的宠物数」就是一条 group by 的事情。owner 表除了姓名、电话、地址外至少要有 created_time 和 updated_time 两个时间字段。pet 表的关键字段是 name、breed、gender、birthday、weight、owner_id其中 owner_id 是外键语义。medical_record 表记录每次就诊的病情描述、诊断结果、用药信息、就诊医生、就诊时间。appointment 表处理预约排期预约日期、时间段、预约项目、状态待确认/已完成/已取消。vaccination 表记录疫苗名称、接种日期、下次接种日期——这个表是后续做接种提醒的数据来源。3.2 建表 SQL 与字段含义说明直接给一段可执行的 DDL注意我在字段注释里写了业务含义这个习惯在答辩和交接时很加分。CREATE TABLE owner ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, name VARCHAR(50) NOT NULL COMMENT 主人姓名, phone VARCHAR(20) NOT NULL COMMENT 联系电话预约提醒用, address VARCHAR(255) DEFAULT NULL COMMENT 家庭地址, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 逻辑删除标记0正常 1删除, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT宠物主人表; CREATE TABLE pet ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, owner_id BIGINT NOT NULL COMMENT 所属主人idowner表主键, name VARCHAR(50) NOT NULL COMMENT 宠物昵称, breed VARCHAR(50) DEFAULT NULL COMMENT 品种如英短、金毛, gender TINYINT DEFAULT NULL COMMENT 性别0公 1母, birthday DATE DEFAULT NULL COMMENT 出生日期用来计算年龄, weight DECIMAL(5,2) DEFAULT NULL COMMENT 体重kg, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 逻辑删除标记, PRIMARY KEY (id), KEY idx_owner_id (owner_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT宠物信息表;字段类型上有几个要留意的点。owner 表的 phone 用 VARCHAR(20) 而不是 VARCHAR(11)因为座机、区号、国际号码都可能出现别把长度卡死。pet 表的 gender 用 TINYINT 而不是 CHAR(1)避免「公母」的中文编码问题展示时在前端做映射。weight 用 DECIMAL(5,2) 而不是 FLOAT浮点数做金额和体重计算会出现 0.10.2 不等于 0.3 的问题DECIMAL 是精确数值类型。create_time 和 update_time 用 DATETIME 并且设置默认值这样 insert 的时候不需要手动 set 时间MyBatis-Plus 的插入逻辑也不用关心这个字段。3.3 外键到底要不要建很多教材强调外键约束但在实际项目中我基本不建物理外键。原因有三个第一数据库在做删除和更新时会多一次约束检查影响写入性能第二业务上做逻辑删除deleted 字段标记之后物理外键与逻辑删除天然冲突——你删不掉「已删除」的数据外键约束就成了摆设第三MyBatis-Plus 的 mapper 层操作单表时有物理外键反而要多维护一句。所以 pet 表里的 owner_id 只是逻辑上的外键靠 service 层去保证「插入宠物前先确认 owner 存在」。这个设计在答辩时容易成为提问点。回答思路是物理外键保证的是数据库层面的引用完整性但在逻辑删除、分库分表、性能优化这些真实约束下引用完整性交给应用层代码更可控。service 层新增宠物时校验 owner_id 是否存在删除主人时先查有无名下宠物、有则提示先转移或删除宠物——这条规则写在 service 是显式的写在外键约束里是隐式的出问题排查起来前者快很多。3.4 MyBatis-Plus 的实体映射与自动填充用 MyBatis-Plus 时实体类和表的映射有两种方式驼峰自动映射和注解指定。强烈建议实体字段名与数据库字段名完全对应或者开启驼峰转换否则每次查询都要写 resultMap。我用的是注解方式因为数据库字段是下划线风格实体类字段是驼峰风格配置了 map-underscore-to-camel-casetrue 之后owner_id 自动映射到 ownerId不需要额外代码。自动填充是 MyBatis-Plus 一个非常实用的能力。实体类里 createTime 和 updateTime 这两个字段每次 insert 和 update 都要手动 set 当前时间代码重复度高。用 TableField(fill FieldFill.INSERT) 和 fill FieldFill.INSERT_UPDATE 注解标记字段再实现 MetaObjectHandler 接口在 insertFill 和 updateFill 方法里统一填充时间。配合前面 DDL 里 DEFAULT CURRENT_TIMESTAMP双保险任何一条写入路径都不会漏时间字段。这也是 MyBatis-Plus 根据实体类生成建表 SQL 的底层基础——实体字段注解完整数据库表才建得干净。4. 核心功能落地宠物档案、预约排期与接种提醒的三段代码4.1 宠物档案新增与分页查询三层代码的完整链路先讲宠物档案的新增这是理解 Controller → Service → Mapper 三层调用关系最直观的入口。我把校验逻辑放在 controller 层做基础校验必填字段、格式把业务校验放在 service 层主人是否存在、名下限重这样职责清晰。下面是新增宠物的核心代码PostMapping(/pet) public ResultLong createPet(RequestBody Valid PetCreateDTO dto) { // 基础校验由 Valid 完成这里直接进入业务层 Long petId petService.createPet(dto); return Result.success(petId); }Service Slf4j public class PetServiceImpl implements PetService { Autowired private PetMapper petMapper; Autowired private OwnerMapper ownerMapper; Override Transactional(rollbackFor Exception.class) public Long createPet(PetCreateDTO dto) { // 业务校验主人必须存在且未删除 Owner owner ownerMapper.selectById(dto.getOwnerId()); if (owner null || owner.getDeleted() 1) { throw new BizException(宠物主人不存在); } // 同一主人名下宠物数量上限防止一个人登记 50 只宠物 Long count petMapper.selectCount( new LambdaQueryWrapperPet().eq(Pet::getOwnerId, dto.getOwnerId())); if (count 5) { throw new BizException(同一主人最多登记5只宠物); } Pet pet new Pet(); BeanUtils.copyProperties(dto, pet); // 属性拷贝简写 petMapper.insert(pet); return pet.getId(); } }这段代码里有几个关键设计。Transactional(rollbackFor Exception.class) 声明事务注意括号里的 rollbackFor 必须写否则 Spring 默认只对运行时异常回滚像 BizException 这种自定义异常如果继承 Exception事务不会生效。业务校验写在 service 而不是 controller是因为这类规则可能被多个接口复用——比如后台导入宠物数据时同样要走「主人存在」的校验。BeanUtils.copyProperties 把 DTO 属性拷到实体类避免 controller 直接把 DTO 传进 mapper防止前端多传字段覆盖数据库值。MyBatis-Plus 的 insert 方法会自动回填自增主键到 pet.getId()所以返回的 id 不需要手动查。分页查询是列表页的高频操作。MyBatis-Plus 的分页插件配好后查询代码很简单Override public PageResultPetVO pagePets(PetQueryDTO query) { PagePet page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperPet wrapper new LambdaQueryWrapper(); // 关键字搜索宠物名或主人姓名模糊匹配 if (StringUtils.hasText(query.getKeyword())) { // 这里关联 owner 表的姓名需要子查询或连表见下方说明 wrapper.and(w - w.like(Pet::getName, query.getKeyword())); } if (query.getBreed() ! null) { wrapper.eq(Pet::getBreed, query.getBreed()); } // 逻辑删除过滤是 MyBatis-Plus 自动处理的deleted0 自动拼接 wrapper.orderByDesc(Pet::getCreateTime); PagePet result petMapper.selectPage(page, wrapper); // 实体转 VO补充主人姓名、年龄等展示字段 ListPetVO voList result.getRecords().stream() .map(pet - convertToVO(pet, ownerMapper)) .collect(Collectors.toList()); return new PageResult(result.getTotal(), voList); }分页查询最容易踩的坑是「按主人姓名搜宠物」pets 表没有 owner_name 字段不能直接在 wrapper 里 like。常见做法有两种如果搜索频率不高先查 owner 表拿到符合条件的 owner_id 列表再 in 到 pet 查询里如果搜索是核心功能直接在 pet 表冗余 owner_name 字段写入时同步更新。我在这类系统里一般选择冗余字段宠物表加 owner_name 和 owner_phone虽然违反了一点范式但查询走单表、索引友好比起 join 的性能收益明显。分页插件配置时注意要引入 MyBatis-Plus 的 PaginationInnerInterceptor否则 selectPage 分页不生效返回全量数据——这个是新手最容易困惑的「配置了但没生效」问题。4.2 预约排期的状态机与冲突校验预约管理比档案管理复杂在「状态」上。一个预约至少有四种状态待确认、已确认、已完成、已取消。我用一个 int 字段 status 存储用常量类定义状态值。修改状态时核心是校验状态流转是否合法——已完成的预约不能直接改成已取消已取消的不能变成已确认。public void cancelAppointment(Long appointmentId, Long currentUserId) { Appointment appointment appointmentMapper.selectById(appointmentId); if (appointment null) { throw new BizException(预约不存在); } // 状态机校验只有待确认和已确认状态可以取消 if (appointment.getStatus() ! AppointmentStatus.PENDING appointment.getStatus() ! AppointmentStatus.CONFIRMED) { throw new BizException(当前状态不允许取消); } Appointment update new Appointment(); update.setId(appointmentId); update.setStatus(AppointmentStatus.CANCELLED); update.setCancelReason(用户取消); update.setUpdateBy(currentUserId); appointmentMapper.updateById(update); }预约冲突校验是另一个要点同一时间段、同一医生不能同时接两个预约。实现时不要在应用层去循环比对直接在 SQL 层判断// 检查是否已有冲突预约 Long conflict appointmentMapper.selectCount( new LambdaQueryWrapperAppointment() .eq(Appointment::getDate, dto.getDate()) .eq(Appointment::getTimeSlot, dto.getTimeSlot()) .eq(Appointment::getDoctorId, dto.getDoctorId()) .in(Appointment::getStatus, AppointmentStatus.PENDING, AppointmentStatus.CONFIRMED)); if (conflict 0) { throw new BizException(该时间段已有预约请选择其他时间); }这个方案的关键在于状态列表参数已取消和已完成的预约不应该阻塞新的预约。另外数据库层面给 (doctor_id, date, time_slot, status) 加一个联合唯一索引做不到因为 status 是可变的所以只能靠应用层校验兜底——这个场景下并发冲突的概率很低应用层校验已足够。真要搞分布式锁就是过度设计了管理系统的不需要那么高的并发保障。4.3 疫苗接种提醒的定时任务实现接种提醒是整个系统里「增值」的功能查询下次接种日期在 7 天内的宠物给主人发送提醒通知。这段逻辑适合用 Spring 的 Scheduled 来做定时扫描。注意两点任务要加分布式部署保护加一个开关只在指定实例执行避免多实例重复发提醒。Component Slf4j public class VaccinationReminderTask { Autowired private VaccinationMapper vaccinationMapper; Autowired private RemindService remindService; Scheduled(cron 0 30 8 * * ?) // 每天早上 8:30 执行 public void sendReminder() { LocalDate today LocalDate.now(); LocalDate endDate today.plusDays(7); // 查询下次接种日期落在今天7天内的记录 ListVaccination list vaccinationMapper.selectList( new LambdaQueryWrapperVaccination() .between(Vaccination::getNextVaccineDate, today, endDate) .eq(Vaccination::getReminded, 0)); for (Vaccination v : list) { // 查询宠物和主人信息组装提醒内容 try { remindService.sendRemindMessage(v); v.setReminded(1); // 标记已提醒避免下次重复发送 vaccinationMapper.updateById(v); } catch (Exception e) { log.error(接种提醒发送失败, vaccinationId{}, v.getId(), e); } } } }定时任务有一个细节cron 用的是服务器时区如果部署在云上要注意时区设置否则 8:30 的提醒可能在北京时间 16:30 才发出去。另一个坑是「明天到期未接种」的记录不能只查一次就标记 reminded1而应该在发送成功后标记发送失败的保留待下次重试。上述代码里 catch 块只记录日志、不标记就是这个原因。系统上线后加一个「手动触发提醒」的接口用来补发漏掉的提醒这是运维侧的后悔药很有必要。5. 避坑排查宠物管理系统中 5 个常见坑与修复路径5.1 分页查询的总记录数一直是 0查了列表却不翻页现象列表接口能返回数据但 total 字段总是 0前端分页组件显示「共 0 条」。原因MyBatis-Plus 分页插件没有注册或者说 PaginationInnerInterceptor 没有放进 MybatisPlusInterceptor 里。很多人只加了 mybatis-plus-boot-starter 依赖以为分页就是 selectPage 自带的能力。解决配置一个 Bean 注入 MybatisPlusInterceptor添加 PaginationInnerInterceptor设置 DbType.MYSQL。还有一个更隐蔽的问题分页插件和自定义拦截器有顺序要求插件要在最外层。5.2 联表查询和逻辑删除大战查出来的数据莫名少了几条现象连表查询 medical_record 和 pet 时发现 join 出来的记录数远少于 pet 表的总数。原因pet 表开启了逻辑删除MyBatis-Plus 自动在单表查询里追加 deleted0但如果你写的是 xml 里的自定义多表 joinMP 不会自动帮你加条件。解决自定义 SQL 里手动加 and p.deleted 0或者用 MP 提供的 TableLogic 注解配合它的自定义 SQL 解析能力。这个坑上线后排查了很久最后是在慢查询日志里看到 join 结果和预期不符才定位到的。5.3 定时任务在开发环境跑得好好的部署后不执行现象本地启动项目到点提醒正常发送用 java -jar 部署到服务器后完全没反应。原因第一服务器时区不是东八区cron 表达式虽然写的是 0 30 8但服务器 UTC 时间比北京时间晚 8 小时第二打包时没有把 scheduled 注解所在包扫描进去——Spring Boot 默认扫描 main 方法同级及子包如果你的 Task 类放在别的包路径下需要配置 ComponentScan。解决应用配置里设置 spring.jackson.time-zoneGMT8服务器上把时区软链到 Asia/Shanghai然后确认启动类能扫描到 Task 包。5.4 登录接口正常但访问业务接口全部 401现象前端登录成功拿到 token之后每个请求都返回未认证。原因JWT 拦截器把放行路径写错了。常见错误是拦截器注册时把「放行登录接口」写在 excludePathPatterns 里但路径写成了 /user/login 而不是 /api/user/login而 controller 的 RequestMapping 带 /api 前缀。另一个坑是配置类上加 Configuration 但拦截器没注入new 出来的拦截器里所有依赖都是 null解码 token 时直接空指针。解决打印拦截器注册后的拦截路径清单人眼核对拦截器通过构造器注入需要的 service不要在里面 new。5.5 环境变量配置了 JDK 却启动失败报 UnsupportedClassVersionError现象下载项目后本地启动直接抛 UnsupportedClassVersionError或者提示「找不到或无法加载主类」。原因JDK 版本不匹配。项目用 JDK 17 编译本地装的是 JDK 8还有一种情况是 IDEA 里配置了 JDK 17但命令行 java -version 还是老版本因为 Path 环境变量里有多个 JDK配置的顺序问题导致实际生效的不是想要的版本。解决命令行里 java -version 确认实际版本再检查 JAVA_HOME 是否指向正确目录如果项目是 Maven 构建在 pom 里显式声明 maven.compiler.source 和 target并且确认 IDEA 的 Project Structure 和 Maven 的 JRE 设置一致。这个坑特别常见尤其是新入职拿老项目练手的时候大部分启动失败都能归因到环境变量配置上。6. 打包、验证与进阶从打好 jar 包到慢 SQL 定位6.1 验证系统该测什么系统「实现」完了不能只说「能跑」。我建议至少拉出这样一条验证清单用户登录后能否按角色管理员、医生看到不同的菜单新增一只宠物后在列表页和详情页能否立刻看到创建一个预约、然后改状态再看「今日预约」列表里的状态颜色是否跟着变把某只宠物的下次接种日期改成三天后手动触发一次提醒任务确认收到提醒后 reminded 字段被标记。其中提醒任务最值得在测试环境手动跑一次接口而不是等 cron 触发也就是写一个临时 Controller 入口收到消息后立刻回头看业务表里 reminded 的状态。6.2 打包部署的常用姿势项目交付多以 jar 包形式。IDEA 里 Maven 面板执行 packagetarget 目录下会生成可执行 jar。命令行的习惯是java -Xms256m -Xmx512m -jar pet-system.jar \ --spring.profiles.activeprod \ --server.port8081注意几个参数的用途-Xms 和 -Xmx 设置了堆大小宠物管理系统并发不高256~512MB 足够--spring.profiles.active 指定 prod 环境的 application-prod.yml里面配生产库地址--server.port 覆盖内置 Tomcat 端口。如果用 Jenkins 或脚本部署建议增加一个健康检查接口返回 200 后再摘流量避免启动一半被人访问。生产环境不要把数据库密码明文写在 yml 里用环境变量的方式注入比如 spring.datasource.password${DB_PASSWORD}。6.3 慢 SQL 定位从现象到 Explain系统用了一段时间后宠物档案列表变慢。不要凭感觉优化先用 MySQL 的慢查询日志定位具体 SQL。开启慢查询set global slow_query_log ON; set global long_query_time 1然后重放操作。拿到慢 SQL 后执行 EXPLAIN看 type 字段是不是 ALL全表扫描、key 是不是 null。常见优化手段是加索引pet 表的 owner_id 已有索引但如果经常按 breed 查列表给 breed 加普通索引就够预约表的查询条件集中在 doctor_id date 上建联合索引 (doctor_id, date, time_slot) 比单列索引效果好很多。注意不要过度加索引写多读少的小表反而因为索引维护拖慢写入速度。这个项目做下来最深的感受是管理系统难的不是某个技术点而是把所有环节接起来的耐心。当初我第一次做这类系统犯过把时间字段手动 set 导致测试环境时间错乱的错误也犯过分页插件没注册导致列表「数据全出来」的低级问题。后来养成了一个习惯——每个功能写完先不看界面效果直接打开数据库表看数据落得对不对数据对了再接前端。这个习惯帮我省了大量联调时间。希望帮到你。本文还有配套的精品资源点击获取
简介基于Spring Boot与Vue实现的一套宠物管理系统完整项目面向Java毕业设计、课程作业以及前后端开发初学者适合需要快速掌握业务系统整体构建流程、完成相似管理功能开发的读者参考。压缩包共471个文件整体约10.81MB包含154个Java后端源码和111个Vue前端组件另有JavaScript、CSS、XML等资源与配置以及SQL数据库脚本、YML环境配置和DOC说明文档能方便地初始化数据库并启动项目。已有132人学习使用。系统按常见管理业务划分模块包括用户注册登录与角色权限、宠物档案添加编辑与照片上传、健康档案与疫苗接种提醒、服务预约与评价、社区论坛与私信互动、日志审计与数据备份恢复等。通过学习该资源可直观理解Spring Boot接口与Vue页面的数据交互体会权限控制和业务分层的实现方式也能为课程设计报告撰写、系统功能演示提供完整的可运行示例。1. 一个宠物管理系统卡在前台 Excel 里的管理系统很多宠物医院、宠物店的前台到现在还在用 Excel 记宠物档案姓名、品种、疫苗日期、上次就诊记录全堆在几张表里查一次要翻半天换个电脑还得靠微信传文件。java宠物管理系统 设计与实现这个方向解决的就是这种「信息在表格里但不在业务里」的尴尬——用一套 Java Web 系统把宠物档案、预约、病历、疫苗接种提醒串起来让前台能查、医生能写、老板能看统计。这篇笔记按我实际做过的方案讲清楚技术选型为什么是 Spring Boot MyBatis、数据库怎么设计才能扛住后续扩展、核心功能的关键代码怎么写、以及那些不跑一遍根本发现不了的坑。适合正在做课程设计或毕业设计的同学也适合想拿管理系统练手 Java 后端的小团队。2. 技术选型Spring Boot MyBatis JWT哪里比老牌 SSM 更适合这个规模2.1 为什么是 Spring Boot 而不是 SSH 或 SSM早期做管理系统教科书里常见 Struts Spring Hibernate后来流行 SSMSpring Spring MVC MyBatis。这两个方案不是不能做宠物管理系统但你会发现大量时间花在「配置」而不是「业务」上。XML 里写一堆 bean 定义、数据源、事务管理器还没开始写宠物档案先折腾了两天环境——尤其是新手跟着教程走卡在 xml 命名空间报错的情况太多了。换成 Spring Boot 之后内嵌 Tomcat、自动配置、约定优于配置一个 main 方法起来就是一个可运行的 Web 服务这对「设计与实现」这种需要快速看到效果的项目来说价值非常大。我在选型时一般遵循两条原则第一团队里最熟的人用什么就用什么不要为了简历好看引入没人能维护的技术第二项目规模决定复杂度宠物管理系统的核心是宠物档案 CRUD、预约流程、病历记录、接种提醒这些用 Spring Boot MyBatis 已经覆盖得非常好杀鸡用不上微服务那一套。如果你在写毕业设计答辩老师问「为什么不用 SSH」回答「SSH 的配置成本高Spring Boot 的自动配置和生态更适合快速落地业务且社区活跃、遇到问题容易查」就是很稳的答案。2.2 工程分层与包结构设计做「设计与实现」类的项目最怕的是所有代码堆在 controller 里一按 CtrlShiftF 满屏的重复代码。这个项目我建议按常见的四层结构拆com.petms ├── controller // 接收 HTTP 请求做参数校验和结果封装 ├── service // 业务逻辑层事务边界在这里 ├── mapper // MyBatis 数据访问层对应数据库表 ├── entity // 数据库实体类 ├── dto // 与前端交互的数据对象避免直接暴露实体 ├── config // 全局配置JWT 拦截器、跨域、WebMvc 配置 ├── common // 统一返回结果、异常处理、常量 ├── utils // 工具类JWT 工具、日期工具 └── PetApplication.java这个结构对应的是「controller 只做转发和校验service 处理业务mapper 只管 SQL」的原则。县体到宠物管理系统宠物档案的新增可以拆成controller 接收 PetDTO 并校验必填项、service 层判断宠物主人是否存在并写入宠物表、mapper 执行 insert 语句。这样做的好处是后续加「同一主人最多登记 5 只宠物」这种规则时只改 service 层不碰 controller 和 mapper。有个容易被忽略的细节点entity 直接用 MyBatis-Plus 的注解映射数据库表而 controller 层接收的是 DTO两者不要混用。有个容易被忽略的细节点是entity 里的数据类型不要用基础类型 int、long要用包装类型 Integer、Long否则查询结果为空时会因为自动拆箱抛空指针异常。比如宠物表有个 owner_id 字段数据库为空时 MyBatis 会映射成 null实体类是 int 的话直接 NPE。2.3 认证选型JWT 还是 Session宠物管理系统的用户分两类前台接待和医生。权限其实不复杂但一定要有登录态校验否则任何人都能调接口删档案。Session 方案简单但前后端分离部署时跨域要处理 Cookie而且集群部署时要引入 Redis 共享 Session——对于这个规模有点重。我用 JWTJSON Web Token的常见做法用户登录成功后生成一个带过期时间的 token 返回给前端前端每次请求在 Header 里带 token后端用一个拦截器解码 token 并校验用户身份。JWT 在宠物管理系统这种内部系统里的好处是「无状态」后端不需要存 Session重启服务不丢登录态扩展多实例时也不用配置 Session 同步。坑在于 token 一旦签发在过期之前是控制不了的所以过期时间不要设太长管理后台的场景 8 小时比较合适。另外校验 token 的拦截器要排除登录接口和静态资源不然用户第一次访问就被拦在门外。拦截器里拿到用户信息后放到 ThreadLocal 或直接塞进请求参数service 层再拿去读当前的用户 id用来做操作日志的登记人字段。3. 数据库设计五张表撑起宠物档案与就诊闭环3.1 核心表拆解owner、pet、record、appointment、vaccination宠物管理系统的数据库设计是整个项目的根基。表设计错了后面写代码全是补丁。我按业务闭环拆成五张核心表宠物主人表owner、宠物表pet、就诊记录表medical_record、预约表appointment、疫苗接种表vaccination。为什么不把宠物和主人的信息塞在一张表里因为一个主人可以带多只宠物来就诊一对多在这种场景里是明确的业务语义拆成两张表后续统计「每位主人名下的宠物数」就是一条 group by 的事情。owner 表除了姓名、电话、地址外至少要有 created_time 和 updated_time 两个时间字段。pet 表的关键字段是 name、breed、gender、birthday、weight、owner_id其中 owner_id 是外键语义。medical_record 表记录每次就诊的病情描述、诊断结果、用药信息、就诊医生、就诊时间。appointment 表处理预约排期预约日期、时间段、预约项目、状态待确认/已完成/已取消。vaccination 表记录疫苗名称、接种日期、下次接种日期——这个表是后续做接种提醒的数据来源。3.2 建表 SQL 与字段含义说明直接给一段可执行的 DDL注意我在字段注释里写了业务含义这个习惯在答辩和交接时很加分。CREATE TABLE owner ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, name VARCHAR(50) NOT NULL COMMENT 主人姓名, phone VARCHAR(20) NOT NULL COMMENT 联系电话预约提醒用, address VARCHAR(255) DEFAULT NULL COMMENT 家庭地址, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 逻辑删除标记0正常 1删除, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT宠物主人表; CREATE TABLE pet ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, owner_id BIGINT NOT NULL COMMENT 所属主人idowner表主键, name VARCHAR(50) NOT NULL COMMENT 宠物昵称, breed VARCHAR(50) DEFAULT NULL COMMENT 品种如英短、金毛, gender TINYINT DEFAULT NULL COMMENT 性别0公 1母, birthday DATE DEFAULT NULL COMMENT 出生日期用来计算年龄, weight DECIMAL(5,2) DEFAULT NULL COMMENT 体重kg, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 逻辑删除标记, PRIMARY KEY (id), KEY idx_owner_id (owner_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT宠物信息表;字段类型上有几个要留意的点。owner 表的 phone 用 VARCHAR(20) 而不是 VARCHAR(11)因为座机、区号、国际号码都可能出现别把长度卡死。pet 表的 gender 用 TINYINT 而不是 CHAR(1)避免「公母」的中文编码问题展示时在前端做映射。weight 用 DECIMAL(5,2) 而不是 FLOAT浮点数做金额和体重计算会出现 0.10.2 不等于 0.3 的问题DECIMAL 是精确数值类型。create_time 和 update_time 用 DATETIME 并且设置默认值这样 insert 的时候不需要手动 set 时间MyBatis-Plus 的插入逻辑也不用关心这个字段。3.3 外键到底要不要建很多教材强调外键约束但在实际项目中我基本不建物理外键。原因有三个第一数据库在做删除和更新时会多一次约束检查影响写入性能第二业务上做逻辑删除deleted 字段标记之后物理外键与逻辑删除天然冲突——你删不掉「已删除」的数据外键约束就成了摆设第三MyBatis-Plus 的 mapper 层操作单表时有物理外键反而要多维护一句。所以 pet 表里的 owner_id 只是逻辑上的外键靠 service 层去保证「插入宠物前先确认 owner 存在」。这个设计在答辩时容易成为提问点。回答思路是物理外键保证的是数据库层面的引用完整性但在逻辑删除、分库分表、性能优化这些真实约束下引用完整性交给应用层代码更可控。service 层新增宠物时校验 owner_id 是否存在删除主人时先查有无名下宠物、有则提示先转移或删除宠物——这条规则写在 service 是显式的写在外键约束里是隐式的出问题排查起来前者快很多。3.4 MyBatis-Plus 的实体映射与自动填充用 MyBatis-Plus 时实体类和表的映射有两种方式驼峰自动映射和注解指定。强烈建议实体字段名与数据库字段名完全对应或者开启驼峰转换否则每次查询都要写 resultMap。我用的是注解方式因为数据库字段是下划线风格实体类字段是驼峰风格配置了 map-underscore-to-camel-casetrue 之后owner_id 自动映射到 ownerId不需要额外代码。自动填充是 MyBatis-Plus 一个非常实用的能力。实体类里 createTime 和 updateTime 这两个字段每次 insert 和 update 都要手动 set 当前时间代码重复度高。用 TableField(fill FieldFill.INSERT) 和 fill FieldFill.INSERT_UPDATE 注解标记字段再实现 MetaObjectHandler 接口在 insertFill 和 updateFill 方法里统一填充时间。配合前面 DDL 里 DEFAULT CURRENT_TIMESTAMP双保险任何一条写入路径都不会漏时间字段。这也是 MyBatis-Plus 根据实体类生成建表 SQL 的底层基础——实体字段注解完整数据库表才建得干净。4. 核心功能落地宠物档案、预约排期与接种提醒的三段代码4.1 宠物档案新增与分页查询三层代码的完整链路先讲宠物档案的新增这是理解 Controller → Service → Mapper 三层调用关系最直观的入口。我把校验逻辑放在 controller 层做基础校验必填字段、格式把业务校验放在 service 层主人是否存在、名下限重这样职责清晰。下面是新增宠物的核心代码PostMapping(/pet) public ResultLong createPet(RequestBody Valid PetCreateDTO dto) { // 基础校验由 Valid 完成这里直接进入业务层 Long petId petService.createPet(dto); return Result.success(petId); }Service Slf4j public class PetServiceImpl implements PetService { Autowired private PetMapper petMapper; Autowired private OwnerMapper ownerMapper; Override Transactional(rollbackFor Exception.class) public Long createPet(PetCreateDTO dto) { // 业务校验主人必须存在且未删除 Owner owner ownerMapper.selectById(dto.getOwnerId()); if (owner null || owner.getDeleted() 1) { throw new BizException(宠物主人不存在); } // 同一主人名下宠物数量上限防止一个人登记 50 只宠物 Long count petMapper.selectCount( new LambdaQueryWrapperPet().eq(Pet::getOwnerId, dto.getOwnerId())); if (count 5) { throw new BizException(同一主人最多登记5只宠物); } Pet pet new Pet(); BeanUtils.copyProperties(dto, pet); // 属性拷贝简写 petMapper.insert(pet); return pet.getId(); } }这段代码里有几个关键设计。Transactional(rollbackFor Exception.class) 声明事务注意括号里的 rollbackFor 必须写否则 Spring 默认只对运行时异常回滚像 BizException 这种自定义异常如果继承 Exception事务不会生效。业务校验写在 service 而不是 controller是因为这类规则可能被多个接口复用——比如后台导入宠物数据时同样要走「主人存在」的校验。BeanUtils.copyProperties 把 DTO 属性拷到实体类避免 controller 直接把 DTO 传进 mapper防止前端多传字段覆盖数据库值。MyBatis-Plus 的 insert 方法会自动回填自增主键到 pet.getId()所以返回的 id 不需要手动查。分页查询是列表页的高频操作。MyBatis-Plus 的分页插件配好后查询代码很简单Override public PageResultPetVO pagePets(PetQueryDTO query) { PagePet page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperPet wrapper new LambdaQueryWrapper(); // 关键字搜索宠物名或主人姓名模糊匹配 if (StringUtils.hasText(query.getKeyword())) { // 这里关联 owner 表的姓名需要子查询或连表见下方说明 wrapper.and(w - w.like(Pet::getName, query.getKeyword())); } if (query.getBreed() ! null) { wrapper.eq(Pet::getBreed, query.getBreed()); } // 逻辑删除过滤是 MyBatis-Plus 自动处理的deleted0 自动拼接 wrapper.orderByDesc(Pet::getCreateTime); PagePet result petMapper.selectPage(page, wrapper); // 实体转 VO补充主人姓名、年龄等展示字段 ListPetVO voList result.getRecords().stream() .map(pet - convertToVO(pet, ownerMapper)) .collect(Collectors.toList()); return new PageResult(result.getTotal(), voList); }分页查询最容易踩的坑是「按主人姓名搜宠物」pets 表没有 owner_name 字段不能直接在 wrapper 里 like。常见做法有两种如果搜索频率不高先查 owner 表拿到符合条件的 owner_id 列表再 in 到 pet 查询里如果搜索是核心功能直接在 pet 表冗余 owner_name 字段写入时同步更新。我在这类系统里一般选择冗余字段宠物表加 owner_name 和 owner_phone虽然违反了一点范式但查询走单表、索引友好比起 join 的性能收益明显。分页插件配置时注意要引入 MyBatis-Plus 的 PaginationInnerInterceptor否则 selectPage 分页不生效返回全量数据——这个是新手最容易困惑的「配置了但没生效」问题。4.2 预约排期的状态机与冲突校验预约管理比档案管理复杂在「状态」上。一个预约至少有四种状态待确认、已确认、已完成、已取消。我用一个 int 字段 status 存储用常量类定义状态值。修改状态时核心是校验状态流转是否合法——已完成的预约不能直接改成已取消已取消的不能变成已确认。public void cancelAppointment(Long appointmentId, Long currentUserId) { Appointment appointment appointmentMapper.selectById(appointmentId); if (appointment null) { throw new BizException(预约不存在); } // 状态机校验只有待确认和已确认状态可以取消 if (appointment.getStatus() ! AppointmentStatus.PENDING appointment.getStatus() ! AppointmentStatus.CONFIRMED) { throw new BizException(当前状态不允许取消); } Appointment update new Appointment(); update.setId(appointmentId); update.setStatus(AppointmentStatus.CANCELLED); update.setCancelReason(用户取消); update.setUpdateBy(currentUserId); appointmentMapper.updateById(update); }预约冲突校验是另一个要点同一时间段、同一医生不能同时接两个预约。实现时不要在应用层去循环比对直接在 SQL 层判断// 检查是否已有冲突预约 Long conflict appointmentMapper.selectCount( new LambdaQueryWrapperAppointment() .eq(Appointment::getDate, dto.getDate()) .eq(Appointment::getTimeSlot, dto.getTimeSlot()) .eq(Appointment::getDoctorId, dto.getDoctorId()) .in(Appointment::getStatus, AppointmentStatus.PENDING, AppointmentStatus.CONFIRMED)); if (conflict 0) { throw new BizException(该时间段已有预约请选择其他时间); }这个方案的关键在于状态列表参数已取消和已完成的预约不应该阻塞新的预约。另外数据库层面给 (doctor_id, date, time_slot, status) 加一个联合唯一索引做不到因为 status 是可变的所以只能靠应用层校验兜底——这个场景下并发冲突的概率很低应用层校验已足够。真要搞分布式锁就是过度设计了管理系统的不需要那么高的并发保障。4.3 疫苗接种提醒的定时任务实现接种提醒是整个系统里「增值」的功能查询下次接种日期在 7 天内的宠物给主人发送提醒通知。这段逻辑适合用 Spring 的 Scheduled 来做定时扫描。注意两点任务要加分布式部署保护加一个开关只在指定实例执行避免多实例重复发提醒。Component Slf4j public class VaccinationReminderTask { Autowired private VaccinationMapper vaccinationMapper; Autowired private RemindService remindService; Scheduled(cron 0 30 8 * * ?) // 每天早上 8:30 执行 public void sendReminder() { LocalDate today LocalDate.now(); LocalDate endDate today.plusDays(7); // 查询下次接种日期落在今天7天内的记录 ListVaccination list vaccinationMapper.selectList( new LambdaQueryWrapperVaccination() .between(Vaccination::getNextVaccineDate, today, endDate) .eq(Vaccination::getReminded, 0)); for (Vaccination v : list) { // 查询宠物和主人信息组装提醒内容 try { remindService.sendRemindMessage(v); v.setReminded(1); // 标记已提醒避免下次重复发送 vaccinationMapper.updateById(v); } catch (Exception e) { log.error(接种提醒发送失败, vaccinationId{}, v.getId(), e); } } } }定时任务有一个细节cron 用的是服务器时区如果部署在云上要注意时区设置否则 8:30 的提醒可能在北京时间 16:30 才发出去。另一个坑是「明天到期未接种」的记录不能只查一次就标记 reminded1而应该在发送成功后标记发送失败的保留待下次重试。上述代码里 catch 块只记录日志、不标记就是这个原因。系统上线后加一个「手动触发提醒」的接口用来补发漏掉的提醒这是运维侧的后悔药很有必要。5. 避坑排查宠物管理系统中 5 个常见坑与修复路径5.1 分页查询的总记录数一直是 0查了列表却不翻页现象列表接口能返回数据但 total 字段总是 0前端分页组件显示「共 0 条」。原因MyBatis-Plus 分页插件没有注册或者说 PaginationInnerInterceptor 没有放进 MybatisPlusInterceptor 里。很多人只加了 mybatis-plus-boot-starter 依赖以为分页就是 selectPage 自带的能力。解决配置一个 Bean 注入 MybatisPlusInterceptor添加 PaginationInnerInterceptor设置 DbType.MYSQL。还有一个更隐蔽的问题分页插件和自定义拦截器有顺序要求插件要在最外层。5.2 联表查询和逻辑删除大战查出来的数据莫名少了几条现象连表查询 medical_record 和 pet 时发现 join 出来的记录数远少于 pet 表的总数。原因pet 表开启了逻辑删除MyBatis-Plus 自动在单表查询里追加 deleted0但如果你写的是 xml 里的自定义多表 joinMP 不会自动帮你加条件。解决自定义 SQL 里手动加 and p.deleted 0或者用 MP 提供的 TableLogic 注解配合它的自定义 SQL 解析能力。这个坑上线后排查了很久最后是在慢查询日志里看到 join 结果和预期不符才定位到的。5.3 定时任务在开发环境跑得好好的部署后不执行现象本地启动项目到点提醒正常发送用 java -jar 部署到服务器后完全没反应。原因第一服务器时区不是东八区cron 表达式虽然写的是 0 30 8但服务器 UTC 时间比北京时间晚 8 小时第二打包时没有把 scheduled 注解所在包扫描进去——Spring Boot 默认扫描 main 方法同级及子包如果你的 Task 类放在别的包路径下需要配置 ComponentScan。解决应用配置里设置 spring.jackson.time-zoneGMT8服务器上把时区软链到 Asia/Shanghai然后确认启动类能扫描到 Task 包。5.4 登录接口正常但访问业务接口全部 401现象前端登录成功拿到 token之后每个请求都返回未认证。原因JWT 拦截器把放行路径写错了。常见错误是拦截器注册时把「放行登录接口」写在 excludePathPatterns 里但路径写成了 /user/login 而不是 /api/user/login而 controller 的 RequestMapping 带 /api 前缀。另一个坑是配置类上加 Configuration 但拦截器没注入new 出来的拦截器里所有依赖都是 null解码 token 时直接空指针。解决打印拦截器注册后的拦截路径清单人眼核对拦截器通过构造器注入需要的 service不要在里面 new。5.5 环境变量配置了 JDK 却启动失败报 UnsupportedClassVersionError现象下载项目后本地启动直接抛 UnsupportedClassVersionError或者提示「找不到或无法加载主类」。原因JDK 版本不匹配。项目用 JDK 17 编译本地装的是 JDK 8还有一种情况是 IDEA 里配置了 JDK 17但命令行 java -version 还是老版本因为 Path 环境变量里有多个 JDK配置的顺序问题导致实际生效的不是想要的版本。解决命令行里 java -version 确认实际版本再检查 JAVA_HOME 是否指向正确目录如果项目是 Maven 构建在 pom 里显式声明 maven.compiler.source 和 target并且确认 IDEA 的 Project Structure 和 Maven 的 JRE 设置一致。这个坑特别常见尤其是新入职拿老项目练手的时候大部分启动失败都能归因到环境变量配置上。6. 打包、验证与进阶从打好 jar 包到慢 SQL 定位6.1 验证系统该测什么系统「实现」完了不能只说「能跑」。我建议至少拉出这样一条验证清单用户登录后能否按角色管理员、医生看到不同的菜单新增一只宠物后在列表页和详情页能否立刻看到创建一个预约、然后改状态再看「今日预约」列表里的状态颜色是否跟着变把某只宠物的下次接种日期改成三天后手动触发一次提醒任务确认收到提醒后 reminded 字段被标记。其中提醒任务最值得在测试环境手动跑一次接口而不是等 cron 触发也就是写一个临时 Controller 入口收到消息后立刻回头看业务表里 reminded 的状态。6.2 打包部署的常用姿势项目交付多以 jar 包形式。IDEA 里 Maven 面板执行 packagetarget 目录下会生成可执行 jar。命令行的习惯是java -Xms256m -Xmx512m -jar pet-system.jar \ --spring.profiles.activeprod \ --server.port8081注意几个参数的用途-Xms 和 -Xmx 设置了堆大小宠物管理系统并发不高256~512MB 足够--spring.profiles.active 指定 prod 环境的 application-prod.yml里面配生产库地址--server.port 覆盖内置 Tomcat 端口。如果用 Jenkins 或脚本部署建议增加一个健康检查接口返回 200 后再摘流量避免启动一半被人访问。生产环境不要把数据库密码明文写在 yml 里用环境变量的方式注入比如 spring.datasource.password${DB_PASSWORD}。6.3 慢 SQL 定位从现象到 Explain系统用了一段时间后宠物档案列表变慢。不要凭感觉优化先用 MySQL 的慢查询日志定位具体 SQL。开启慢查询set global slow_query_log ON; set global long_query_time 1然后重放操作。拿到慢 SQL 后执行 EXPLAIN看 type 字段是不是 ALL全表扫描、key 是不是 null。常见优化手段是加索引pet 表的 owner_id 已有索引但如果经常按 breed 查列表给 breed 加普通索引就够预约表的查询条件集中在 doctor_id date 上建联合索引 (doctor_id, date, time_slot) 比单列索引效果好很多。注意不要过度加索引写多读少的小表反而因为索引维护拖慢写入速度。这个项目做下来最深的感受是管理系统难的不是某个技术点而是把所有环节接起来的耐心。当初我第一次做这类系统犯过把时间字段手动 set 导致测试环境时间错乱的错误也犯过分页插件没注册导致列表「数据全出来」的低级问题。后来养成了一个习惯——每个功能写完先不看界面效果直接打开数据库表看数据落得对不对数据对了再接前端。这个习惯帮我省了大量联调时间。希望帮到你。本文还有配套的精品资源点击获取
