企业官网建设流程全解析

做宠物爱心组织管理系统这半年，我把SpringBoot后端、Vue前端的各种坑都踩了一遍。这套基于Java+MySQL+MyBatis的宠物爱心组织管理系统，从功能设计到最终落地，中间经历了好几轮推翻重来。今天把整个系统的设计思路、核心代码逻辑和实操中遇到的典型问题完整分享出来，给正在做同类管理系统的朋友一个可以直接参考的版本。

这套系统主要解决宠物救助站、爱心领养组织在日常运营中的信息管理问题：宠物档案混乱、领养申请靠表格登记、捐赠物资去向不明、志愿者排班靠群聊接龙。用系统把这些流程线上化之后，管理员能实时掌握基地的宠物数量、领养进度、物资库存和捐赠明细，申请领养的人也可以在线上提交资料、查看审核进度。适合正在做毕业设计、课程项目，或者接私活做中小型管理系统的开发者参考。

1. 项目整体设计与功能拆解

1.1 需求梳理与模块划分

做管理系统第一步不是写代码，而是先把业务方到底需要管理什么弄清楚。我之前见过太多项目一上来就建表，结果做到一半发现字段不够用或者业务流程对不上，推倒重来非常痛苦。

宠物爱心组织的日常业务大致有这么几块：

• 宠物管理：收录待领养、待救助的宠物信息，包括品种、年龄、健康状态、疫苗情况、照片等。这个模块是整个系统最核心的数据底座，其他模块都围绕它展开。
• 领养管理：领养人提交申请，管理员审核，审核通过后签订电子领养协议，后续还要做回访记录。这里的核心是一套状态流转机制，申请、初审、复审、通过、拒绝、已完成。
• 捐赠管理：记录每一笔资金和物资捐赠，支持导出统计报表。爱心组织最需要财务透明，这个模块一定要有明确的收入台账和物资去向记录。
• 志愿者管理：志愿者报名、排班、服务时长统计。很多组织是兼职志愿者，排班和考勤容易乱，需要用系统来统一协调。
• 活动管理：发布线下领养日活动、募捐活动，志愿者可以在线报名，管理员能看到报名人数和活动反馈。
• 公告与消息：组织动态、寻宠启事、系统通知的发布和展示。

我最后采用的角色权限模型是三种：超级管理员（系统配置）、组织管理员（日常业务管理）、普通用户（领养申请、志愿者报名、捐赠）。这样既覆盖了组织的内部管理需求，又能让外部爱心人士参与进来。

1.2 技术选型为什么选这套组合

技术选型上，SpringBoot + Vue + MySQL + MyBatis这套组合在中小型管理系统里的地位，基本相当于装修界的“轻奢风”——不是最豪华，但足够体面，胜在生态成熟、招聘市场上会的人多、遇到问题百度都有答案。

SpringBoot 2.7.x 是目前最稳妥的选择。网上很多教程用SpringBoot 3.x，但如果你用的是JDK 8，千万别硬上3.x，因为SpringBoot 3最低要求JDK 17，上来就报错。而且SpringBoot 2.7对应的Spring Cloud、MyBatis等生态组件兼容性都验证很充分，不会出现“版本太高没人踩过坑”的尴尬。

MyBatis 选择的是传统XML方式，没有用MyBatis-Plus。原因很简单：这个项目的SQL大多是动态条件查询和跨表关联，手写SQL反而更直观可控，而且面试的时候能讲清楚MyBatis的工作原理。不过要注意MyBatis的一级缓存和二级缓存机制，默认配置下如果开启了二级缓存而Mapper没做正确配置，很容易出现查询到旧数据的问题。

前端Vue选的是2.7+Vue Router 3.x+Element UI，这套组合虽然不算最新，但胜在文档极度丰富、坑基本都被填平了。如果开发周期紧，没必要为了“用最新版本”去冒险用Vue 3的Composition API重写全部代码。等系统稳定运行后，再逐步迁移也不迟。

1.3 数据库表结构设计

表结构是整个系统的地基，我在设计时花了最多心思。核心表有以下几张：

用户表（sys_user）：用户ID、用户名、密码（MD5加盐）、昵称、手机号、邮箱、角色、状态、创建时间。这里要注意用户名要建唯一索引，否则重复用户名插入时只在业务层校验，高并发下会漏掉。

