企业官网建设流程全解析

做管理系统这几年，我最大的体会是：毕设或练手项目真正难啃的往往不是某个技术点，而是“一堆技术点黏在一起时怎么理清楚”。这次拿“基于SpringBoot的云宠之家管理系统设计与实现”做个完整复盘——从需求拆解、技术选型、数据库设计到核心模块代码，再到我实际运行中踩过的坑，一次性说透，希望能给正在做类似项目的朋友提供一套可以直接参考的落地方案。

1. 项目概述与需求拆解

1.1 云宠之家到底在解决什么问题

“云宠之家”这个名字听起来很互联网，但把它落到功能上，其实就是一个典型的信息管理平台。它能做的事情可以概括成四个方面：

第一，宠物信息的统一管理。宠物档案不再散落在纸质表格或者微信聊天记录里，管理员可以维护每一只宠物的品种、年龄、性别、健康状态、照片等基础资料，公众用户也能浏览宠物列表。

第二，领养流程的线上化。把线下填表、电话沟通的领养流程搬到系统里，用户提交领养申请，管理员审核，宠物状态同步变更，整个过程有记录、可追溯。

第三，健康记录与提醒。每一只宠物可以绑定多条免疫、驱虫、体检记录，系统还能通过定时任务在指定时间提醒相关责任人。

第四，多角色与权限控制。系统里至少要有系统管理员、普通用户，甚至还可以扩展宠物医生、志愿者等角色，不同角色看到的功能入口和数据范围完全不同。

综合这些需求，这个系统适合正在准备毕业设计的同学，也适合想用SpringBoot做完整全栈项目的初学者。它不算大，但功能链路完整，能够覆盖SpringBoot、MyBatis-Plus、JWT认证、文件上传、定时任务、分页查询这些主流技术点，做完以后简历上可以写的东西非常扎实。

1.2 功能模块的边界划分

项目拆模块的时候，我习惯先画“角色-功能”矩阵，而不是直接建表。这样能避免后续代码写了一半发现入口不对。

系统角色与核心功能对应关系大致如下：

• 管理员：宠物档案管理、领养审核、健康记录维护、用户管理、统计概览
• 普通用户：注册登录、浏览宠物、提交领养申请、查看个人申请进度、补充宠物日常记录
• 游客：查看宠物公开信息（只读）、注册入口

模块划分上我最终确定了六个核心模块：用户管理模块、宠物管理模块、领养管理模块、健康记录模块、系统管理模块和统计报表模块。

这里我想强调一个容易被忽略的点：领养管理不是简单写一个INSERT语句。用户提交申请后，宠物状态要从未领养变成待审核，审核通过后还要再次变更。这个过程如果不做事务控制，很容易出现宠物状态和申请记录对不上的脏数据。这也是我在代码实现时优先用@Transactional的地方，后面会详细讲。

2. 技术选型与搭建思路

2.1 为什么选择SpringBoot作为基础框架

这个项目使用SpringBoot，不是因为“大家都在用”，而是它的特性确实适合这类业务系统。

SpringBoot最核心的价值是自动装配和约定优于配置。传统SSM项目要写大量的XML配置，而SpringBoot把大多数组件的初始化和配置封装成了Starter，比如spring-boot-starter-web内置了Tomcat和SpringMVC，spring-boot-starter-data-redis把Redis连接池、模板对象全部配置好，开发者只需要关注业务代码。

举个例子，我的pom.xml里引入MyBatis-Plus和三方工具类之后，几乎不需要手动写DataSource配置类。这并不代表底层不需要配置，而是SpringBoot利用条件注解@ConditionalOnClass在类路径里有对应依赖时自动装好。了解这一点很重要，因为后续排查“我的配置为什么不生效”时，第一个思路就应该是检查自动配置是否被覆盖。

版本选择上，我最终确定的是SpringBoot 2.7.x。2.7仍然是主流的稳定版本，且SpringBoot 3.x要求JDK 17，当时很多三方依赖的兼容性还不太完善。如果你用的是JDK 8，2.7系列是最舒服的选择。JDK 17当然更好，但需要接受更高的依赖适配成本。

