企业官网建设流程全解析

简介：一份基于Java的流浪动物救助平台设计与实现毕业设计文档，面向计算机相关专业学生及Java全栈开发初学者。文档完整呈现了平台从选题背景、系统分析、功能设计到技术实现的全部过程，围绕流浪动物信息展示、志愿者风采、在线领养申请、线上募捐等核心模块展开，给出了基于SpringBoot、Vue、MySQL及Eclipse等工具的详细实现方案。包内共1个docx文件，大小1.48MB，内容为完整毕业设计论文，包含摘要、目录、正文、结论及参考文献，结构规范可直接参考。已有299人学习浏览，适合用于毕业设计选题参考、论文模板借鉴或项目开发思路梳理。通过阅读这份文档，读者可以掌握流浪动物救助平台的需求分析、数据库设计、前后端交互逻辑等关键技术，包括流浪动物信息发布管理、领养申请审核流程、线上募捐功能实现，同时也能了解Java体系在公益性信息共享平台中的落地实践，为类似系统开发提供完整参照。

1. 流浪动物救助平台是什么：表面是爱心网站，本质是审核状态机

把Java课程设计题目清单翻到最后几页，流浪动物救助平台通常都会挂在里面。第一眼看上去，它像一个“爱心信息站”，真正动手后才发现难点全在后台审核流程：动物发布要审核、领养申请要审核、救助记录要关联用户，任何一个状态没流转对，这个平台就退化成只能浏览的静态页面。拆开讲，它就是一套基于Spring Boot的多角色Java Web系统，前台做展示与申请，后台做审核与数据管理。适合正在找java课程设计案例源码参考的从业者，也适合想用一个完整业务练手Spring Boot的初学者。下面这套方案，从选型、建表到接口和页面，基本可以直接照抄。

2. 模块拆分与技术选型：先定边界，再用8张表撑起救助平台

2.1 技术栈怎么选：Spring Boot + MyBatis-Plus + Thymeleaf的原因

Spring Boot + MyBatis-Plus + Thymeleaf + Bootstrap + MySQL，是这类题目最常见也最稳的一套组合。为什么不是SSH？现在新项目很少碰Struts和Hibernate，维护成本高，答辩也容易被动。为什么不是前后端分离？一个人同时维护Vue工程和Spring Boot工程，联调、跨域、Token过期这些事会把工期吃掉大半，而流浪动物救助平台根本不需要那么重的交互。为什么不是Spring Cloud？这个题目业务量级远没到微服务，单体应用足够。

模板引擎选Thymeleaf，因为Spring Boot默认集成，不用单独配JSP那套环境；UI层面用Bootstrap，能把后台表格和前台卡片快速做整齐。如果你想把项目写进简历，技术栈后面再硬加Redis缓存和RabbitMQ削峰会很突兀，单机事务在这个场景下足够讲清楚。

选MyBatis-Plus的理由很现实：分页、条件构造器、逻辑删除都是开箱即用，省掉大量重复SQL。java基础扎实的同学可以完全手写MyBatis XML，但课程设计这种两到四周工期的题目，把省下来的时间拿去做业务闭环更划算。另外，这套组合对新手也友好，出问题时社区案例多，基本搜得到同类报错。

2.2 功能模块与角色划分

整个平台按两个端来拆就够了，角色分普通用户和管理员。未登录访客可以浏览前台列表和详情；注册登录后，用户能提交领养申请、上报救助线索、登记捐赠、报名志愿者活动。管理员负责动物信息审核、领养审核、救助受理、公告发布和用户管理。

核心链路可以画成一条线：发现流浪动物 → 用户或管理员登记 → 管理员审核通过 → 前台公开展示 → 用户提交领养申请 → 管理员审核 → 动物状态变为“已领养”。这条链路走通，系统主体就完成了。剩下的是公告、捐赠、救助记录、评论这些外围模块，用于撑起页面丰富度，同时也能把数据库表设计得更有层次，答辩时也好解释。

2.3 数据库设计：8张表把业务边界定死

表结构我给出可直接执行的版本。用户表建议叫sys_user，不要直接用user，后者在MySQL里是保留字，建表时常要加反引号，对新手是额外麻烦，改名最省事。