宠物信息表（pet_info）：宠物ID、宠物名称、品种、性别、是否绝育、疫苗状态、健康状况描述、是否可领养、照片URL、救助时间、备注。照片URL我用的是相对路径，绝对路径会导致换了部署环境就全裂。

领养申请表（adopt_apply）：申请ID、关联用户ID、关联宠物ID、申请时间、申请状态、领养原因、居住情况说明、工作状况说明、管理员审核意见、审核人、审核时间。

捐赠记录表（donation_record）：捐赠ID、捐赠人ID、捐赠类型（资金/物资）、金额或物资描述、捐赠时间、收款渠道、备注。资金类关联财务流水号，物资类关联物资库存。

志愿者表（volunteer_info）：志愿者ID、关联用户ID、可服务时间段、擅长领域、累计服务时长、审核状态。

活动表（activity_info）：活动ID、标题、内容、活动时间、活动地点、最大人数、当前报名人数、发布人ID、状态。

物资库存表（material_stock）：物资ID、物资名称、库存量、单位、安全库存阈值、所属仓库、更新时间。每次出入库都要写一条库存流水，否则账实不符时连追查的入口都没有。

我把数据库字符集统一设置为utf8mb4，这个非常重要。之前用过utf8，结果用户填写的生僻字和emoji表情直接存不进去，前台报“Incorrect string value”错误，后来全局排查才发现是字符集问题。utf8mb4是utf8的超集，能存四字节的unicode字符，存储空间差别可以忽略不计。

2. 后端核心实现与关键业务逻辑

2.1 SpringBoot项目结构与分层规范

后端项目包结构我建议按“controller-service-mapper-entity”四层来划分，别图省事把代码全堆在Controller里。我在实际开发中验证过，这种分层方式在系统变复杂之后的价值会越来越明显。

com.pet.organization ├── controller // 接收前端请求，做参数校验 ├── service // 业务逻辑处理层 ├──── impl // service实现类 ├── mapper // MyBatis数据访问接口 ├── entity // 数据库表映射实体类 ├── dto // 前端传输对象，避免直接把实体返回给前端 ├── common // 全局返回结果、异常处理、工具类 ├── config // 配置类（跨域、拦截器等） └── constant // 常量定义

Controller层只做参数接收和结果返回，不写任何业务逻辑。Service层处理业务流程，Mapper层只负责SQL操作。前端返回统一封装Result对象，格式为code+message+data，这样前端只要判断code是否等于200就能统一处理成功和失败，代码会清爽很多。

一个我特别想强调的实践：实体对象不要直接返回给前端，而是转成DTO。原因是数据库表字段可能包含内部信息（如创建人ID、逻辑删除标记），直接暴露给前端既不安全也不灵活。初期我觉得多写一层DTO是浪费时间，后来前端同事需要一个新的字段组合，如果没有DTO层，要么加冗余字段，要么前端多请求一次接口，反而更麻烦。

2.2 MyBatis动态SQL的应用细节

宠物管理模块有个核心查询场景：列表页根据品种、健康状态、是否可领养、时间范围等条件进行组合筛选。这种需求用MyBatis动态SQL处理再合适不过了。