2.2 前后端交互与认证方案

实际操作层面，我没有做成前后端分离的单页应用，而是采用了SpringBoot + 模板渲染 + Vue局部引入的混合方案。页面主体用Thymeleaf渲染后台管理页面，需要高交互性的模块（比如宠物列表的模糊搜索、图片预览）局部引入Vue组件。这个思路对毕设来说非常实用——既不用单独部署前端工程，又能体验到Vue的响应式开发。

认证方案选了JWT。每次登录成功后，后端签发一个Token，前端存储并在请求头Authorization: Bearer token里携带。后端通过拦截器解析Token、校验签名和过期时间，再把用户信息放入ThreadLocal，方便业务层随时获取当前登录用户。

需要说明的是，单服务器场景下session其实更简单，但JWT让我不需要额外配置session复制或共享，也方便以后如果要用Redis做分布式会话，可以平滑过渡。对学习目的来说，把JWT的生成、解析、刷新、拦截器四个环节走一遍，比直接用Spring Security默认登录机制学到底层原理深刻得多。

2.3 Maven项目结构规划

模块规划直接影响后续开发效率。我的maven工程结构如下：

cloud-pet-home ├── src/main/java │ ├── com.cloudpet.common │ ├── com.cloudpet.config │ ├── com.cloudpet.controller │ ├── com.cloudpet.service │ ├── com.cloudpet.mapper │ ├── com.cloudpet.entity │ ├── com.cloudpet.dto │ ├── com.cloudpet.interceptor │ └── com.cloudpet.utils ├── src/main/resources │ ├── mapper │ ├── static │ └── application.yml └── pom.xml

分层方面我坚持了经典的Controller-Service-Mapper三层层级，但没有再加“Entity里套VO、VO里套DTO”这种过度设计。对于小型项目，一个实体类加一个视图对象完全够用，否则你会发现光做对象转换就占了一半时间。

3. 数据库设计与核心表结构

3.1 六张核心表的字段规划

数据库设计我建议一次到位，因为后面改表结构代价很大。我把核心表归纳成六张，字段设置围绕“可查询、可关联、可追溯”三个原则进行。

先看用户表：

