简介：《基于java流浪动物救助平台设计与实现》是一份完整的毕业设计论文文档，面向计算机相关专业学生、SpringBoot与Vue全栈开发者，以及关注流浪动物保护的信息化项目人员。文档以Java为核心，结合SpringBoot、Vue与MySQL，系统描述了平台从需求分析、数据库设计到模块开发的全流程，重点涵盖流浪动物信息展示、志愿者风采、在线领养申请、爱心募捐等功能，并探讨了平台对促进救助信息共享和救助行为发生的价值。包体为单个DOCX文件，大小约1.48MB，内含中英文摘要、绪论、技术选型、功能设计与实现等章节，结构清晰，便于直接阅读和编辑排版。已有299人学习浏览，适合用作毕业设计参考、课程论文模板或公益类Web项目的开发蓝本；读者从中可掌握平台整体架构、前后端交互逻辑、数据库表设计及核心业务实现要点，为同类型系统开发提供可落地的思路与排错经验。
1. 流浪动物救助平台用 Java 做，到底解决了谁的什么问题
流浪动物救助这件事，最痛的不是没人管，而是信息烂在各自的群里、贴吧和朋友圈里。发现一只受伤的猫，救助人拍张照发个群，三天后消息被刷走，后续没人跟进；救助站收容了动物，登记靠 Excel，领养审核靠人肉聊天记录，回访全靠自觉。一个基于 Java 的流浪动物救助平台，本质上就是把「发现—救助—收容—领养—回访」这条链路上的信息流转、状态跟踪和审批记录固化下来，让好心人、救助站和领养人各有一个入口，各自看到自己该看的那部分。
Java 在这个场景里合适，是因为这类平台多半是中小型团队或高校项目在做，团队对 Spring Boot 这套生态最熟，招聘和交接都方便；同时后续要接地图定位、文件存储、微信小程序端，Java 的服务端生态现成组件多，不至于什么都从零写。这篇文章按我自己落地的做法，把这个平台的模块拆解、数据库设计、权限模型、文件上传和上线部署讲一遍，再列出实际维护中容易让人翻车的几个点。适合打算自己从零写一套、或者接手别人半成品继续改的开发者看。
2. 先拆平台的核心模块：一张业务流程图背后的七个状态节点
2.1 救助平台的业务闭环不是 CRUD，是状态机
很多初写这类系统的开发者，上来就设计「动物表」「领养表」，然后做几个增删改查页面，觉得完事了。实际跑起来你会发现，救助平台最核心的复杂度不在表结构，而在「一条求助记录从发现到最后被领养，中间的状态变化怎么流转、谁有权变、变了之后通知谁」。
我一般会先把业务对象的状态机画出来。一条流浪动物记录至少经历这些状态：待审核、救助中（已安置）、待领养、领养审核中、已领养、已绝育/已医疗、已安乐（特殊情况）、已死亡（自然）。每个状态变更都对应一个操作角色：普通用户只能发起「发现上报」；管理员可以审核、变更救助状态、标记可领养；领养人提交申请后，状态进入领养审核中，此时只有管理员能审批通过或拒绝。
把这个状态机落到代码里，有两种常见做法。一种是用一个status字段存整型，到处写 if/else 判断；另一种是引入状态模式或者用枚举把「当前状态 + 操作」映射到「目标状态 + 权限角色」。我自己的经验是：小项目用枚举加一张状态流转配置表就够了，不必上 workflow 引擎，否则维护成本直接翻倍。
public enum AnimalStatus { PENDING(0, "待审核"), RESCUING(1, "救助中"), ADOPTABLE(2, "待领养"), ADOPTING(3, "领养审核中"), ADOPTED(4, "已领养"), MEDICAL(5, "医疗中"), DECEASED(6, "已死亡"); private final int code; private final String desc; AnimalStatus(int code, String desc) { this.code = code; this.desc = desc; } public int getCode() { return code; } public String getDesc() { return desc; } }这段枚举的意义在于把散落在业务代码里的 magic number 收口。后续凡是涉及动物状态的地方，统一引用AnimalStatus.ADOPTABLE这样的常量，而不是直接写数字2。哪怕只是查列表，也要在 SQL 里带上状态条件，避免把已死亡或已安乐的数据混进待领养列表，这是用户最容易投诉的点。
2.2 上报、领养、回访：三个主流程的接口设计差异
三个核心流程的接口设计思路完全不一样，不能套同一个模板。
「发现上报」是高频写操作，而且可能伴随图片、定位、联系电话。这个接口我一般设计成表单提交，接收入口是POST /api/report，内容包含动物类型、发现地点经纬度、描述、图片文件列表、上报人联系方式。这里要注意的是，上报人并不强制注册登录，因为很多捡到流浪动物的路人并不想装 App、注册账号，他们只是路过看一眼，拍张照传上来就走。所以这个接口用匿名提交 + 手机号校验就够了。
「领养申请」则必须走登录态，因为领养人需要承担后续回访责任。这个接口接收领养人 ID、动物 ID、住房情况、养宠经验、工作稳定性等结构化字段。它的设计重点不是写入，而是「同一只动物在待领养状态下只能被一个人正式申请」，需要做好并发控制，否则两个人同时申请同一只猫，后端两个请求都校验通过，就会产生脏数据。
「回访」流程更特殊，它的操作频率低，但记录要完整留痕。领养成功后，管理员需要按照约定时间回访，回访记录包括照片、环境描述、是否仍然养着，这些记录关联到领养关系 ID 而不是动物 ID，因为同一只动物可能被退养后再被领养，记录如果挂在动物上就会串掉。
public class AdoptRecord { private Long id; private Long animalId; private Long applicantId; private Long reportId; // 关联到最初的发现记录 private String address; private String homeType; // 自有住房 / 租房 private String petExperience; // 养宠经验描述 private Integer auditStatus; // 0 待审核 1 通过 2 拒绝 private LocalDateTime createTime; private LocalDateTime auditTime; private String rejectReason; }看一眼这个实体：reportId关联到最初的发现记录，是为了让管理员在审核时能看到完整链路，比如这只动物从哪个区域被捡到、救助过程中做过哪些医疗处理。实际开发中很多人只关联animalId，结果就是领养人申请时，管理员根本看不到这只动物的来路，只能再开一个页面去查，体验很割裂。
2.3 为什么救助站管理端和普通用户端要拆开设计
同一个平台，普通用户看到的是「附近待领养动物列表 + 申请领养 + 我的上报记录」，救助站管理员看到的是「待审核列表、待回访列表、动物档案维护、领养审批队列」。这两个角色的信息密度完全不同，强行复用一套页面模板会让管理员的操作效率变得极低。
管理端我一般单独设计菜单结构：今日待办、上报审核、动物管理、领养管理、回访管理、公告管理、用户管理、数据统计。注意「今日待办」是关键，管理员每天打开系统第一眼看到的是有多少条待审核上报、多少条到期回访，而不是一张冷冰冰的动物总表。这个设计直接决定管理员愿不愿意每天登录系统，如果打开全是散乱的列表，他很快就会改用微信群。
用户端则突出「低门槛」，核心路径是搜索附近的待领养动物、查看动物详情、提交领养申请、查看申请进度。用户端不要暴露「待审核」「救助中」这种后台术语，前端文案应该翻译成「申请已提交」「救助人在确认中」「已通过，等待接宠」这类人话。这里其实是个很常见的设计失误，开发者图省事把后台状态值直接透出到前端，用户看到「ADOPTING」直接懵掉。
数据层面，JDK 自带的HashMap足够应付小规模内存缓存，但平台一旦上线，需要给管理员端的待办列表加一个轻量缓存，避免每次打开都全表扫。这里可以用 Spring Cache + Caffeine 做本地缓存，对「今日待办」只缓存 30 秒，够用且实现简单。
3. 数据库怎么设计：从动物档案到领养关系，这 13 张表够不够用
3.1 动物主表、图片附件、救助记录：一张表的拆分逻辑
数据库设计是整个平台的地基，我在这里吃过不少亏，所以直接把我验证过的一套表结构讲清楚。
最核心的是animal主表，它只记录动物自身的固有属性：名称、种类（猫/狗/其他）、品种、年龄估算、性别、毛色、体型、健康状况摘要、绝育状态、疫苗状态、当前状态、入档时间。注意「健康摘要」「疫苗状态」「绝育状态」这类字段要单独拆成列而不是塞进一个 JSON 里，因为后续列表页需要按「已绝育」「已打疫苗」做筛选，JSON 字段做筛选条件在 MySQL 里很别扭，虽然在 MySQL 5.7 之后有 JSON_EXTRACT 可以用，但索引效率远不如普通列。
图片附件不要直接放在主表里。一张动物可能有 5 到 8 张照片，如果主表设计成photo_urls VARCHAR(2000)存逗号分隔的 URL，后续要删除单张图片时，必须先读出来再拆分重写，不仅麻烦而且容易出错。我采用的是一张animal_image子表，每行存一张图的 URL、顺序、类型（封面/环境图/伤口特写），主图用is_cover标记。
CREATE TABLE `animal_image` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `animal_id` bigint(20) NOT NULL COMMENT '动物ID', `url` varchar(500) NOT NULL COMMENT '图片访问地址', `sort_order` int(11) NOT NULL DEFAULT '0' COMMENT '显示顺序', `is_cover` tinyint(1) NOT NULL DEFAULT '0' COMMENT '是否封面', `create_time` datetime NOT NULL, PRIMARY KEY (`id`), KEY `idx_animal_id` (`animal_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='动物图片表';这里 KEYidx_animal_id必须建，查询动物详情时要一次性取回该动物的全部图片，没有这个索引就是全表扫。is_cover用tinyint(1)是因为 MySQL 的布尔类型本质就是 tinyint，别写成boolean，MyBatis 映射会少一些麻烦。
救助记录表rescue_record则单独记录每次救助行为：动物 ID、救助人 ID、发现位置、发现时间、救助描述、送医机构、医疗花费、是否送检、结果描述。这张表是「待审核」和「救助中」两个状态的数据来源，管理员审核一条上报，本质就是审核这条rescue_record是否真实、信息是否完整、图片能否佐证。
3.2 领养关系表必须把状态流转和联系人拆开
领养关系是整个平台业务闭环中法律效力最强的一环，表结构设计不能太随意。adopt_record前面已经展示过，这里说说它的关键设计点。
第一个关键点是「领养人和上报人很可能不是同一个人」，所以adopt_record必须同时保留applicant_id和report_id，不能只存动物 ID。第二个关键点是申请状态流转字段audit_status不要和动物状态animal.status混在一起，因为「领养申请审核中」和「动物状态待领养」是两个不同维度的状态，前者属于申请记录，后者属于动物档案。第三个关键点是要设置expire_time字段，用于处理「申请通过后领养人超过多少天没来接走，自动释放领养资格」的业务规则。
「回访记录」我单独建表follow_up_record，关联adopt_record_id而不是animal_id，因为回访针对的是「领养人是否履行承诺」这件事。表结构包含：领养记录 ID、回访时间、回访方式（上门/视频/电话）、回访人 ID、动物现状描述、居住环境描述、满意度评级、现场照片 URL、下一步计划。回访是运营层面的核心动作，没有回访记录的领养关系在数据上是不完整的。
3.3 用户表和角色表：志愿者、管理员、普通用户怎么共存
先说结论：用「用户表 + 角色表 + 用户角色关联表」这套经典 RBAC 模型在这个平台够用，但需要在角色上增加「数据范围」的概念，否则志愿者和管理员的权限边界会模糊。
普通用户只操作自己的数据：自己的上报记录、自己的领养申请。志愿者能处理「待审核」状态的数据，但看不到其他维度的敏感数据，比如管理员的后台统计。管理员拥有全部权限，包括用户冻结、动物档案删除、公告发布。
CREATE TABLE `user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `phone` varchar(20) NOT NULL COMMENT '手机号', `password` varchar(100) NOT NULL COMMENT 'BCrypt 加密后的密码', `nickname` varchar(50) DEFAULT NULL, `role_id` bigint(20) NOT NULL DEFAULT '3' COMMENT '角色ID: 1管理员 2志愿者 3普通用户', `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '1正常 0禁用', `create_time` datetime NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';role_id直接冗余在用户表里而不是走关联表，是刻意为之。这个小系统角色数量固定只有三个，完全没必要做用户-角色中间表，一张中间表只会让查询多一次 join，还很考验写 SQL 的人水平。如果后面真的出现「一个用户既是志愿者又是管理员」的需求，再重构也不迟。
密码字段用 BCrypt，不用 MD5。MD5 加盐也不是不行，但 Spring Security 自带的BCryptPasswordEncoder直接可用，没必要自己造轮子。数据库编码统一utf8mb4，因为平台里用户昵称、动物描述可能带 emoji，utf8字符集存不了四个字节的 emoji，utf8mb4才能存。
4. 用 Spring Boot 落地后端接口：登录鉴权、文件上传和列表分页
4.1 基于 Token 的登录方案，为什么比 Session 更省事
流浪动物救助平台很可能既没有独立的 App，也没有复杂的域名体系，前端可能是一个管理后台网页加一个未来要做的微信小程序。Session 方案的痛点在于：小程序端是另一套域名，跨域请求带着 Session Cookie 会被浏览器同源策略拦住，后端配置跨域时还要处理allowCredentials，麻烦得很。
所以用 Token 方案，登录成功后后端签发一个 JWT，前端存到 localStorage 或者小程序的 storage 里，每次请求在Authorization头里带上。后端用拦截器解析 Token，把用户 ID 和角色注入到当前请求上下文中。
@PostMapping("/login") public Result<String> login(@RequestBody LoginRequest req) { User user = userService.findByPhone(req.getPhone()); if (user == null || !passwordEncoder.matches(req.getPassword(), user.getPassword())) { return Result.error("手机号或密码错误"); } if (user.getStatus() == 0) { return Result.error("账号已被禁用"); } String token = JwtUtil.createToken(user.getId(), user.getRoleId()); return Result.ok(token); }JwtUtil.createToken内部用 HS256 算法签名，载荷里只放userId和roleId，不放手机号等敏感信息。过期时间我一般设 7 天，太短会导致用户每天都要重新登录，太长了 Token 泄露后的风险窗口太大。注意 JWT 的 secret 要放到配置文件里，绝不能硬编码在 Java 代码中，否则代码一泄露等于后台裸奔。
4.2 文件上传：给图片加水印、压缩和校验，一个都不能少
救助平台里最多的上传就是动物照片。设计上传接口时，第一件事是限制格式和大小。jpg、png、webp三种格式可以接受，单张大小控制在 5MB 以内。Spring Boot 默认的spring.servlet.multipart.max-file-size是 1MB，需要调大，否则前端传个 3MB 的照片直接被拒。
图片处理后存本地磁盘还是对象存储，取决于部署环境。如果是个人服务器或者学校实验室，我一般建议先存本地磁盘，后面再迁移到 OSS。本地存储时要按日期分子目录，避免一个文件夹下文件数过多，比如/uploads/2025/06/18/uuid.jpg，文件名用UUID重新生成，不保留客户端原始文件名——原始文件名可能包含中文或特殊字符，直接当文件名存会出各种问题。
图片压缩我习惯用Thumbnails库（基于 Java 的图片缩放库），把上传的图片压缩到最大宽度 1200px、质量 0.8。这个操作能显著节省磁盘空间，也提高列表页加载速度。压缩前先判断图片原始尺寸，如果本来就很小就不压缩，避免把清晰的小图压糊。
public String saveImage(MultipartFile file, String subDir) throws IOException { // 1. 校验文件格式 String ext = StringUtils.getFilenameExtension(file.getOriginalFilename()); if (!Arrays.asList("jpg", "jpeg", "png", "webp").contains(ext.toLowerCase())) { throw new BizException("仅支持 jpg/png/webp 格式图片"); } // 2. 压缩图片 BufferedImage src = ImageIO.read(file.getInputStream()); if (src.getWidth() > 1200) { Thumbnails.of(file.getInputStream()) .width(1200) .outputQuality(0.8) .toFile(tempFile); } else { file.transferTo(tempFile); } // 3. 生成存储路径和文件名 String datePath = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyy/MM/dd")); String uuid = UUID.randomUUID().toString().replace("-", ""); String fileName = uuid + "." + ext; String relativePath = "/uploads/" + datePath + "/" + fileName; // 4. 移动文件到最终目录 Path fullPath = Paths.get(uploadRootDir).resolve(relativePath).normalize(); Files.createDirectories(fullPath.getParent()); Files.move(tempFile.toPath(), fullPath, StandardCopyOption.REPLACE_EXISTING); return relativePath; }这段代码里有几个细节实际很容易踩坑。ImageIO.read在遇到损坏的图片文件时会返回null，不做判断直接往下走会空指针，所以要在src为 null 时抛出业务异常。Paths.resolve拼接路径时要防止路径穿越攻击，理论上relativePath是我们自己生成的没有问题，但如果是接收入参就要过滤../。tempFile使用的是File.createTempFile，用完要记得删除，否则临时目录会被垃圾文件塞满。
4.3 列表分页：别把 PageHelper 当银弹，大偏移量慢到怀疑人生
管理端的动物列表、用户列表、领养列表都涉及分页。常见做法是引入 PageHelper 插件，在 Service 层调用PageHelper.startPage(pageNum, pageSize)，紧接着查询语句自动拼接LIMIT。这个插件小项目用着舒服，但有一条红线要记住：必须紧跟 Mapper 查询方法之后调用，中间不能夹任何其他数据库操作，否则分页会作用到错误的查询上。
更值得警惕的是大偏移量翻页。比如管理端在数据积累到几千条后，点击第 100 页，LIMIT 990, 10会让 MySQL 扫描并丢弃前 990 条记录，后面的页码越深越慢。实际处理方式有两种：限制最大页码；或者把LIMIT offset, size改写成WHERE id > #{lastId} LIMIT #{size}这种基于游标的分页方式。
管理端我一般直接禁用深页码，因为运营场景根本不会有人翻到第 50 页去找一只猫。前端分页组件给到最大 100 页就是上限，后端再设一层防线，页码超过阈值直接拒绝。此外，列表查询的表数据要控制在必要字段，不能SELECT *，把description这种长文本带出来会让网络传输和内存白白消耗。
5. 管理端的避坑指南：权限漏洞、状态错乱和消息通知的四个血泪坑
5.1 越权访问：改了 URL 里的 ID 就能看别人的领养申请
这个坑在不少管理端项目里都存在，尤其是列表和详情接口没有做数据权限校验的时候。一个普通用户登录后，如果知道接口规律，比如GET /api/adopt/detail?id=1024，他完全可以把id换成1025、1026，直接看到别人的领养申请详情，包括手机号、家庭住址等隐私信息。
现象：用户反馈说在平台上看到了陌生人的申请单。原因：后端查询详情时只校验了「是否登录」，没有校验「这条记录是否属于当前用户」。解决：所有详情接口先判断当前用户角色，普通用户只能查询applicant_id = 当前用户ID的记录；管理员和志愿者走另一种带权限校验的查询逻辑。
public AdoptRecordDetailVO getAdoptDetail(Long adoptId, User currentUser) { AdoptRecord record = adoptRecordMapper.selectById(adoptId); if (record == null) { throw new BizException("申请记录不存在"); } // 普通用户只能看自己的记录 if (currentUser.getRoleId() == RoleEnum.USER.getCode() && !record.getApplicantId().equals(currentUser.getId())) { throw new BizException("无权查看该申请记录"); } return convertToVO(record); }这段代码的关键就是那句!record.getApplicantId().equals(currentUser.getId())。管理员角色不需要走这个限制，因为管理端本身有权限控制。同时，管理端接口要把敏感字段（身份证号、完整地址）在 VO 层脱敏，只显示部分字符，尽可能减少隐私泄露面。
5.2 状态错乱：同一条领养申请被两个管理员重复审批
团队里多个管理员同时在线时，会出现两个人同时打开同一个待审核申请，A 点了通过，B 也点了通过，最终这条申请被审核了两次。虽然数据库层面最终状态值只有一个，但操作日志里会出现两条审核记录，而且后写入的操作可能把先写入的正确状态覆盖掉。
现象：领养申请状态显示已通过，但操作日志里出现了两条不同管理员的通过记录。原因：审核接口没有做乐观锁或状态前置校验。解决：在更新语句上加上状态条件，只有当当前状态仍然是「待审核」时才允许更新。
@Update("UPDATE adopt_record SET audit_status = #{targetStatus}, " + "auditor_id = #{operatorId}, audit_time = NOW() " + "WHERE id = #{adoptId} AND audit_status = 0") int updateStatusWithLock(Long adoptId, Integer targetStatus, Long operatorId);这个AND audit_status = 0就是乐观锁的思路。更新前数据库会校验该记录当前状态，如果另一个管理员已将其改为 1，那么本次更新影响行数为 0，Service 层判断rows == 0后直接提示「该申请已被处理」。这个方法看似简单，但实际很多项目因为图省事直接写UPDATE ... WHERE id = ?而漏掉了状态条件。
动物状态也是一样的问题。操作「标记待领养」时，SQL 必须带上前置状态条件，比如WHERE id = ? AND status = 1，否则可能出现把已经领养的动物又改回待领养的情况。
5.3 消息通知黑洞：状态变了但用户根本不知道
状态流转链路设计好了、数据库也更新了，但用户端没有收到任何通知，这是平台上线后口碑崩掉的重灾区。上报的流浪动物被管理员审核通过了，用户不知道；提交的领养申请被批准了，用户也不知道，用户只能隔三差五自己进平台刷新查询。
现象：领养人抱怨「申请通过了也没人告诉我，差点错过」。原因：后端只更新了数据库状态，没有触发任何通知机制。解决：在状态变更的 Service 方法里联动发消息。最简单的方案是站内信，在数据库建一张message表，状态变更时插入一条消息，用户下次登录时在顶部铃铛处看到未读红点。这种站内信不需要引入消息队列，一条 insert 语句就够了。
短信通知成本高、接入门槛高，小平台不必一开始就用。微信小程序模板消息是另一个思路，但需要用户在小程序端有 openid 且授权过，属于后续增强项。第一版先做站内信，把「状态变更必定留痕」这个习惯养成，再谈其他渠道。
5.4 图片静置导致磁盘爆满：清理策略和备份策略不能缺席
平台运行几个月后，用户发现上传新照片总是失败，终端查一下磁盘已经 100%。流浪动物平台图片多、体积大，如果没有定时清理机制，磁盘被占满是必然的。还没完——不仅因为上传的照片，还有日志文件、临时文件、数据库 binlog 日志，每一个都在吃磁盘。
现象：服务日志报 No space left on device。原因：没有磁盘空间监控和清理任务。解决：写一个定时任务，每天凌晨删除超过 30 天的日志文件；临时目录每天清理；图片文件按业务保留策略定期清理「与无效记录关联的图片」，比如上报审核未通过的记录 30 天后再删除图片。部署层面，用df -h定时看磁盘水位，低于 20% 预留空间时触发告警。
图片备份这件事，很多小团队直接忽略。但流浪动物平台的图片一旦丢失，损失不可逆。我一般建议：服务器本地磁盘存一份热数据，再用 crontab 每天把上传目录同步到另一个存储位置（另一台机器或对象存储冷备），同步策略用增量即可，不推荐全量每天跑，浪费带宽和时间。
6. 上线前必做的三轮验证：从接口压测到异常恢复的完整检查单
第一轮接口逻辑验证。用 Postman 把核心链路全部跑一遍：匿名用户上报一条动物信息，上传三张图片，管理员审核通过，动物状态变更为待领养；另一个用户登录提交领养申请，管理员审批通过，生成领养记录；之后添加回访记录。每一步都校验数据库落库字段是否准确，状态是否按预期流转。这一轮如果有自动化测试条件，就把状态流转写成单元测试，避免后续重构时改崩核心链路。
第二轮权限矩阵验证。整理一张「角色 × 接口」的表格，逐项核对。普通用户能否访问/api/admin/**路径下的接口；志愿者能否审核上报；未登录用户能否直接调用上报接口。特别注意：接口层面要校验，前端只是控制按钮显隐，不能靠前端隐藏入口来保证安全。前端隐藏一个「删除」按钮很容易，但别人直接 POST 请求删除接口依然有效。
第三轮异常场景恢复验证。模拟文件上传超过大小限制，看后端返回的错误提是否友好；模拟数据库连接断开，看服务能否自动重连；模拟磁盘写满导致图片保存失败，看异常有没有被捕捉并转换成业务错误提示。这些异常场景在开发期大概率不会主动测，等上线后真实发生时才手忙脚乱，不如在上线前花半天时间主动制造故障。
验证做完之后，有个小习惯值得养成：把核心接口的响应时间记下来，存成一个基准值清单。比如动物详情接口平均 120ms，列表接口平均 260ms。这个清单后续每次发版前后拿新数据对比，如果接口突然从 120ms 变成 1.2s，基本就是新增了一条不用索引的 join 查询或者查询条件没带全。这套「基准值对比找问题」的办法，比我遇到过的不少公司靠纯感觉调优要靠谱得多。
我在这个平台上吃过最大的亏，其实就是低估了权限校验的琐碎程度。功能都做完了，以为权限也完了，结果越权接口一测一个准。后来养成的习惯是：每写完一个查询类型的接口，先问自己一句「当前登录用户有没有权利看这几条数据」，然后顺手把校验条件写进去。成本很低，但能省掉后面无数的扯皮和投诉。希望这些踩坑记录能帮你少走一圈弯路。
本文还有配套的精品资源，点击获取