<select id="selectPetList" resultType="com.pet.organization.entity.PetInfo"> SELECT * FROM pet_info <where> <if test="petName != null and petName != ''"> AND pet_name LIKE CONCAT('%', #{petName}, '%') </if> <if test="variety != null and variety != ''"> AND variety = #{variety} </if> <if test="healthStatus != null and healthStatus != ''"> AND health_status = #{healthStatus} </if> <if test="adoptable != null"> AND adoptable = #{adoptable} </if> <if test="startTime != null"> AND create_time &gt;= #{startTime} </if> <if test="endTime != null"> AND create_time &lt;= #{endTime} </if> </where> ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} </select>

这里有几个坑要注意。<where>标签的两个缩写scanWhere，我之前见过有程序员在<if>后面加AND 1=1的写法，虽然也能跑，但MyBatis官方推荐的写法就是用<where>标签自动去掉首个多余的AND。另外XML中的>和<不能直接写，必须用>和<转义，不然XML解析直接报错，这个报错信息不明显，排查起来很费时间。

关于Limit分页，小数据量项目用MySQL的LIMIT加偏移量就够了，但数据量超过几十万之后性能会退化，这时候需要改成基于游标的分页方式。对这套管理系统而言，宠物和活动数据量通常不会特别大，用基础的分页方式即可。

MyBatis还有一个容易踩的坑：默认开启了下划线到驼峰的自动映射的话，实体字段要和表字段严格对应。我一直保持数据库字段用下划线命名（create_time），Java实体用驼峰命名（createTime），然后在mybatis-config.xml里配置map-underscore-to-camel-case为true，这样写SQL时连resultMap都可以省一部分。但如果某个表字段不按这个规则命名，就会静默映射失败，返回null，排查时先检查这里。

2.3 领养审核的完整业务逻辑

领养申请是系统里业务逻辑最复杂的环节，因为它的状态流转涉及申请方和管理员双方，而且每个节点都有前置条件。

我的状态定义是常量化的：

public interface AdoptStatus { Integer PENDING = 1; // 待审核 Integer APPROVED = 2; // 审核通过 Integer REJECTED = 3; // 已拒绝 Integer COMPLETED = 4; // 已完成领养 Integer CANCELED = 5; // 已取消 }

用户提交申请后，状态置为PENDING。管理员审核时，系统自动检查宠物是否已被其他用户锁定或者已经被领养，如果宠物不可用，直接提示“该宠物暂不可领养”并拒绝操作。

审核通过时，要做几件事：更新申请状态、把宠物的adoptable改成0（不可领养）、记录审核人和审核时间。这里我用了事务注解@Transactional，确保要么全部成功，要么全部回滚。之前没有加事务的时候，出现过申请状态更新了但宠物状态没改的中间状态，对接下来的业务流程产生了严重干扰。

审核拒绝时，用户需要看到明确的拒绝原因。我要求管理员必须在审核意见字段填写原因，不能留空。前端页面上用状态tag的颜色区分不同状态（待审核黄色、通过绿色、拒绝红色），用户进来一眼就能看到自己的申请进展。

这里分享一个细节：审核操作要加乐观锁。并发场景下，同一个管理员可能打开多个页面同时审核同一个申请，或者两个管理员同时处理一个申请，直接update会把状态覆盖错。我在申请表加了version字段，update的时候带上where version = #{version}，更新成功version自增，更新失败说明已被他人处理，需要刷新重新判断。这个机制在面试里也是加分项。

3. 前端Vue的设计与开发记录

3.1 环境搭建的版本选型

前端部分我是从环境搭建开始踩坑的。先说结论：Node.js版本选择16.x或18.x LTS，Vue CLI版本选择5.x，Element UI版本选择2.15.x，这套组合在Windows和macOS上都很稳。

npm安装依赖阶段经常遇到的问题有两个：一是网络慢导致超时，二是依赖之间版本冲突。我的建议是在项目根目录配置.npmrc文件：

registry=https://registry.npm.taobao.org/ sass_binary_site=https://npm.taobao.org/mirrors/node-sass/

node-sass这个包非常坑，在Node.js 16上编译经常报错。如果项目全部是纯JavaScript代码，尽量别用sass，直接用Element UI自带的主题变量定制或者less都行。如果非要用scss，推荐改用dart-sass（项目里直接npm install sass --save-dev即可），兼容性比node-sass好得多。

Vue项目的目录结构我按这个来组织：

src ├── api // axios接口请求封装 ├── assets // 静态资源 ├── components // 公共组件 ├── router // 路由配置 ├── store // Vuex状态管理 ├── views // 页面组件 ├── utils // 工具函数 └── App.vue

关键点在于api目录要按业务模块拆成多个文件，比如pet.js、adopt.js、donate.js，每个文件里用函数导出具体的请求方式，页面里只调函数，不直接写axios。这样后端接口调整URL时只需要改一个文件，全局生效。

3.2 权限控制与路由守卫

菜单和按钮的权限控制，我是通过动态路由配合Vuex来实现的。用户登录成功后，后端返回该用户所有角色和权限标识列表，前端根据权限标识过滤路由表，再通过router.addRoutes动态注入可访问的路由。

路由守卫的逻辑在router/index.js里：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path === '/login') { next() return } if (!token) { next({ path: '/login', query: { redirect: to.fullPath } }) return } if (to.meta && to.meta.roles && !to.meta.roles.includes(store.state.user.role)) { next('/403') return } next() })

这里有个比较容易踩的坑：刷新页面的时候Vuex里的用户信息会被清空，动态路由会丢失，导致刷新后访问某个二级路由直接404。解决方案是在main.js入口文件里，在router.beforeEach中判断如果Vuex中没有用户信息但localStorage有token，就调用后端接口重新拉取用户信息，再放行路由。这一步很多人会忘记，但它是刷新后体验是否流畅的关键。