CREATE TABLE sys_user ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录名', password VARCHAR(100) NOT NULL COMMENT 'BCrypt加密后的密码', phone VARCHAR(20) DEFAULT NULL, role TINYINT NOT NULL DEFAULT 0 COMMENT '0普通用户 1管理员', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; CREATE TABLE animal ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50) NOT NULL COMMENT '动物昵称', species VARCHAR(20) NOT NULL COMMENT '猫或狗', age VARCHAR(20) DEFAULT NULL COMMENT '年龄描述，如2个月', gender TINYINT DEFAULT 0 COMMENT '0未知 1公 2母', health_status VARCHAR(200) DEFAULT NULL COMMENT '健康状况', location VARCHAR(100) DEFAULT NULL COMMENT '发现位置', description TEXT COMMENT '详细描述', photo VARCHAR(200) DEFAULT NULL COMMENT '图片相对路径', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待审核 1已发布 2已领养 3已下架', create_by INT NOT NULL COMMENT '发布人id', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_status (status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='流浪动物表'; CREATE TABLE adoption_application ( id INT AUTO_INCREMENT PRIMARY KEY, animal_id INT NOT NULL COMMENT '申请领养的动物', user_id INT NOT NULL COMMENT '申请人', reason VARCHAR(500) COMMENT '申请理由', phone VARCHAR(20), address VARCHAR(100) 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) COMMENT '审核备注', KEY idx_animal (animal_id), KEY idx_user (user_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='领养申请表'; CREATE TABLE rescue_record ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL COMMENT '上报人', animal_id INT DEFAULT NULL COMMENT '关联动物id，可为空', rescue_time DATETIME COMMENT '发现时间', location VARCHAR(100) COMMENT '发现地点', description TEXT, status TINYINT NOT NULL DEFAULT 0 COMMENT '0待受理 1已受理 2已完成', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='救助记录表'; CREATE TABLE donation_record ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, amount DECIMAL(10,2) DEFAULT NULL COMMENT '现金金额', item_name VARCHAR(100) DEFAULT NULL COMMENT '物资名称', remark VARCHAR(200), donate_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='捐赠记录表'; CREATE TABLE volunteer_activity ( id INT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(100) NOT NULL, content TEXT, activity_time DATETIME, location VARCHAR(100), max_people INT DEFAULT 20, current_people INT DEFAULT 0, status TINYINT DEFAULT 0 COMMENT '0招募中 1已结束', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='志愿活动表'; CREATE TABLE announcement ( id INT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(100) NOT NULL, content TEXT, publisher VARCHAR(50), publish_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='公告表'; CREATE TABLE comment ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, target_type TINYINT COMMENT '0动物 1活动', target_id INT NOT NULL, content VARCHAR(500), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='评论表';

几个字段设计上的考虑。animal.photo只存相对路径，不要存base64，否则数据库会迅速膨胀，页面加载也慢。animal.status是全局最重要的字段，前台列表只查status = 1的数据，待审核的动物绝不会出现在访客面前。adoption_application.status和animal.status要分开，两者联动是业务闭环的关键点，后面代码里再展开。

金额字段用DECIMAL，不用FLOAT或DOUBLE，精度问题在java基础里经常被问，这里就顺手避开。rescue_record.animal_id允许为空，因为用户可能先上报救助线索，管理员后补关联动物档案。这块属于业务边界设计，答辩时能说清楚理由，比多写十个接口更有说服力。

3. 用Spring Boot把后端骨架跑起来：实体、Mapper与核心接口

3.1 初始化项目与依赖清单

用Spring Initializr生成工程时，包名建议用com.example.animal，groupId和artifactId随意，但包结构要清晰。下面这个依赖清单是精简版，版本号以你本地Spring Boot父工程为准，不要硬贴网上的版本号，容易冲突。

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency>

spring-boot-starter-web负责Controller和内置Tomcat；mybatis-plus-boot-starter提供MyBatis-Plus能力；mysql-connector-java是MySQL驱动；thymeleaf负责服务端页面渲染。还需要引入Spring Boot的校验依赖和Lombok，Lombok可以省掉getter/setter，不用的话就手动生成。

application.yml里的核心配置如下：

spring: datasource: url: jdbc:mysql://localhost:3306/animal_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver thymeleaf: cache: false servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis-plus: configuration: map-underscore-to-camel-case: true

serverTimezone=Asia/Shanghai解决的是MySQL驱动连接后时间差8小时的问题，这个是老坑了，不配的话查出来的DATETIME会偏移。thymeleaf.cache=false是开发阶段必须开的，否则改页面要重启服务才生效。multipart限制上传大小，图片一般10MB以内足够。map-underscore-to-camel-case=true让create_by自动映射到createBy，MyBatis-Plus默认开启，所以这里的配置其实是冗余的，但写出来能让新手看懂意图。

3.2 实体类与通用分页接口

Animal实体类直接对应animal表，用@TableName指定表名，防止类名和表名不一致时查错表。

@Data @TableName("animal") public class Animal { @TableId(type = IdType.AUTO) private Long id; private String name; private String species; private String age; private Integer gender; private String healthStatus; private String location; private String description; private String photo; private Integer status; private Long createBy; private LocalDateTime createTime; private LocalDateTime updateTime; }

@TableId(type = IdType.AUTO)对应数据库自增主键。字段全部走驼峰映射，不用写XML。注意photo字段在数据库里叫photo，没有下划线，映射没歧义。createBy对应create_by，靠MyBatis-Plus自动驼峰转换完成。

Mapper层直接继承BaseMapper，单表CRUD和条件查询全部省掉：

@Mapper public interface AnimalMapper extends BaseMapper<Animal> { }

后台分页接口是管理端最常用的入口。管理员看所有动物列表，按status过滤，按创建时间倒序：

@RestController @RequestMapping("/api/admin/animal") public class AdminAnimalController { @Autowired private AnimalMapper animalMapper; @GetMapping("/page") public Result<IPage<Animal>> page( @RequestParam(defaultValue = "1") int page, @RequestParam(defaultValue = "10") int size, @RequestParam(required = false) Integer status) { Page<Animal> p = new Page<>(page, size); LambdaQueryWrapper<Animal> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(status != null, Animal::getStatus, status) .orderByDesc(Animal::getCreateTime); return Result.ok(animalMapper.selectPage(p, wrapper)); } }

LambdaQueryWrapper里的eq(status != null, ...)是MyBatis-Plus条件构造器的典型写法：第一个参数是布尔表达式，为false时这个条件不参与拼SQL，所以status传空就能查全部。Page对象必须作为第一个参数传给selectPage，返回值里有records、total、current、size，前端分页条直接复用这几个字段。这里的Result是项目统一返回对象，字段一般包含code、message、data，用你自己的包装类也行，关键是统一。

3.3 领养审核状态机：用事务保证数据一致性

这是整个项目中最值得写进简历的Service方法。管理员审核一条领养申请时，必须同时做两件事：把申请状态改成通过或拒绝；如果通过，把对应动物的状态改成“已领养”。这两步必须在一个事务里完成，否则会出现申请已通过但动物还在前台挂着的脏数据。

@Service public class AdoptionServiceImpl implements AdoptionService { @Autowired private AdoptionApplicationMapper applicationMapper; @Autowired private AnimalMapper animalMapper; @Override @Transactional(rollbackFor = Exception.class) public void auditAdoption(Long applicationId, Integer auditResult, String auditRemark) { // 1. 查出申请记录，状态必须是待审核 AdoptionApplication app = applicationMapper.selectById(applicationId); if (app == null || !app.getStatus().equals(0)) { throw new BusinessException("申请不存在或已被处理过"); } // 2. 更新申请状态 app.setStatus(auditResult); app.setAuditRemark(auditRemark); app.setAuditTime(LocalDateTime.now()); applicationMapper.updateById(app); // 3. 审核通过时，联动修改动物状态，变成已领养 if (auditResult.equals(1)) { Animal animal = animalMapper.selectById(app.getAnimalId()); if (animal == null || !animal.getStatus().equals(1)) { throw new BusinessException("该动物当前不在可领养状态"); } animal.setStatus(2); animalMapper.updateById(animal); } } }

逻辑分三步：第一步先查申请并校验状态为0，这是防重复处理的关键。第二步更新申请记录，把审核结果和备注写进去。第三步是核心联动，只有审核通过时才改动物状态；拒绝时动物保持“已发布”，用户可以另选别的动物继续申请。

@Transactional(rollbackFor = Exception.class)必须写，默认情况下事务只回滚RuntimeException，如果业务层抛出的是自定义BusinessException，不指定rollbackFor会出现事务不生效的诡异问题。这就是常被问到的典型问题：java怎么保证数据一致性？在这个场景下的答案就是三步走——先查状态、再快照更新、最后联动更新，外层用事务兜底。面试官接着问“数据库层面还能怎么兜”，答案就是唯一索引或乐观锁，后面避坑章节会写。

4. 把前后端流程串起来：从发表、审核到领养申请闭环

4.1 前台首页：只展示已审核通过的动物

前台首页的核心逻辑就一条SQL：where status = 1 order by create_time desc。待审核和已领养的动物都不该出现在这里，用Thymeleaf渲染一个分页列表：

<div class="container"> <div class="row" th:each="a : ${page.records}"> <div class="col-md-4 card"> <img th:src="${a.photo}" class="card-img-top" alt="动物照片"/> <div class="card-body"> <h5 th:text="${a.name}">动物名</h5> <p th:text="${a.species + ' / ' + a.age}">猫 / 2个月</p> <p th:text="${a.healthStatus}">健康状况</p> <a th:href="@{'/animal/detail/' + ${a.id}}" class="btn btn-primary">查看详情</a> </div> </div> </div> </div>

Controller里把Page<Animal>放进Model之后，Thymeleaf会自动把IPage接口暴露成page.records、page.current、page.pages。前台查询时只设置wrapper.eq(Animal::getStatus, 1)，再orderByDesc(Animal::getCreateTime)，代码逻辑和后台分页接口几乎一致，区别只在一个条件。这里不需要额外写原生的分页SQL，避免重复劳动。

图片地址直接th:src="${a.photo}"展示，这要求上传图片后返回的路径是/upload/xxx.jpg这种可由浏览器直接访问的URL，不是磁盘绝对路径，更不是base64字符串。关于图片访问的坑，第5章专门讲。

4.2 领养申请：表单提交与后端防重复校验

详情页底部放一个领养申请表单，需要提交animalId、申请理由、联系电话和居住地址。这段是纯静态表单，不做异步，简单可靠：

<form th:action="@{/api/adoption/apply}" method="post"> <input type="hidden" name="animalId" th:value="${animal.id}"/> <div class="form-group"> <label>申请理由</label> <textarea name="reason" class="form-control" rows="3"></textarea> </div> <div class="form-group"> <label>联系电话</label> <input type="text" name="phone" class="form-control"/> </div> <div class="form-group"> <label>居住地址</label> <input type="text" name="address" class="form-control"/> </div> <button type="submit" class="btn btn-success">提交领养申请</button> </form>

后端接收这个请求时，要做的校验不是表单非空那么简单，而是必须自己从库里读动物状态，再判断当前用户有没有申请过。不要信任前端传过来的任何状态字段：

@PostMapping("/api/adoption/apply") @Transactional public Result<?> apply(AdoptionApplication app, @RequestParam Long userId) { // 1. 动物必须是已发布状态 Animal animal = animalMapper.selectById(app.getAnimalId()); if (animal == null || animal.getStatus() != 1) { return Result.fail("该动物当前不可领养"); } // 2. 同一个用户对同一动物只能有一条申请 Long count = applicationMapper.selectCount( new LambdaQueryWrapper<AdoptionApplication>() .eq(AdoptionApplication::getAnimalId, app.getAnimalId()) .eq(AdoptionApplication::getUserId, userId)); if (count > 0) { return Result.fail("你已经申请过这只动物了，请等待审核"); } // 3. 初始化申请状态为待审核 app.setUserId(userId); app.setStatus(0); app.setApplyTime(LocalDateTime.now()); applicationMapper.insert(app); return Result.ok(); }

注意这里顺序很重要：先查动物状态，再查申请记录，最后插入新申请。查动物状态是为了防止管理员已经审核通过、动物已经变成已领养，用户还在前台看到详情页。查重复申请则是应对双击提交或者用户反复刷新提交。第三步把status显式初始化为0，即使前端恶意传了其他值也没用，后端只认自己赋值。

这段逻辑写完，前台用户侧的核心闭环就完成了。剩下的救助上报、捐赠登记本质上都是同一个套路：关联用户、初始化状态、插入记录，只是表和字段不一样。

4.3 后台管理：审核列表与图片上传

后台管理端和前台的区别主要在视图层。管理员打开审核页，默认看到status=0的动物列表，每条记录后面两个按钮：“通过”和“拒绝”。通过后动物状态变为1，前台立刻可见。拒绝时填一个备注，用户那边能收到反馈。

图片上传是后台发布动物的必选项，工具类写法如下：

@PostMapping("/api/admin/animal/upload") public Result<?> upload(@RequestParam("file") MultipartFile file) { String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); String fileName = UUID.randomUUID() + suffix; String uploadDir = System.getProperty("user.dir") + "/upload"; File dir = new File(uploadDir); if (!dir.exists()) { dir.mkdirs(); } File saveFile = new File(dir, fileName); file.transferTo(saveFile); return Result.ok("/upload/" + fileName); }

生成文件名时必须拼一个UUID，不能用用户上传的原始文件名，否则不同用户传一个a.jpg就会互相覆盖。System.getProperty("user.dir")取的是项目运行目录，本地开发时是工程根目录，transferTo如果目标目录不存在会直接抛异常，所以先mkdirs()。返回给前端的路径是/upload/xxx.jpg，这个路径要靠静态资源映射才能访问，否则上传成功但图片永远加载不出来，下一个坑。

5. 平台开发避坑：5个常见Java项目翻车现场与排查手段

5.1 图片明明传上去了，页面就是不显示

现象：upload接口返回成功，数据库里也存了/upload/xxx.jpg，但<img>标签破图。浏览器直接访问localhost:8080/upload/xxx.jpg返回404。

原因：Spring Boot默认只把classpath:/static/和classpath:/public/等目录映射成静态资源，你写的/upload是项目根目录下的物理文件夹，不在自动映射范围内。

解决：自己加一个资源映射配置：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + System.getProperty("user.dir") + "/upload/"); } }

addResourceHandler("/upload/**")是浏览器访问的URL前缀，addResourceLocations("file:" + ...)指向物理目录，注意结尾必须加/，否则映射不生效。这是个非常经典的Spring Boot资源映射坑，网上案例很多，但如果没人提醒，第一次遇到会查半天。

5.2 同一个用户对同一只动物提交了多条领养申请

现象：用户疯狂点击“提交领养申请”按钮，后台出现多条同一用户的申请记录，管理员审核时不知道以哪条为准。

原因：前端只做了按钮置灰，后端的重复校验有并发漏洞。用户两次请求同时到达后端，两个线程都查出来count = 0，然后同时插入，重复数据就产生了。

解决：后端在数据表上直接加唯一索引，让重复数据从根本上插不进去：

ALTER TABLE adoption_application ADD UNIQUE KEY uk_animal_user (animal_id, user_id);

加完索引后，重复插入会抛DuplicateKeyException，在Controller里catch这个异常统一返回“你已申请过”。但这会连带一个问题：一旦申请被拒绝，用户就不能再申请同一只动物了。如果业务上允许拒绝后再次申请，就把唯一索引改成uk_animal_user_status (animal_id, user_id, status)，利用status=2表示被拒绝，允许用户重新提交一条status=0的新申请。

5.3 MyBatis-Plus分页查出来总是全表数据

现象：调selectPage后records里一次性返回几十上百条，total值正确，但分页完全无效。

原因：MyBatis-Plus的分页需要单独配置PaginationInnerInterceptor拦截器，不配置的话Page对象只是摆设，SQL不会拼接LIMIT。

解决：在启动类或配置类里注册分页插件：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); PaginationInnerInterceptor pagination = new PaginationInnerInterceptor(DbType.MYSQL); pagination.setMaxLimit(100L); interceptor.addInnerInterceptor(pagination); return interceptor; } }