CREATE TABLE `tb_user` ( `id` bigint NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录名', `password` varchar(100) NOT NULL COMMENT 'BCrypt加密密码', `nickname` varchar(50) DEFAULT NULL, `phone` varchar(20) DEFAULT NULL, `avatar` varchar(200) DEFAULT NULL, `role` tinyint NOT NULL DEFAULT 0 COMMENT '0普通用户 1管理员', `status` tinyint NOT NULL DEFAULT 1 COMMENT '1启用 0禁用', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

密码字段我使用BCrypt加密存储，不存明文，这是出于最基本的安全习惯。username加了唯一索引，因为登录时每秒可能执行大量按用户名查询，没有索引会触发全表扫描。

宠物表是系统核心资产：

CREATE TABLE `tb_pet` ( `id` bigint NOT NULL AUTO_INCREMENT, `name` varchar(50) NOT NULL, `category` varchar(20) DEFAULT NULL COMMENT '猫/狗/兔等', `breed` varchar(50) DEFAULT NULL, `age` int DEFAULT NULL, `gender` tinyint DEFAULT NULL COMMENT '0母 1公', `weight` decimal(5,2) DEFAULT NULL, `photo` varchar(200) DEFAULT NULL, `status` tinyint NOT NULL DEFAULT 0 COMMENT '0待领养 1审核中 2已领养 3下架', `description` text, `owner_id` bigint DEFAULT NULL COMMENT '当前负责人/领养人', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里status是状态机，与领养申请联动。owner_id一开始不会被使用，只有领养审核通过后才关联到用户，这种设计保证同一个宠物不会被重复领养。

领养申请表：

CREATE TABLE `tb_adopt_apply` ( `id` bigint NOT NULL AUTO_INCREMENT, `pet_id` bigint NOT NULL, `user_id` bigint NOT NULL, `reason` varchar(500) DEFAULT NULL COMMENT '领养理由', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0待审核 1通过 2拒绝', `apply_time` datetime DEFAULT CURRENT_TIMESTAMP, `audit_time` datetime DEFAULT NULL, `audit_remark` varchar(200) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

健康记录表，字段上比较灵活，记录类型和描述分开，方便以后统计分析：

CREATE TABLE `tb_health_record` ( `id` bigint NOT NULL AUTO_INCREMENT, `pet_id` bigint NOT NULL, `record_type` varchar(20) NOT NULL COMMENT '免疫/驱虫/体检/就医', `title` varchar(100) DEFAULT NULL, `content` text, `record_time` datetime DEFAULT NULL, `create_by` bigint DEFAULT NULL, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

预约登记表和服务项目表我合在一张里，因为服务项目种类不多，不需要单独建表。字段分别是pet_id、user_id、service_type、appointment_time、status、remark。

3.2 表关系与常见设计误区

表之间的关联关系并不复杂。用户与宠物是一对多，宠物与健康记录是一对多，用户与领养申请是一对多，宠物与领养申请是一对多。

设计时最容易犯的错误主要有三个。

第一个是“到处都存冗余字段”。比如宠物表里存了领养人姓名，看起来查询方便，但一旦用户改了昵称，宠物表数据就变成旧的。正确做法是只存owner_id，展示时通过关联查询拿到用户昵称。

第二个是“软删除和状态字段混淆”。我见过很多项目把宠物状态用del_flag（1已删除0未删除）来表示，但“已领养”和“已删除”完全是两回事。建议分开：status管业务状态，is_deleted管逻辑删除，不要混在一起。

第三个是“日期字段类型不清”。如果是纯Java后端项目，使用datetime和LocalDateTime对象配合即可。如果前后端分离且前端要用JavaScript处理日期，我建议统一用LocalDateTime接字符串格式，避免日期序列化出现“2024-12-07T10:00:00”这种前端不好处理的格式。可以给SpringBoot配置一个全局Jackson格式化器一次性解决。

提示：MySQL 8.0默认字符集已经是utf8mb4，所以建表时务必指定utf8mb4而不是老的utf8，否则存储emoji或特殊字符时会报错或乱码。

4. 核心功能模块的实现细节

4.1 用户认证与全局请求拦截

认证这块我拆成了三个步骤：登录接口签发Token、拦截器校验Token、拦截器放行白名单。

登录逻辑不复杂，核心代码是这样的：

@Service public class AuthServiceImpl implements AuthService { @Autowired private UserMapper userMapper; @Autowired private JwtUtils jwtUtils; @Override public Result<LoginVO> login(LoginDTO dto) { User user = userMapper.selectByUsername(dto.getUsername()); if (user == null || !BCrypt.gateway().matches(dto.getPassword(), user.getPassword())) { return Result.error("用户名或密码错误"); } if (user.getStatus() == 0) { return Result.error("账号已被禁用"); } String token = jwtUtils.generateToken(user.getId(), user.getRole()); LoginVO vo = new LoginVO(token, user.getNickname(), user.getRole()); return Result.success(vo); } }

这里有两个细节值得提。

密码校验不能用MD5直接比对，BCrypt匹配才是标准做法。因为每次BCrypt生成的哈希值包含随机盐，每次加密结果不同，所以要用matches方法验证。

Token生成时要包含角色信息，因为后续管理员接口需要校验角色。我使用的是一个简单的JWT工具类，内部声明了signWith(SignatureAlgorithm.HS256, secretKey.getBytes())，过期时间设为24小时。对于学习项目够用了。

拦截器部分我做了两个关键设计。一是定义InterceptorConfig注册拦截器，二是把登录、获取验证码、宠物公开列表等路径加入白名单：

@Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new JwtInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/auth/login", "/auth/register", "/pet/public/**"); }

说到全局请求拦截器，我还遇到一个常见的坑：拦截器里把用户信息放进了ThreadLocal，但是在afterCompletion阶段忘记清理。线程复用时，下次请求可能会拿到上一个用户的身份信息，这是一个安全漏洞。所以一定要在finally块里调用remove()。

4.2 宠物管理：分页查询与图片上传

宠物管理是所有模块里最需要打磨的，因为它涉及列表、详情、上传和状态变更。

分页查询使用了MyBatis-Plus的Page对象，配合LambdaQueryWrapper动态拼条件。举个例子：

@Override public Page<PetVO> pagePets(Integer pageNum, Integer pageSize, PetQuery query) { Page<Pet> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Pet> wrapper = new LambdaQueryWrapper<>(); if (StringUtils.isNotBlank(query.getCategory())) { wrapper.eq(Pet::getCategory, query.getCategory()); } if (StringUtils.isNotBlank(query.getKeyword())) { wrapper.and(w -> w.like(Pet::getName, query.getKeyword()) .or().like(Pet::getBreed, query.getKeyword())); } if (StringUtils.isNotBlank(query.getStatus())) { wrapper.eq(Pet::getStatus, query.getStatus()); } wrapper.orderByDesc(Pet::getCreateTime); Page<Pet> result = petMapper.selectPage(page, wrapper); return convertToVO(result); }

为什么要用LambdaQueryWrapper而不是写死XML SQL？因为宠物列表的查询条件不固定，用户可能只选品类、只搜品种，也可能组合查询。用LambdaQueryWrapper动态构造条件，代码简洁，还能避免拼接SQL注入。

图片上传这个点我也重点处理了。

我选择把图片保存到服务器的独立目录，而不是数据库的longblob字段。上传接口长这样：

@PostMapping("/upload") public Result<String> upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return Result.error("文件不能为空"); } String originalFilename = file.getOriginalFilename(); String ext = StringUtils.getFilenameExtension(originalFilename); if (!Arrays.asList("jpg", "jpeg", "png", "gif").contains(ext)) { return Result.error("不支持的图片格式"); } String fileName = UUID.randomUUID() + "." + ext; File dir = new File(uploadPath); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir.getAbsolutePath() + "/" + fileName)); return Result.success("/upload/" + fileName); }

这里有几个关键点：保存文件名用UUID，避免恶意用户上传同名文件覆盖已有资源；限制扩展名，防止上传jsp、exe等可执行文件；代码中要对file.transferTo方法抛出的IOException做好处理，不要让它直接暴露给前端。

静态资源访问还需要加一个WebMvcConfigurer配置：

registry.addResourceHandler("/upload/**").addResourceLocations("file:D:/cloudpet/upload/");

注意：这里路径要和application.yml里的自定义路径保持一致，否则会出现“上传成功但图片无法访问”的诡异问题。

4.3 领养流程的状态机与事务控制

领养申请模块是业务逻辑最重的部分。我采用了一个简单的状态机：

待领养（0）→ 审核中（1）→ 已领养（2）

操作路径有两种：用户申请时状态0→1，管理员审核时状态1→2或1→0（拒绝后宠物重新变为待领养）。

用户提交领养申请时，一要校验宠物存在，二要校验宠物状态为待领养。防止用户刷接口把同一只宠物申请多次，tb_adopt_apply表应该对pet_id + user_id + status加唯一索引，但考虑到用户可能被拒绝后重新申请，这里我在业务代码里用了一个“查出当前是否存在待审核或已通过记录”的逻辑，而不是简单加唯一索引。

审核方法长这样：

@Transactional(rollbackFor = Exception.class) public void auditAdopt(Long applyId, Integer result, String remark) { AdoptApply apply = adoptApplyMapper.selectById(applyId); if (apply == null || apply.getStatus() != 0) { throw new BizException("申请记录不存在或已处理"); } Pet pet = petMapper.selectById(apply.getPetId()); if (pet == null) { throw new BizException("宠物不存在"); } if (result == 1) { if (pet.getStatus() != 1) { throw new BizException("宠物当前不在审核状态"); } // 更新申请状态为通过 apply.setStatus(1); apply.setAuditTime(LocalDateTime.now()); apply.setAuditRemark(remark); adoptApplyMapper.updateById(apply); // 更新宠物状态为已领养 pet.setStatus(2); pet.setOwnerId(apply.getUserId()); petMapper.updateById(pet); } else { apply.setStatus(2); adoptApplyMapper.updateById(apply); pet.setStatus(0); petMapper.updateById(pet); } }

我一直强调这里的@Transactional(rollbackFor = Exception.class)非常关键。默认情况下Spring事务只对RuntimeException回滚，如果你在业务方法抛出自定义BizException，而它又没有继承RuntimeException，事务不会回滚。rollbackFor = Exception.class就是告诉Spring任何异常都回滚，这在写业务系统时应该是标配。

4.4 健康提醒定时任务实现

定时任务的场景是：每天上午8点检查未来7天需要接种疫苗或驱虫的宠物，调用短信或站内信提醒。

实现方式就是SpringBoot自带的@Scheduled注解，配合自定义线程池配置：

@Component public class HealthRemindTask { @Scheduled(cron = "0 0 8 * * ?") public void remind() { List<HealthRecord> remindList = healthRecordMapper.selectNeedRemind(); if (CollectionUtils.isEmpty(remindList)) { return; } for (HealthRecord record : remindList) { // 给自己留一个扩展入口，目前先打日志 log.info("宠物{}需要{},提醒负责人{}", record.getPetId(), record.getTitle(), record.getPetId()); } } }

要在主启动类或者配置类上加上@EnableScheduling，否则定时任务不会生效。SpringBoot默认的定时任务是单线程执行的，如果任务耗时长，会影响其他定时任务。我使用了TaskScheduler线程池，配置了核心线程数5。

实际开发中，健康记录表里应该有next_time或remind_time这类字段，而不是每次扫全表。我是在tb_health_record中冗余了一个next_record_time字段，定时任务查询条件就是next_record_time BETWEEN NOW() AND DATE_ADD(NOW(), INTERVAL 7 DAY)，配合索引查询效率很高。

5. 安全控制与环境部署

5.1 权限校验的两种层级

虽然JWT已经完成了身份认证，但权限校验还需要单独做。我采用了注解+拦截器组合的方式。

自定义一个@RequireRole注解，标记接口需要的角色ID：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { int value() default 0; }

在拦截器中通过HandlerMethod拿到注解，再比较当前用户的角色：

public boolean preHandle(...) { // 校验token，将userId和role存入ThreadLocal HandlerMethod handlerMethod = (HandlerMethod) handler; RequireRole requireRole = handlerMethod.getMethodAnnotation(RequireRole.class); if (requireRole != null) { int needRole = requireRole.value(); if (needRole != SecurityUtil.getCurrentUser().getRole()) { throw new BizException(403, "无权限访问"); } } return true; }

这种方式写起来简单直接，不用引入Spring Security的大量过滤器链。但如果你后续想要更灵活的权限扩展（比如角色-权限-资源三级模型），建议直接转Spring Security加@PreAuthorize。

5.2 跨域问题与接口联调

如果你是纯前后端分离开发，跨域是逃不开的坑。我在后端配置了一个CorsConfig：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedHeader("*"); config.addAllowedMethod("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

配置完成后有个细节要注意：如果同时使用了Spring Security，跨域配置必须在Security过滤链之前生效，否则预检请求（OPTIONS）会被拦截。

5.3 项目打包与实际部署

SpringBoot项目的部署相对简单。在IDEA里先执行mvn clean package，如果项目是多模块，要确认父模块和子模块都成功install。打包后生成的jar文件可以直接通过java -jar运行。

我实际部署时使用的是服务器上安装的MySQL和指定的JDK环境。跑之前务必检查application.yml里的数据源配置和环境变量，尤其是密码含有特殊字符时，在YAML里需要用单引号包裹。

一个我踩过的坑是：本地开发正常，打包上服务器后图片上传失败。排查半天发现是application.yml里的上传路径写的是本地绝对路径，服务器上没有这个目录。解决办法是把上传路径独立成配置项，部署时通过环境变量或application-prod.yml覆盖。

file: upload-path: ${UPLOAD_PATH:D:/cloudpet/upload/}

这样本地和服务器用同一套代码，启动时传入不同的UPLOAD_PATH即可。

6. 常见问题与排查思路

6.1 启动报错的排查套路

我见过很多朋友项目启动失败，其实是SpringBoot版本和依赖冲突导致的常见现象。

比如提示Error creating bean with name 'xxxMapper'，多半是Mapper接口扫描不到。先确认启动类上的@MapperScan注解路径是否正确，再看Mapper接口有没有被@Mapper标注，最后检查mybatis-plus的mapper-locations配置有没有把XML文件路径写错。

还有一类问题特别容易忽略：多个配置文件中同一个属性重复定义。比如application.yml和application-prod.yml里都设置了server.port，启动时以application.yml里的为准。建议只在一个地方维护启动端口，避免疑惑。

6.2 数据查询与关联问题

分页查询返回的数据里，宠物列表需要显示领养人姓名，但tb_pet表只有owner_id。这时候如果用MyBatis-Plus的Page<Pet>直接返回，前端只会看到一串数字ID。

我采用VO方式解决：

public class PetVO { private Long id; private String name; private String category; private Integer status; private String ownerName; private String photo; }

查询完分页结果后，收集所有owner_id批量查用户表，再循环填充ownerName。千万不要在循环里逐条查数据库，这样会产生N+1问题，数据量一大性能会急剧下降。

6.3 上传图片404问题

普通Controller上传成功但访问图片时报404，此时按三个顺序排查：第一，检查addResourceHandler里的访问前缀和前端请求路径是否一致；第二，检查本地目录是否存在并有写入权限；第三，检查是否被拦截器拦截了/upload/**路径。

注意：如果你的拦截器设置了addPathPatterns("/**")，一定要记得把"/upload/**"加进excludePathPatterns，否则图片请求也会经过JWT认证，导致无法公开访问。

6.4 基于环境差异的问题清单

我把常见问题汇总成一个速查表，方便大家直接对照排查。

6.5 我的性能优化与后续扩展建议

项目烧录成型之后，有几处性能优化是值得做的。

第一，热门宠物列表的查询结果可以考虑加Redis缓存。以宠物分页列表为例，宠物数据变动不频繁，但浏览量大，把第一页缓存5分钟即可明显降低数据库压力。如果使用了Spring Data Redis，只需要在Service实现里加一个@Cacheable注解，效率提升非常明显。

第二，健康提醒这类定时任务可以从“每天全表扫描”改成“只扫描未来N天数据”，配合next_record_time字段上的索引。

第三，扩展方向上，建议把“评论留言”做成楼主回复模式，并把用户的领养申请记录做成分页展示，方便管理员追溯操作日志。

7. 个人体会与最后补充

最后说点实在的体会。这类管理系统的代码难度其实不高，但最容易出问题的环节往往在“边界条件和状态一致性”。领养审核、宠物状态更新、用户权限控制——这些功能单看不复杂，串起来就会暴露出大量细节问题。所以动手前花两天把需求拆清楚，把表关系和状态流转画明白，绝对比急着写代码划算。

我第一次做这种项目时，就是在“用户提交申请后，管理员拒绝，宠物状态是否正确回退”这个点上想简单了。当时以为只要把申请表的status改成拒绝就行，导致宠物一直停留在审核中状态，用户看不到任何提示。现在的实现里，从申请到审核、通过或拒绝，每个步骤都更新宠物对应状态，并且所有操作都留了audit_remark备注，这样运营人员也能看懂每一条记录背后发生了什么。

调试过程中还有一个经验想分享：把系统的常用操作日志打出来。我习惯在Service关键方法里加一行log.info，记录操作人、操作对象和结果。看起来繁琐，但在配置环境异常或需要复盘业务流程时，日志能帮你快速定位问题链路，远比事后从数据库里反推效率高。

如果你也准备拿着这个题目去做，建议先用两到三个晚上把核心流程走通，再逐步加功能。数据库表和状态字段一旦定下来，后面所有模块都建立在这套基础上，前期设计的重要性，怎么说都不过分。

这个项目后续还有不少值得玩味的方向，比如多角色权限升级、消息通知模块、数据可视化大屏，甚至对接地图实现附近宠物医院推荐。有了现在这套骨架，扩展新的功能模块只是锦上添花的事。