按钮级别的权限，我用自定义指令v-permission来实现。例如删除宠物这个按钮需要admin权限：

<el-button v-if="$store.state.user.role === 'admin'" type="danger">删除</el-button>

如果只是控制少数几个按钮，直接用v-if判断就可以，没必要引入复杂的权限组件。项目核心是业务功能的稳定性，权限控制做到“菜单路由+关键按钮显隐”这个粒度就足够了。

3.3 宠物管理页面的实现要点

宠物列表页是系统里最常操作的页面，也是我做得最细致的一个页面。整体布局是顶部搜索栏（品种下拉、健康状态下拉、可领养状态、搜索按钮）、中间表格展示宠物信息、底部为分页组件。

Element UI的el-table在数据量大时需要设置height属性，这样表格内部滚动而不会把整个页面撑得无限长。分页组件要配合后端的pageNum、pageSize参数，我把分页逻辑封装成了一个混入对象mixin，多个列表页共用一套逻辑，代码复用率很高。

图片展示是个容易被忽视的细节。宠物照片我用el-image组件渲染，设置了preview-src-list预览属性和懒加载lazy。后端存储的图片URL可能是相对路径，前端axios请求时统一用baseURL拼接域名前缀，这样换服务器或改端口只需要改环境变量，不用动业务代码。

表单验证方面，领养申请表单里手机号和身份证号的正则校验必须严格，不能用简单的必填校验糊弄：

rules: { phone: [ { required: true, message: '请输入手机号', trigger: 'blur' }, { pattern: /^1[3-9]\d{9}$/, message: '手机号格式不正确', trigger: 'blur' } ], reason: [ { required: true, message: '请填写领养原因', trigger: 'blur' }, { min: 10, max: 200, message: '领养原因请控制在10-200字', trigger: 'blur' } ] }

为什么领养原因要限制最小长度？这是在实操中发现的问题。最早我允许用户填一个“喜欢”两个字就提交，管理员看到这种申请根本没办法判断领养人的养宠条件，审核效率极低。加上10字最小长度后，申请质量明显提升，因为用户被引导去描述自己的居住环境、养宠经验，审核通过率也高了。

3.4 数据可视化与统计报表

捐赠管理模块我加了一个简单的数据可视化页面，用ECharts绘制月度捐赠额的柱状图和捐赠类型的饼图。这个页面虽然本身不复杂，但效果很直观，组织负责人看报表方便很多。

后端提供一个聚合统计接口，按月份分组汇总捐赠数据：

SELECT DATE_FORMAT(create_time, '%Y-%m') AS month, SUM(amount) AS total_amount FROM donation_record WHERE donation_type = 1 AND create_time >= #{startTime} GROUP BY month ORDER BY month DESC

前端配合ECharts的data属性直接就渲染成图表。整个实现不超过100行代码，但对这个系统来说，价值感提升非常明显。很多爱心组织需要公示捐款数据来获取公众信任，这个图表导出发给捐赠人看，能省去大量沟通成本。

这里提醒一下：ECharts中文文档里说引入的时候用完整包import * as echarts from 'echarts'就行，但这样包体积会比较大，升级为按需引入会更合理。不过按需引入配置略麻烦，如果是管理系统后台，加载慢一点也无所谓，我实际项目中直接用了完整包，开发效率更高。

4. 部署上线与避坑实录

4.1 数据库初始化和基础数据准备

数据库用Navicat或者命令行执行建表SQL都可以，但有个易忽略的问题：MySQL 5.7和MySQL 8.0的语法差异。MySQL 8.0默认已经有了utf8mb4，而MySQL 5.7需要指定。如果你在本机装了MySQL 5.7.44，部署到服务器变成MySQL 8.0.28，SQL脚本最好在SQL Mode上面做兼容处理，例如去掉默认的ONLY_FULL_GROUP_BY，不然GROUP BY查询可能直接报错。

另一个常见问题：MySQL 5.7的密码字段格式和8.0不同，导出导入账号信息的时候可能会出现认证插件不兼容，连接时直接报“Authentication plugin 'caching_sha2_password' cannot be loaded”。遇到这个问题，创建用户时用：

CREATE USER 'pet'@'%' IDENTIFIED WITH mysql_native_password BY 'password';

这一步很关键，很多部署环境是云数据库，本地连接正常但线上连不上，大概率就是认证插件版本不一致导致的。