setMaxLimit(100L)是安全上限，防止前端传一个size=999999把整个表打出来。这个配置属于“新手必踩，老手必查”，因为不配置时项目能跑、接口能通、数据能返回，看起来一切正常，只有翻页时才发现问题。

5.4 前端传“2024-05-12”，后端LocalDateTime直接报错

现象：领养申请里的applyTime字段前端传的是"2024-05-12"，后端用LocalDateTime接收，请求直接400，日志提示无法反序列化。

原因：LocalDateTime默认期望格式是yyyy-MM-ddTHH:mm:ss，纯日期字符串缺了时间部分；Spring自带的消息转换器不认识这种紧凑格式。

解决：前端传"2024-05-12 00:00:00"，或者后端把这个字段类型改成LocalDate。实体里如果只是记录申请日期，用LocalDate最省心，序列化和反序列化都默认支持yyyy-MM-dd。如果要保留具体时间，就在字段上加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")，并保证前端按这个格式传值。这个问题的本质是java基础里的类型与格式转换，面试问日期处理时经常被拿出来当引子。

5.5 启动失败：端口占用与Mapper扫描不到

现象：APPLICATION FAILED TO START，日志里写着Port 8080 was already in use；或者启动后调用接口报Invalid bound statement (not found)。

原因：端口被占用通常是本地起了第二个Tomcat实例、或者IDEA端口没释放；Mapper扫描不到通常是启动类没加@MapperScan，或者Mapper接口上没有@Mapper注解。