初始化数据方面，我一次性导入了10条测试宠物记录、3个测试活动、2个志愿者，这样开发环境一启动页面就有数据展示，不会显得空。实际上线前再清理测试数据即可。还有一点：生产库的admin初始密码，上线前一定要改掉，默认密码123456这种一定要在手册里写明修改步骤。

4.2 前后端分离部署的跨域问题

跨域永远是前后端分离项目绕不过去的坑。开发环境下，前端跑在8080端口，后端跑在8081端口，前端请求后端的接口如果没有做跨域处理，浏览器会直接拦截，控制台报“No 'Access-Control-Allow-Origin' header is present”。

我的解决方案是在后端写一个全局CORS配置类，继承WebMvcConfigurer：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

允许所有来源是因为系统本身没有对外部来源做严格的跨域限制，内网部署时安全风险可控。但如果你部署在公网且有用户角色概念，这里建议把allowedOriginPatterns改成白名单模式，只允许特定域名的跨域请求。

不过我实际部署线上时更推荐用Nginx反向代理来解决跨域。Nginx把前端页面和后端接口放在同一个域名下面，路径/api开头的请求都代理到后端的8081端口。这样浏览器视角看到的全是同源请求，根本不会存在跨域问题，而且Nginx还能帮忙做静态资源缓存和Https证书配置，等于一个方案解决三个问题。

Nginx的配置片段：

location /api/ { proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; add_header Access-Control-Allow-Origin *; }

这里注意proxy_pass后面是否带路径最后斜杠，带不带斜杠会改变请求路径的拼接规则，网上很多帖子没讲清楚，实际配置错了接口全404，排错要花不少时间。

4.3 打包构建的实战记录

前端用npm run build命令打包，默认输出到dist目录。这个目录里是纯静态文件，直接扔到Nginx的html目录或者用CDN分发都可以。但有一个配置必须注意：Vue Router如果用了history模式，刷新某个子路径页面时后端会找不到路径，出现404。

解决方法是Nginx的try_files指令：

location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }

这个配置的意思是碰到请求先尝试找对应文件，找不到就回退到index.html，由前端路由去兜底。如果用了hash模式（URL带#），就没有这个问题。我最终选择的是history模式加Nginx兜底配置，因为URL更美观。

后端SpringBoot打包用mvn clean package -DskipTests生成jar包，这里注意跳过测试这个参数必须带着，否则如果单元测试因为MySQL版本问题报错，整个打包流程就会卡住。打包后直接用java -jar启动：

java -jar pet-management-system.jar --spring.profiles.active=prod

不同环境的配置用application-dev.yml和application-prod.yml分离，数据库连接、Redis地址、文件上传路径都按环境区分。这个习惯在开发期看不出差别，到了上线部署的时候能帮你省掉很多“本地好好的，线上怎么就崩了”的排查时间。

4.4 配置总结与优化建议

关于系统上线后的性能问题，我实际测试后给出几个结论：

• 单台4核8G的云服务器，部署这套前后端分离系统完全够用，并发几百个用户同时访问不会出现明显卡顿。
• 数据库连接池配置Druid，初始连接数5，最小空闲连接数5，最大活跃连接数20，这个配置在小规模系统下是合理的。
• 网关层面不引入，直接用Nginx做代理和静态资源缓存。网关虽好，但对这个体量的系统属于过度设计，引入反而增加排查复杂度。
• 日志用logback框架，输出到文件并按天滚动。排查线上问题时，日志就是救命稻草，一定要在部署的时候确认好日志目录有磁盘空间。

缓存方面，宠物列表这种热点数据其实可以用Redis做缓存来提升访问速度，但要注意缓存和数据库的一致性。我这套系统没有引入Redis，原因在于数据量不大、访问频率不高，直接查MySQL的性能已经足够。对于爱心组织常见的业务规模，简化架构反而更容易维护。如果后续宠物数量突破几万条，再考虑引入缓存也不迟。

5. 实际开发中遇到的典型问题

5.1 后端环境问题排查

问题一：JDK版本和SpringBoot版本不匹配。刚开始用了SpringBoot 3.0.2但系统只装了JDK 8，启动直接报“Unsupported class file major version 61”，这是因为SpringBoot 3编译版本要求Java 17。我的解决方案是统一降到JDK 8 + SpringBoot 2.7.x。如果你电脑里装了多个JDK版本，建议在IDEA里面设置好Project SDK，不要去改系统的JAVA_HOME，否则其他软件可能受影响。

问题二：MySQL 5.7在Windows 10上安装容易卡在最后一步“Apply Security Settings”报错。常见原因是之前的残留服务没卸载干净，或者3306端口被占用。先netstat -ano查看端口占用情况，找到占用进程后在任务管理器里结束掉，再重新安装基本就没问题了。如果还报错，检查MySQL服务是否已经在服务管理器里存在，存在就先删除残留服务再重装。

5.2 前端环境问题排查

问题一：Failed to load tsconfig '@vue/tsconfig/tsconfig.web.json': tsconfig not found。这个错误只出现在项目引用了 @vue/tsconfig 包但没有正确安装依赖的情况下。检查 package.json 里 devDependencies，确认 @vue/tsconfig 存在且版本对应上，然后npm install重新安装一次。如果还是报错，可以把 tsconfig.json 里 extends 的路径改成相对路径指向 node_modules，这种问题多半是npm安装不完整。

问题二：Vue项目源码发给别人运行后，对方环境一致但页面白屏，控制台报模块找不到。九成原因是双方的依赖版本不一致，项目里的package-lock.json没有提交到版本库。这个文件必须提交，它能锁死所有依赖的确切版本。同理还有.npmrc文件，如果不提交，对方拉代码后npm install可能就从官方源下载，速度慢不说还可能版本有偏差。

问题三：npm install特别慢或者报ETIMEDOUT。可以用国内镜像源，但要注意淘宝镜像源已经切换了新域名，老的有段时间会跳转。推荐用npmmirror.com这个官方地址，在项目根目录执行：

npm config set registry https://registry.npmmirror.com

配置完成后通过npm config get registry验证是否生效，再重新npm install，速度会快很多。

5.3 系统运行中的业务逻辑问题

我在测试阶段发现一个比较典型的问题：管理员在后台修改宠物状态时，没有校验该宠物是否已被领养申请锁定，导致用户看到宠物的“可领养”状态与实际时间不一致。这个问题的根源是宠物状态和申请状态之间的同步关系没有理清楚。

最终方案是宠物状态改为：可领养、已被申请、已领养、休息中四种状态。“已被申请”状态是中间过渡态，用户提交申请后自动切换，管理员审核通过后变成“已领养”，审核拒绝后自动回滚为“可领养”。这样整个状态机就完整了，不会再出现数据不一致的问题。

另一个问题是志愿者服务时长统计的准确性。最初设计是活动结束后手动录入时长，结果发现管理员经常忘记录，月底统计不准确。后来改成活动创建时预估时长，活动结束后根据实际签到情况自动累计，管理员只需要修改误差，省了很多事。这说明系统中能够自动化的环节，尽量别依赖人工操作。

6. 关于这套系统的经验总结

做这类管理系统，最大的感受是：技术栈本身没有太多值得炫技的地方，真正拉开差距的是对业务的理解和对细节的把控。我刚动手写代码时只想着把CRUD跑通，后来深入业务才发现，光是一个宠物领养状态的流转就涉及申请、审核、回访、终止等多个环节，每一步的状态变更都要有据可查。

我建议拿到类似管理系统需求时，先花至少两天时间梳理业务流程，画清楚角色和操作的关系，再动手建表，同时把状态枚举、全局异常、统一返回体这些基础架构搭好。骨架稳了，后面填业务功能的速度会快很多，返工的几率也大大降低。

另外，这套项目的源码和数据库脚本，我整理成了一个可以直接运行的版本，包含完整的初始化SQL和前后端完整代码。这里的要点是：数据库脚本一定要包含创建数据库的语句和默认管理员账号，别让拿到代码的人还要自己去改配置文件才能启动。我在分享代码之前都会自己从头拉代码再跑一遍，确保别人拿到手可以直接启动。

最后再分享一个我踩过好多次的坑：修改代码前一定要先跑一遍原有功能，确定改动的副作用范围。做过管理系统的都知道，改动一个公共组件或者一个工具方法，可能牵连七八个页面。代码里多写点注释，命名别用拼音缩写，两个月后你自己回来翻代码的时候，一定会感谢当时的自己。这套宠物爱心组织管理系统，从设计到上线大概用了三周时间，中间反复调整优化用了两周，整体工作量在同类项目中算是比较标准的。希望这篇分享能帮你少踩几个坑，尤其是那些报错信息特别不直观的问题，提前知道，能省下大把时间。