解决：端口占用时临时换端口启动，不用改配置文件，直接加启动参数：

java -jar animal-platform.jar --server.port=8081

Mapper扫描问题分两种情况处理。启动类上统一加@MapperScan("com.example.animal.mapper")，整个包下的Mapper全部注册；或者每个Mapper接口上单独加@Mapper。推荐前者，写一次就不用再管。这类问题日志里的Caused by通常会直接点明原因，不要只看最上面的红色大字，往下翻三行找Caused by才是排查思路。

6. 从打包到演示：让救助平台在验收现场一次跑过的三个技巧

6.1 用一条演示脚本把核心流程完整串一遍

验收演示最怕临时手点数据，状态前后对不上。建议把演示数据直接写成data.sql，让JPA或手动初始化器在启动时自动灌入。一条典型的演示链路是：一个管理员账号、一个普通用户账号、一只待审核的猫、一只已发布的狗、一条已提交的领养申请。演示时先登录管理员审核猫，再去前台看狗，提交领养申请后切回管理员审核，最终回到前台看到“已领养”状态。

演示数据的状态字段必须和脚本顺序匹配，否则会出现“点审核说已处理过”的尴尬场面。时间字段用固定的2024-01-01 00:00:00，不要用NOW()，避免多次启动后数据时间不一致，影响截图和讲解。

6.2 一条命令打出可运行的jar包

本地开发跑mvn spring-boot:run没问题，但验收现场往往要换一台机器，最好提前打包成可执行jar：

mvn clean package -DskipTests java -jar target/animal-platform-0.0.1-SNAPSHOT.jar

-DskipTests跳过测试，避免因为测试类缺失导致打包失败。打包前确认application.yml里数据库地址、账号密码已经换成验收环境的配置，用户名密码不要硬编码在代码里。如果现场端口被占，按第5章的办法加--server.port参数即可。这里还需要提前确认本机java -version环境正常，java环境变量配置不对的话，jar包双击和命令行都无法启动。

6.3 给验收加分的展示顺序

演示时不要从头像和注册页面开始，时间不够时先走主链路，再补外围模块。推荐顺序：前台首页（展示已通过审核的动物）→ 用户登录 → 提交领养申请 → 右上角提示“待审核”→切换到管理员账号 → 审核通过 → 切换回前台，该动物状态变为“已领养”。这条链路每走一步都对应一张表和一个状态字段，讲起来干净利落，导师也能顺着这个顺序追问。

加分项是在管理员首页放一个简单的统计看板：按species统计动物数量，用ECharts柱状图渲染。后端接口就是GROUP BY species一行SQL，前端图表30分钟能调完。如果担心实时数据渲染翻车，可以先用静态JSON兜底，演示时再切到动态接口。我自己的习惯是永远先做静态兜底再做动态接入，两套数据源切换用if判断，线上永远走动态，演示现场万一接口报错也有退路。这算是我做演示项目这么多年攒下来的一个习惯，哪里都可能出问题，演示现场永远是备份优先。希望帮到你。

本文还有配套的精品资源，点击获取