1. 为什么选这套组合SpringBootVue3MyBatis的真实理由宠物领养系统这个选题几乎是Java后端学习路上的标准动作。不管是毕业设计、课程项目还是想充实简历的练手项目它都有个非常典型的特点业务逻辑不复杂但覆盖面很全——用户体系、内容发布、状态审核、数据检索、前后端交互该有的环节一个不少。而这种体量的系统恰好就是SpringBootVue3MyBatis这套组合最擅长的战场。先说后端。SpringBoot把SSM时代那一堆繁琐的XML配置砍掉之后一个宠物领养系统从零搭建到跑通业务效率比传统方式高出一大截。它内置的自动配置机制能把数据源、事务、Web容器这些基础设施全部托管起来我们只需要关心业务代码。MyBatis则负责把SQL从Java代码里剥离出去尤其是领养系统里那些涉及多表联查、条件筛选、状态统计的查询写在XML里比写在注解里清晰得多也更容易调整。再说前端。Vue3的Composition API对这类管理后台展示页混合型项目非常友好。宠物列表的筛选逻辑、领养申请的表单校验、管理端的审核操作这些功能用ref、reactive和computed组织起来代码比Options API更紧凑逻辑复用也方便。配合Vite的极速冷启动前后端联调时改一行代码几十毫秒就能看到效果这种体验感在Vue2Webpack时代是可望不可及的。加上MySQL做数据持久化这套SpringBootVue3MyBatisMySQL的组合本质上就是当前中小型Web项目的主流配置。选它来做宠物领养系统不是因为它是某个大厂的高端架构而是因为它最贴近真实企业项目的开发模式——前后端分开部署、接口文档驱动联调、Git各管各的分支。从这个角度说做完这个项目学到的不是怎么写一个宠物领养系统而是一个真实Web项目是怎么组织起来的。2. 数据库设计领养业务的核心在状态流转2.1 四张核心表和一对多关系的梳理宠物领养系统听起来业务简单但数据库设计上有一个容易犯的错误只盯着宠物表和用户表忽略了领养这个行为本身是要被跟踪和记录的。我实际做的表结构是这样的user用户表id、username、password加密存储、phone、email、avatar、role区分管理员和普通用户、status是否封禁、create_time。管理员和普通用户用同一个表加角色字段区分而不是拆成两张表是因为两者的公共字段远多于差异字段拆表带来的查询复杂度完全不值得。pet宠物表id、name、category猫/狗/其他、breed品种、age、gender、is_neutered是否绝育、vaccine_status疫苗情况、description详细描述、images图片URL多张用逗号分隔、status0-待审核1-已上架2-已领养3-已下架、publisher_id发布人、create_time、update_time。adoption_application领养申请表id、pet_id、applicant_id、reason领养理由、home_condition居住情况、experience养宠经验、status0-待审核1-已通过2-已拒绝3-已完成、apply_time、audit_time、auditor_id。favorite收藏表id、user_id、pet_id、create_time。这四张表的关系是用户一对多发布宠物宠物一对多接收领养申请用户一对多发起领养申请用户和宠物通过收藏表形成多对多关系。看起来简单但真正运行起来后你会发现adoption_application这张表才是整个系统的核心——它是状态流转的主战场也是并发问题最容易爆发的地方。2.2 领养状态机的设计思路领养系统的业务规则核心是一个状态机宠物从发布到被领养中间要经过发布→审核→上架→申请→审核通过→完成这六个节点。很多初学方案把状态设计得非常随意想到哪写哪导致后端的if/else越来越乱。我的做法是先把状态流图画清楚宠物发布后进入待审核状态管理员通过后变为上架此时用户才能看到并提交领养申请管理员在收到申请后可以选择通过或拒绝通过后宠物状态改为已领养用户的申请记录标记为已完成。这个设计里有一个容易被忽略的点宠物状态和领养申请状态必须分开管理但又需要保持联动。举个例子管理员在审核领养申请时需要同时更新adoption_application.status和pet.status两块数据。如果不加控制就会出现申请状态是已通过但宠物状态还是上架中这种数据不一致的问题。解决办法有两个层面数据库层面在审批时先检查宠物当前是否处于可领养状态用UPDATE pet SET status 2 WHERE id ? AND status 1来保证原子性代码层面把状态变更封装在同一个事务方法里任何一步失败就整体回滚。提示状态字段建议用数字而不要用字符串。一来数据库存储和索引更高效二来避免了字符串拼写不统一的问题。前端展示层再通过枚举或字典把它们映射成对应的中文文案。3. 后端落地SpringBoot分层架构与MyBatis的实战用法3.1 项目初始化与目录结构设计我初始化的项目用的是SpringBoot 2.7.x版本这个版本是个稳定舒适区——既兼容JDK 8/11又保留了javax命名空间网上绝大多数教程和踩坑资料都适配它。如果选SpringBoot 3.x就要求JDK 17以上而且所有依赖里的javax.servlet会变成jakarta.servlet很多第三方整合的示例代码直接跑不通对新手来说就是个无底洞。后端目录结构我按功能包划分com.example.adoption ├── config // 配置类跨域、拦截器、WebMvc ├── controller // 控制层接收请求、返回结果 ├── service // 业务层核心业务逻辑 │ └── impl ├── mapper // MyBatis持久层接口 ├── entity // 实体类 ├── dto // 请求/响应对象用于参数校验和结果封装 ├── vo // 视图对象聚合多表数据 ├── common // 通用类统一返回结果、异常处理、工具类 └── interceptor // JWT拦截器每一层各司其职Controller只做参数接收和结果封装不写任何业务代码Service负责业务逻辑和事务管理Mapper只负责数据库操作。这样分层的好处是当前项目规模不大时感觉有点冗余但一旦领养申请、宠物审核、用户收藏这些功能之间开始互相调用分层清晰的收益就会立刻显现出来。3.2 MyBatis的XML映射和动态SQLMyBatis在这一项目里主要处理三类SQL单表CRUD、多表联查、动态条件筛选。我全程用XML方式写Mapper没有用注解。原因是宠物列表页的查询条件太多了——按分类、品种、年龄、性别、绝育状态、发布时间排序这些条件组合起来可能是十几种情况用动态SQL的where和if标签管理起来清晰直观而注解里拼字符串会疯掉。举个例子宠物列表页的典型查询select idselectPetList resultTypecom.example.adoption.vo.PetVO SELECT p.*, u.username AS publisher_name FROM pet p LEFT JOIN user u ON p.publisher_id u.id where p.status 1 if testcategory ! null and category ! AND p.category #{category} /if if testgender ! null and gender ! AND p.gender #{gender} /if if testkeyword ! null and keyword ! AND (p.name LIKE CONCAT(%, #{keyword}, %) OR p.description LIKE CONCAT(%, #{keyword}, %)) /if choose when testsort newest ORDER BY p.create_time DESC /when otherwise ORDER BY p.create_time ASC /otherwise /choose /where /select这里有个细节where标签会自动去掉第一个多余的AND所以所有条件都可以统一写成AND xxx不用担心拼接问题。新手容易犯的错误是手动拼SQL时忘了处理最后一个条件后面的AND换用MyBatis动态标签之后这类问题从根上被消灭了。3.3 MyBatis条件判断里那个0被吞掉的经典坑这个坑我在实际开发里踩过一次也是很多面试题会问的点。假设要按宠物状态筛选前端传过来status 0待审核状态你写的XML判断是if teststatus ! null and status ! AND p.status #{status} /if看起来天衣无缝对不对但实际执行时会发现status 0这条过滤条件根本没被拼上查询结果把待审核之外的宠物全查出来了。原因是MyBatis的OGNL表达式里0会被解析成Integer类型而是空字符串。OGNL在做0 ! 比较时会尝试把空字符串转成数字转换结果就是0于是0 ! 这个表达式返回false整个if条件被跳过。解决办法有两种。第一种是把判断拆开写只判断nullif teststatus ! null AND p.status #{status} /if第二种更精准用toString()显式声明类型if teststatus ! null and status.toString() ! AND p.status #{status} /if这个坑如果不在还开发阶段发现等到项目上线后管理员筛选列表数据出错排查起来会非常痛苦——因为问题出在看不见的动态SQL拼接阶段而不是明显的报错信息。类似的坑在MyBatis里其实不少后面我会专门列一个踩坑清单。3.4 领养审核流程中的事务与并发控制领养审核操作是系统中最需要谨慎处理的接口。管理员点击通过按钮后端要做的事情是校验申请状态、更新申请状态为已通过、更新宠物状态为已领养、给申请者留一条状态变更记录。这个过程必须包在事务里。我用Transactional注解处理事务Transactional(rollbackFor Exception.class) public void approveAdoption(Integer applicationId, Integer adminId) { // 1. 查询申请记录并校验状态 AdoptionApplication app adoptionApplicationMapper.selectById(applicationId); if (app null || app.getStatus() ! 0) { throw new BusinessException(申请记录不存在或已被处理); } // 2. 原子性更新申请状态 int rows adoptionApplicationMapper.updateStatus(applicationId, 1, adminId); if (rows 0) { throw new BusinessException(申请已被其他人处理请刷新后重试); } // 3. 原子性更新宠物状态确保宠物仍处于可领养状态 int petRows petMapper.updateStatusByCondition(app.getPetId(), 1, 2); if (petRows 0) { throw new BusinessException(该宠物已被领养请刷新后重试); } }这里最关键的是updateStatus和updateStatusByCondition这两个用了条件更新的SQL。它们不是先查后改那样在并发场景下会有竞态条件而是直接把当前状态必须是待处理/上架中作为WHERE条件写进UPDATE语句通过数据库行锁来保证并发安全。两个管理员同时审核同一申请时只有一个能更新成功另外一个拿到rows 0直接提示已被处理。这种写法比加SELECT FOR UPDATE锁更轻量也比在Java代码层用synchronized更可靠——因为集群部署时synchronized只能锁住单个实例而数据库条件更新是全局生效的。4. Vue3前端从登录到领养申请的双角色工程4.1 Vite初始化与工程结构前端我用Vite创建Vue3项目这一步比Vue CLI快得不是一星半点npm create vuelatest # 根据提示选择需要的特性TypeScript选NoRouter选YesPinia选Yes工程结构按模块划分src ├── api // 接口请求封装 ├── assets // 静态资源 ├── components // 通用组件 ├── router // 路由配置 ├── stores // Pinia状态 ├── views // 页面视图 │ ├── home // 前台展示 │ ├── admin // 管理后台 │ └── user // 用户中心 ├── utils // 工具函数 └── App.vue一个容易忽略的细节是alias配置。默认情况下Vite里需要用相对路径../../来找组件一旦目录嵌套深了非常痛苦。在vite.config.js里配置好别名后就可以用/components/PetCard.vue这样的绝对方式导入了import { defineConfig } from vite import vue from vitejs/plugin-vue import path from path export default defineConfig({ plugins: [vue()], resolve: { alias: { : path.resolve(__dirname, src) } } })4.2 跨域问题前后端分离的第一个拦路虎前后端分离开发第一个遇到的问题必然是跨域。前端跑在http://localhost:5173后端跑在http://localhost:8080两者端口不同浏览器直接请求就会触发CORS拦截。我在后端配置类里统一处理跨域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(*)配合allowCredentials(true)时不能使用*通配具体域名否则部分浏览器会拦截携带Cookie的请求。更严谨的做法是把前端域名明确写出来比如https://www.example.com。4.3 路由守卫与动态侧边栏宠物领养系统有前台用户和管理员两类角色两者的权限差异很大普通用户看到的是首页、宠物列表、领养申请、个人中心管理员看到的是宠物审核、领养审核、用户管理、数据统计。我用路由守卫在前端做了拦截控制。路由配置里给每个页面标记需要的角色{ path: /admin, component: () import(/views/admin/AdminLayout.vue), meta: { requiresAuth: true, role: ROLE_ADMIN }, children: [ { path: pet-audit, component: () import(/views/admin/PetAudit.vue) }, { path: adoption-audit, component: () import(/views/admin/AdoptionAudit.vue) } ] }然后在全局前置守卫里检查router.beforeEach((to, from, next) { const token localStorage.getItem(token) const userInfo JSON.parse(localStorage.getItem(userInfo) || {}) if (to.meta.requiresAuth !token) { next(/login) return } if (to.meta.role to.meta.role ! userInfo.role) { next(/403) return } next() })这套方案足够应对当前项目规模。但要说清楚一个事实前端路由守卫只是优化体验的手段真正的权限控制必须后端接口层也做。因为前端所有的JS代码用户都能看到绕过路由守卫直接调后端接口是很容易的事情。所以我的后端在每个需要权限的接口上都加了RequireRole类似的注解校验前端守卫只是让普通用户看不到入口而已。4.4 领养申请表单一个实战级的表单校验案例领养申请表单是整个前端交互最复杂的部分。它不仅字段多领养理由、居住情况、养宠经验而且提交后要处理三种状态待审核、已通过、已拒绝。已拒绝时还要显示原因。我用Element Plus的el-form做校验规则配置如下const rules { reason: [ { required: true, message: 请填写领养理由, trigger: blur }, { min: 10, max: 500, message: 领养理由需在10到500字之间, trigger: blur } ], homeCondition: [ { required: true, message: 请选择居住情况, trigger: change } ], experience: [ { required: true, message: 请选择养宠经验, trigger: change } ] }提交前检查是否重复申请过同一只宠物——这个逻辑我放在后端接口里做了因为前端只能做显性校验防不了恶意请求。后端查询逻辑是public void applyAdoption(AdoptionApplicationDTO dto, Integer userId) { // 校验同一用户不能重复申请同一只宠物 Integer count adoptionApplicationMapper.countByPetAndApplicant(dto.getPetId(), userId); if (count 0) { throw new BusinessException(您已申请过该宠物请勿重复申请); } // 校验宠物必须处于上架状态 Pet pet petMapper.selectById(dto.getPetId()); if (pet null || pet.getStatus() ! 1) { throw new BusinessException(该宠物暂不可领养); } // 插入申请记录 }4.5 宠物卡片列表的渲染与图片懒加载前台首页的宠物列表用栅格布局展示宠物卡片每张卡片包含宠物照片、名字、品种、性别、年龄标签。图片加载方面我用Vue3自定义指令实现了懒加载只有图片进入视口才真正加载数据避免首屏加载几十张图把带宽吃满。const lazyLoad { mounted(el, binding) { const observer new IntersectionObserver((entries) { if (entries[0].isIntersecting) { el.src binding.value observer.unobserve(el) } }) observer.observe(el) } }5. 图片上传、分页查询与MyBatis分页插件的整合5.1 图片上传本地存储还是对象存储宠物领养系统里图片是刚需一只待领养的宠物至少需要上传3-5张照片。我用的是本地磁盘存储方案后端接收MultipartFile保存到服务器指定目录然后把访问路径返回给前端存到数据库。public String uploadImage(MultipartFile file) { // 校验文件类型和大小 if (file.isEmpty() || file.getSize() 5 * 1024 * 1024) { throw new BusinessException(图片大小不能超过5MB); } String originalFilename file.getOriginalFilename(); String suffix originalFilename.substring(originalFilename.lastIndexOf(.)); ListString allowedSuffix Arrays.asList(.jpg, .jpeg, .png, .gif); if (!allowedSuffix.contains(suffix.toLowerCase())) { throw new BusinessException(不支持的图片格式); } // 生成唯一文件名避免重名覆盖 String fileName UUID.randomUUID().toString().replace(-, ) suffix; String dateDir new SimpleDateFormat(yyyyMMdd).format(new Date()); File dir new File(UPLOAD_DIR dateDir); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir.getAbsolutePath() File.separator fileName)); // 返回访问URL return /upload/ dateDir / fileName; }在WebMvcConfig里把/upload/**映射为静态资源Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file: UPLOAD_DIR); }本地方案的好处是简单、零成本适合开发和单机部署。但坦白说项目真要上线到云服务器上我建议换成云存储——本地磁盘扩容是运维噩梦而云存储自带CDN加速访问速度也更快。不过对练手项目本地完全够用。5.2 分页查询MyBatis分页插件的正确用法宠物列表和领养申请列表都必须分页否则数据量一上来页面会卡死。我用的PageHelper分页插件整合步骤极简第一步引入依赖dependency groupIdcom.github.pagehelper/groupId artifactIdpagehelper-spring-boot-starter/artifactId version1.4.7/version /dependency第二步业务方法里直接使用public PageResultPetVO getPetList(PetQueryDTO query) { PageHelper.startPage(query.getPageNum(), query.getPageSize()); ListPetVO list petMapper.selectPetList(query); PageInfoPetVO pageInfo new PageInfo(list); return new PageResult(pageInfo.getTotal(), pageInfo.getList()); }PageHelper.startPage()之后紧跟着的第一条SQL会被自动加上LIMIT语句。这里有个必须牢记的规矩startPage之后必须紧跟一个Mapper查询方法中间不要插入任何其他数据库操作否则分页会作用到错误的SQL上。分页插件还有一些高级用法比如PageInfo里自带pageNum、pageSize、pages总页数、isFirstPage、isLastPage等字段前端直接用就行不用自己算。5.3 数据统计与首页大屏管理后台我加了一个简单的数据统计页面展示宠物总数、上架宠物数、待审核宠物数、本月领养成功数。这些统计用一条聚合SQL完成select idselectDashboardStats resultTypecom.example.adoption.vo.DashboardVO SELECT (SELECT COUNT(*) FROM pet) AS totalPetCount, (SELECT COUNT(*) FROM pet WHERE status 1) AS availablePetCount, (SELECT COUNT(*) FROM pet WHERE status 0) AS pendingPetCount, (SELECT COUNT(*) FROM adoption_application WHERE status 3 AND MONTH(create_time) MONTH(CURRENT_DATE)) AS monthlyAdoptedCount /select这种仪表盘的统计一般不需要实时性要求很高的数据偶尔缓存一下也没问题。6. 开发过程中踩过的坑从环境搭建到上线部署6.1 IDEA创建SpringBoot项目版本陷阱与选型建议用IDEA的Spring Initializr创建项目时默认选择的SpringBoot版本很可能是3.x。如果本机JDK是8或11这时要么手动改成2.7.x要么升级JDK到17。我实际开发时选了2.7.x原因很实际很多组件比如某些工作流引擎、支付SDK对SpringBoot 3的支持还不够成熟网上可查的资料也大量集中在2.x时代。如果确实想用SpringBoot 3.x一定要提前确认几个配套组件的版本兼容性MyBatis的mybatis-spring-boot-starter要用2.3.x以上版本PageHelper要用1.4.6以上版本并且注意javax到jakarta的包名变更。这些细节都确认清楚再开始不然开发到一半被依赖冲突卡住非常折磨。6.2 MySQL安装配置免安装版的正确姿势MySQL的安装是这套项目里最容易卡住新手的一环。我用的免安装版zip解压版比msi安装包更可控具体步骤从官网下载zip压缩包解压到指定目录路径不要有中文和空格。在解压目录下创建my.ini配置文件设置basedir和datadir路径。以管理员身份打开命令行执行mysqld --initialize-insecure初始化这样root用户默认空密码。执行mysqld --install注册为Windows服务然后net start mysql启动。用mysql -u root -p登录执行ALTER USER rootlocalhost IDENTIFIED BY 你的密码;设置密码。配置数据库连接信息时SpringBoot的application.yml里要设置时区和字符集spring: datasource: url: jdbc:mysql://localhost:3306/adoption?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver特别注意serverTimezone必须配不配的话连接会报时区错误。useSSLfalse是因为本地开发不需要SSL加密不加访问时会有一大堆警告日志。6.3 JWT登录鉴权拦截器里的白名单登录鉴权我用JWT实现。用户登录成功后后端签发一个带用户ID和角色信息的Token返回前端前端每次请求在Authorization头带上Token后端通过拦截器解析Token把当前用户信息放到ThreadLocal里供业务代码使用。拦截器里一个容易遗漏的点是白名单配置。登录、注册、宠物列表、宠物详情这些接口不应该需要登录才能访问否则游客连首页都看不了。我在拦截器里维护了一个白名单数组private static final String[] WHITE_LIST { /api/auth/login, /api/auth/register, /api/pet/list, /api/pet/detail/**, /upload/** };/upload/**也必须放行不然宠物列表页的图片会因为没带Token而加载失败——这个坑我实际遇到过排查半天才发现是拦截器把静态资源也拦截了。6.4 打包部署前端Nginx 后端Jar的经典组合项目开发完成后部署上线我采用的标准策略是前端用Nginx托管后端打包成Jar用java -jar运行MySQL用系统服务。前端打包命令npm run build打包完成后dist目录里的静态文件上传到服务器Nginx配置如下server { listen 80; server_name example.com; # 前端静态文件 root /usr/share/nginx/html; index index.html; # 前端路由history模式需要配置try_files location / { try_files $uri $uri/ /index.html; } # 反向代理后端接口 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 上传的图片 location /upload/ { proxy_pass http://127.0.0.1:8080; } }try_files $uri $uri/ /index.html这一行必须配否则前端路由用了history模式时用户在非首页刷新会报404。后端Jar启动命令我一般用nohup java -jar -Xms256m -Xmx512m adoption-system.jar app.log 21 nohup保证SSH断开后进程不退出-Xms和-Xmx控制JVM堆内存大小。日志输出到app.log出问题时方便排查。6.5 我在实际开发中最后悔没早点做的事做完这个项目复盘有一个心得想分享一定要从第一周就把接口文档写好不要等联调的时候再补。我一开始图快接口参数改了又改前后端通过聊天工具反复确认浪费了大量时间。后来用类似Apifox或者直接在后端Swagger加注解的方式把接口文档生成出来前端照着文档调接口后端照着文档做自测效率至少提升一倍。哪怕是一个人同时写前后端这个习惯也值得养成——因为一周后你自己回头看自己写的接口也会忘记当时设计时的细节。另外一个建议是单元测试。领养审核这种核心流程我用JUnit写了几条测试用例包括正常审批、重复审批、宠物状态异常等场景每次改完代码跑一遍就能确认核心逻辑没被改坏。虽然写测试短期内看起来浪费时间但如果项目稍后还要继续迭代这笔投资回报率极高。7. 功能演示与项目扩展这套架构还能怎么玩宠物领养系统跑通之后可以沿着几个方向扩展既是简历亮点也是技术深度的体现消息通知模块领养申请状态变化后给用户发送站内信或邮件通知。技术实现上可以在申请状态变更的地方发布一个Spring事件ApplicationEvent监听器里异步处理通知逻辑这样核心审核逻辑不会因为通知发送失败而回滚。全文检索宠物列表页的关键字搜索目前只是SQL的LIKE模糊查询数据量大时性能会遇到瓶颈。可以引入Elasticsearch把宠物信息建立索引检索速度和相关性都会大幅提升。这个扩展对简历的加分效果非常明显。Redis缓存热点数据宠物详情页通常是访问最频繁的接口可以把热点宠物的详情数据缓存到Redis里设置过期时间减少数据库压力。用SpringCacheRedis整合改造成本很低。图片懒加载再优化目前粗粒度查看了正确的本地实现如果换用CDN缩略图方案上传时同时生成缩略图列表页加载缩略图详情页加载原图页面性能还会有明显改善。从一个技术练手项目的角度这套SpringBootVue3MyBatisMySQL的组合已经足够让你完整经历一个Web应用从需求分析、数据库设计、前后端开发到打包部署的全过程。认真做完再针对上面的扩展方向挑一个深入研究无论是继续做毕设还是写进简历做项目经验都完全拿得出手。
1. 为什么选这套组合SpringBootVue3MyBatis的真实理由宠物领养系统这个选题几乎是Java后端学习路上的标准动作。不管是毕业设计、课程项目还是想充实简历的练手项目它都有个非常典型的特点业务逻辑不复杂但覆盖面很全——用户体系、内容发布、状态审核、数据检索、前后端交互该有的环节一个不少。而这种体量的系统恰好就是SpringBootVue3MyBatis这套组合最擅长的战场。先说后端。SpringBoot把SSM时代那一堆繁琐的XML配置砍掉之后一个宠物领养系统从零搭建到跑通业务效率比传统方式高出一大截。它内置的自动配置机制能把数据源、事务、Web容器这些基础设施全部托管起来我们只需要关心业务代码。MyBatis则负责把SQL从Java代码里剥离出去尤其是领养系统里那些涉及多表联查、条件筛选、状态统计的查询写在XML里比写在注解里清晰得多也更容易调整。再说前端。Vue3的Composition API对这类管理后台展示页混合型项目非常友好。宠物列表的筛选逻辑、领养申请的表单校验、管理端的审核操作这些功能用ref、reactive和computed组织起来代码比Options API更紧凑逻辑复用也方便。配合Vite的极速冷启动前后端联调时改一行代码几十毫秒就能看到效果这种体验感在Vue2Webpack时代是可望不可及的。加上MySQL做数据持久化这套SpringBootVue3MyBatisMySQL的组合本质上就是当前中小型Web项目的主流配置。选它来做宠物领养系统不是因为它是某个大厂的高端架构而是因为它最贴近真实企业项目的开发模式——前后端分开部署、接口文档驱动联调、Git各管各的分支。从这个角度说做完这个项目学到的不是怎么写一个宠物领养系统而是一个真实Web项目是怎么组织起来的。2. 数据库设计领养业务的核心在状态流转2.1 四张核心表和一对多关系的梳理宠物领养系统听起来业务简单但数据库设计上有一个容易犯的错误只盯着宠物表和用户表忽略了领养这个行为本身是要被跟踪和记录的。我实际做的表结构是这样的user用户表id、username、password加密存储、phone、email、avatar、role区分管理员和普通用户、status是否封禁、create_time。管理员和普通用户用同一个表加角色字段区分而不是拆成两张表是因为两者的公共字段远多于差异字段拆表带来的查询复杂度完全不值得。pet宠物表id、name、category猫/狗/其他、breed品种、age、gender、is_neutered是否绝育、vaccine_status疫苗情况、description详细描述、images图片URL多张用逗号分隔、status0-待审核1-已上架2-已领养3-已下架、publisher_id发布人、create_time、update_time。adoption_application领养申请表id、pet_id、applicant_id、reason领养理由、home_condition居住情况、experience养宠经验、status0-待审核1-已通过2-已拒绝3-已完成、apply_time、audit_time、auditor_id。favorite收藏表id、user_id、pet_id、create_time。这四张表的关系是用户一对多发布宠物宠物一对多接收领养申请用户一对多发起领养申请用户和宠物通过收藏表形成多对多关系。看起来简单但真正运行起来后你会发现adoption_application这张表才是整个系统的核心——它是状态流转的主战场也是并发问题最容易爆发的地方。2.2 领养状态机的设计思路领养系统的业务规则核心是一个状态机宠物从发布到被领养中间要经过发布→审核→上架→申请→审核通过→完成这六个节点。很多初学方案把状态设计得非常随意想到哪写哪导致后端的if/else越来越乱。我的做法是先把状态流图画清楚宠物发布后进入待审核状态管理员通过后变为上架此时用户才能看到并提交领养申请管理员在收到申请后可以选择通过或拒绝通过后宠物状态改为已领养用户的申请记录标记为已完成。这个设计里有一个容易被忽略的点宠物状态和领养申请状态必须分开管理但又需要保持联动。举个例子管理员在审核领养申请时需要同时更新adoption_application.status和pet.status两块数据。如果不加控制就会出现申请状态是已通过但宠物状态还是上架中这种数据不一致的问题。解决办法有两个层面数据库层面在审批时先检查宠物当前是否处于可领养状态用UPDATE pet SET status 2 WHERE id ? AND status 1来保证原子性代码层面把状态变更封装在同一个事务方法里任何一步失败就整体回滚。提示状态字段建议用数字而不要用字符串。一来数据库存储和索引更高效二来避免了字符串拼写不统一的问题。前端展示层再通过枚举或字典把它们映射成对应的中文文案。3. 后端落地SpringBoot分层架构与MyBatis的实战用法3.1 项目初始化与目录结构设计我初始化的项目用的是SpringBoot 2.7.x版本这个版本是个稳定舒适区——既兼容JDK 8/11又保留了javax命名空间网上绝大多数教程和踩坑资料都适配它。如果选SpringBoot 3.x就要求JDK 17以上而且所有依赖里的javax.servlet会变成jakarta.servlet很多第三方整合的示例代码直接跑不通对新手来说就是个无底洞。后端目录结构我按功能包划分com.example.adoption ├── config // 配置类跨域、拦截器、WebMvc ├── controller // 控制层接收请求、返回结果 ├── service // 业务层核心业务逻辑 │ └── impl ├── mapper // MyBatis持久层接口 ├── entity // 实体类 ├── dto // 请求/响应对象用于参数校验和结果封装 ├── vo // 视图对象聚合多表数据 ├── common // 通用类统一返回结果、异常处理、工具类 └── interceptor // JWT拦截器每一层各司其职Controller只做参数接收和结果封装不写任何业务代码Service负责业务逻辑和事务管理Mapper只负责数据库操作。这样分层的好处是当前项目规模不大时感觉有点冗余但一旦领养申请、宠物审核、用户收藏这些功能之间开始互相调用分层清晰的收益就会立刻显现出来。3.2 MyBatis的XML映射和动态SQLMyBatis在这一项目里主要处理三类SQL单表CRUD、多表联查、动态条件筛选。我全程用XML方式写Mapper没有用注解。原因是宠物列表页的查询条件太多了——按分类、品种、年龄、性别、绝育状态、发布时间排序这些条件组合起来可能是十几种情况用动态SQL的where和if标签管理起来清晰直观而注解里拼字符串会疯掉。举个例子宠物列表页的典型查询select idselectPetList resultTypecom.example.adoption.vo.PetVO SELECT p.*, u.username AS publisher_name FROM pet p LEFT JOIN user u ON p.publisher_id u.id where p.status 1 if testcategory ! null and category ! AND p.category #{category} /if if testgender ! null and gender ! AND p.gender #{gender} /if if testkeyword ! null and keyword ! AND (p.name LIKE CONCAT(%, #{keyword}, %) OR p.description LIKE CONCAT(%, #{keyword}, %)) /if choose when testsort newest ORDER BY p.create_time DESC /when otherwise ORDER BY p.create_time ASC /otherwise /choose /where /select这里有个细节where标签会自动去掉第一个多余的AND所以所有条件都可以统一写成AND xxx不用担心拼接问题。新手容易犯的错误是手动拼SQL时忘了处理最后一个条件后面的AND换用MyBatis动态标签之后这类问题从根上被消灭了。3.3 MyBatis条件判断里那个0被吞掉的经典坑这个坑我在实际开发里踩过一次也是很多面试题会问的点。假设要按宠物状态筛选前端传过来status 0待审核状态你写的XML判断是if teststatus ! null and status ! AND p.status #{status} /if看起来天衣无缝对不对但实际执行时会发现status 0这条过滤条件根本没被拼上查询结果把待审核之外的宠物全查出来了。原因是MyBatis的OGNL表达式里0会被解析成Integer类型而是空字符串。OGNL在做0 ! 比较时会尝试把空字符串转成数字转换结果就是0于是0 ! 这个表达式返回false整个if条件被跳过。解决办法有两种。第一种是把判断拆开写只判断nullif teststatus ! null AND p.status #{status} /if第二种更精准用toString()显式声明类型if teststatus ! null and status.toString() ! AND p.status #{status} /if这个坑如果不在还开发阶段发现等到项目上线后管理员筛选列表数据出错排查起来会非常痛苦——因为问题出在看不见的动态SQL拼接阶段而不是明显的报错信息。类似的坑在MyBatis里其实不少后面我会专门列一个踩坑清单。3.4 领养审核流程中的事务与并发控制领养审核操作是系统中最需要谨慎处理的接口。管理员点击通过按钮后端要做的事情是校验申请状态、更新申请状态为已通过、更新宠物状态为已领养、给申请者留一条状态变更记录。这个过程必须包在事务里。我用Transactional注解处理事务Transactional(rollbackFor Exception.class) public void approveAdoption(Integer applicationId, Integer adminId) { // 1. 查询申请记录并校验状态 AdoptionApplication app adoptionApplicationMapper.selectById(applicationId); if (app null || app.getStatus() ! 0) { throw new BusinessException(申请记录不存在或已被处理); } // 2. 原子性更新申请状态 int rows adoptionApplicationMapper.updateStatus(applicationId, 1, adminId); if (rows 0) { throw new BusinessException(申请已被其他人处理请刷新后重试); } // 3. 原子性更新宠物状态确保宠物仍处于可领养状态 int petRows petMapper.updateStatusByCondition(app.getPetId(), 1, 2); if (petRows 0) { throw new BusinessException(该宠物已被领养请刷新后重试); } }这里最关键的是updateStatus和updateStatusByCondition这两个用了条件更新的SQL。它们不是先查后改那样在并发场景下会有竞态条件而是直接把当前状态必须是待处理/上架中作为WHERE条件写进UPDATE语句通过数据库行锁来保证并发安全。两个管理员同时审核同一申请时只有一个能更新成功另外一个拿到rows 0直接提示已被处理。这种写法比加SELECT FOR UPDATE锁更轻量也比在Java代码层用synchronized更可靠——因为集群部署时synchronized只能锁住单个实例而数据库条件更新是全局生效的。4. Vue3前端从登录到领养申请的双角色工程4.1 Vite初始化与工程结构前端我用Vite创建Vue3项目这一步比Vue CLI快得不是一星半点npm create vuelatest # 根据提示选择需要的特性TypeScript选NoRouter选YesPinia选Yes工程结构按模块划分src ├── api // 接口请求封装 ├── assets // 静态资源 ├── components // 通用组件 ├── router // 路由配置 ├── stores // Pinia状态 ├── views // 页面视图 │ ├── home // 前台展示 │ ├── admin // 管理后台 │ └── user // 用户中心 ├── utils // 工具函数 └── App.vue一个容易忽略的细节是alias配置。默认情况下Vite里需要用相对路径../../来找组件一旦目录嵌套深了非常痛苦。在vite.config.js里配置好别名后就可以用/components/PetCard.vue这样的绝对方式导入了import { defineConfig } from vite import vue from vitejs/plugin-vue import path from path export default defineConfig({ plugins: [vue()], resolve: { alias: { : path.resolve(__dirname, src) } } })4.2 跨域问题前后端分离的第一个拦路虎前后端分离开发第一个遇到的问题必然是跨域。前端跑在http://localhost:5173后端跑在http://localhost:8080两者端口不同浏览器直接请求就会触发CORS拦截。我在后端配置类里统一处理跨域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(*)配合allowCredentials(true)时不能使用*通配具体域名否则部分浏览器会拦截携带Cookie的请求。更严谨的做法是把前端域名明确写出来比如https://www.example.com。4.3 路由守卫与动态侧边栏宠物领养系统有前台用户和管理员两类角色两者的权限差异很大普通用户看到的是首页、宠物列表、领养申请、个人中心管理员看到的是宠物审核、领养审核、用户管理、数据统计。我用路由守卫在前端做了拦截控制。路由配置里给每个页面标记需要的角色{ path: /admin, component: () import(/views/admin/AdminLayout.vue), meta: { requiresAuth: true, role: ROLE_ADMIN }, children: [ { path: pet-audit, component: () import(/views/admin/PetAudit.vue) }, { path: adoption-audit, component: () import(/views/admin/AdoptionAudit.vue) } ] }然后在全局前置守卫里检查router.beforeEach((to, from, next) { const token localStorage.getItem(token) const userInfo JSON.parse(localStorage.getItem(userInfo) || {}) if (to.meta.requiresAuth !token) { next(/login) return } if (to.meta.role to.meta.role ! userInfo.role) { next(/403) return } next() })这套方案足够应对当前项目规模。但要说清楚一个事实前端路由守卫只是优化体验的手段真正的权限控制必须后端接口层也做。因为前端所有的JS代码用户都能看到绕过路由守卫直接调后端接口是很容易的事情。所以我的后端在每个需要权限的接口上都加了RequireRole类似的注解校验前端守卫只是让普通用户看不到入口而已。4.4 领养申请表单一个实战级的表单校验案例领养申请表单是整个前端交互最复杂的部分。它不仅字段多领养理由、居住情况、养宠经验而且提交后要处理三种状态待审核、已通过、已拒绝。已拒绝时还要显示原因。我用Element Plus的el-form做校验规则配置如下const rules { reason: [ { required: true, message: 请填写领养理由, trigger: blur }, { min: 10, max: 500, message: 领养理由需在10到500字之间, trigger: blur } ], homeCondition: [ { required: true, message: 请选择居住情况, trigger: change } ], experience: [ { required: true, message: 请选择养宠经验, trigger: change } ] }提交前检查是否重复申请过同一只宠物——这个逻辑我放在后端接口里做了因为前端只能做显性校验防不了恶意请求。后端查询逻辑是public void applyAdoption(AdoptionApplicationDTO dto, Integer userId) { // 校验同一用户不能重复申请同一只宠物 Integer count adoptionApplicationMapper.countByPetAndApplicant(dto.getPetId(), userId); if (count 0) { throw new BusinessException(您已申请过该宠物请勿重复申请); } // 校验宠物必须处于上架状态 Pet pet petMapper.selectById(dto.getPetId()); if (pet null || pet.getStatus() ! 1) { throw new BusinessException(该宠物暂不可领养); } // 插入申请记录 }4.5 宠物卡片列表的渲染与图片懒加载前台首页的宠物列表用栅格布局展示宠物卡片每张卡片包含宠物照片、名字、品种、性别、年龄标签。图片加载方面我用Vue3自定义指令实现了懒加载只有图片进入视口才真正加载数据避免首屏加载几十张图把带宽吃满。const lazyLoad { mounted(el, binding) { const observer new IntersectionObserver((entries) { if (entries[0].isIntersecting) { el.src binding.value observer.unobserve(el) } }) observer.observe(el) } }5. 图片上传、分页查询与MyBatis分页插件的整合5.1 图片上传本地存储还是对象存储宠物领养系统里图片是刚需一只待领养的宠物至少需要上传3-5张照片。我用的是本地磁盘存储方案后端接收MultipartFile保存到服务器指定目录然后把访问路径返回给前端存到数据库。public String uploadImage(MultipartFile file) { // 校验文件类型和大小 if (file.isEmpty() || file.getSize() 5 * 1024 * 1024) { throw new BusinessException(图片大小不能超过5MB); } String originalFilename file.getOriginalFilename(); String suffix originalFilename.substring(originalFilename.lastIndexOf(.)); ListString allowedSuffix Arrays.asList(.jpg, .jpeg, .png, .gif); if (!allowedSuffix.contains(suffix.toLowerCase())) { throw new BusinessException(不支持的图片格式); } // 生成唯一文件名避免重名覆盖 String fileName UUID.randomUUID().toString().replace(-, ) suffix; String dateDir new SimpleDateFormat(yyyyMMdd).format(new Date()); File dir new File(UPLOAD_DIR dateDir); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir.getAbsolutePath() File.separator fileName)); // 返回访问URL return /upload/ dateDir / fileName; }在WebMvcConfig里把/upload/**映射为静态资源Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file: UPLOAD_DIR); }本地方案的好处是简单、零成本适合开发和单机部署。但坦白说项目真要上线到云服务器上我建议换成云存储——本地磁盘扩容是运维噩梦而云存储自带CDN加速访问速度也更快。不过对练手项目本地完全够用。5.2 分页查询MyBatis分页插件的正确用法宠物列表和领养申请列表都必须分页否则数据量一上来页面会卡死。我用的PageHelper分页插件整合步骤极简第一步引入依赖dependency groupIdcom.github.pagehelper/groupId artifactIdpagehelper-spring-boot-starter/artifactId version1.4.7/version /dependency第二步业务方法里直接使用public PageResultPetVO getPetList(PetQueryDTO query) { PageHelper.startPage(query.getPageNum(), query.getPageSize()); ListPetVO list petMapper.selectPetList(query); PageInfoPetVO pageInfo new PageInfo(list); return new PageResult(pageInfo.getTotal(), pageInfo.getList()); }PageHelper.startPage()之后紧跟着的第一条SQL会被自动加上LIMIT语句。这里有个必须牢记的规矩startPage之后必须紧跟一个Mapper查询方法中间不要插入任何其他数据库操作否则分页会作用到错误的SQL上。分页插件还有一些高级用法比如PageInfo里自带pageNum、pageSize、pages总页数、isFirstPage、isLastPage等字段前端直接用就行不用自己算。5.3 数据统计与首页大屏管理后台我加了一个简单的数据统计页面展示宠物总数、上架宠物数、待审核宠物数、本月领养成功数。这些统计用一条聚合SQL完成select idselectDashboardStats resultTypecom.example.adoption.vo.DashboardVO SELECT (SELECT COUNT(*) FROM pet) AS totalPetCount, (SELECT COUNT(*) FROM pet WHERE status 1) AS availablePetCount, (SELECT COUNT(*) FROM pet WHERE status 0) AS pendingPetCount, (SELECT COUNT(*) FROM adoption_application WHERE status 3 AND MONTH(create_time) MONTH(CURRENT_DATE)) AS monthlyAdoptedCount /select这种仪表盘的统计一般不需要实时性要求很高的数据偶尔缓存一下也没问题。6. 开发过程中踩过的坑从环境搭建到上线部署6.1 IDEA创建SpringBoot项目版本陷阱与选型建议用IDEA的Spring Initializr创建项目时默认选择的SpringBoot版本很可能是3.x。如果本机JDK是8或11这时要么手动改成2.7.x要么升级JDK到17。我实际开发时选了2.7.x原因很实际很多组件比如某些工作流引擎、支付SDK对SpringBoot 3的支持还不够成熟网上可查的资料也大量集中在2.x时代。如果确实想用SpringBoot 3.x一定要提前确认几个配套组件的版本兼容性MyBatis的mybatis-spring-boot-starter要用2.3.x以上版本PageHelper要用1.4.6以上版本并且注意javax到jakarta的包名变更。这些细节都确认清楚再开始不然开发到一半被依赖冲突卡住非常折磨。6.2 MySQL安装配置免安装版的正确姿势MySQL的安装是这套项目里最容易卡住新手的一环。我用的免安装版zip解压版比msi安装包更可控具体步骤从官网下载zip压缩包解压到指定目录路径不要有中文和空格。在解压目录下创建my.ini配置文件设置basedir和datadir路径。以管理员身份打开命令行执行mysqld --initialize-insecure初始化这样root用户默认空密码。执行mysqld --install注册为Windows服务然后net start mysql启动。用mysql -u root -p登录执行ALTER USER rootlocalhost IDENTIFIED BY 你的密码;设置密码。配置数据库连接信息时SpringBoot的application.yml里要设置时区和字符集spring: datasource: url: jdbc:mysql://localhost:3306/adoption?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver特别注意serverTimezone必须配不配的话连接会报时区错误。useSSLfalse是因为本地开发不需要SSL加密不加访问时会有一大堆警告日志。6.3 JWT登录鉴权拦截器里的白名单登录鉴权我用JWT实现。用户登录成功后后端签发一个带用户ID和角色信息的Token返回前端前端每次请求在Authorization头带上Token后端通过拦截器解析Token把当前用户信息放到ThreadLocal里供业务代码使用。拦截器里一个容易遗漏的点是白名单配置。登录、注册、宠物列表、宠物详情这些接口不应该需要登录才能访问否则游客连首页都看不了。我在拦截器里维护了一个白名单数组private static final String[] WHITE_LIST { /api/auth/login, /api/auth/register, /api/pet/list, /api/pet/detail/**, /upload/** };/upload/**也必须放行不然宠物列表页的图片会因为没带Token而加载失败——这个坑我实际遇到过排查半天才发现是拦截器把静态资源也拦截了。6.4 打包部署前端Nginx 后端Jar的经典组合项目开发完成后部署上线我采用的标准策略是前端用Nginx托管后端打包成Jar用java -jar运行MySQL用系统服务。前端打包命令npm run build打包完成后dist目录里的静态文件上传到服务器Nginx配置如下server { listen 80; server_name example.com; # 前端静态文件 root /usr/share/nginx/html; index index.html; # 前端路由history模式需要配置try_files location / { try_files $uri $uri/ /index.html; } # 反向代理后端接口 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 上传的图片 location /upload/ { proxy_pass http://127.0.0.1:8080; } }try_files $uri $uri/ /index.html这一行必须配否则前端路由用了history模式时用户在非首页刷新会报404。后端Jar启动命令我一般用nohup java -jar -Xms256m -Xmx512m adoption-system.jar app.log 21 nohup保证SSH断开后进程不退出-Xms和-Xmx控制JVM堆内存大小。日志输出到app.log出问题时方便排查。6.5 我在实际开发中最后悔没早点做的事做完这个项目复盘有一个心得想分享一定要从第一周就把接口文档写好不要等联调的时候再补。我一开始图快接口参数改了又改前后端通过聊天工具反复确认浪费了大量时间。后来用类似Apifox或者直接在后端Swagger加注解的方式把接口文档生成出来前端照着文档调接口后端照着文档做自测效率至少提升一倍。哪怕是一个人同时写前后端这个习惯也值得养成——因为一周后你自己回头看自己写的接口也会忘记当时设计时的细节。另外一个建议是单元测试。领养审核这种核心流程我用JUnit写了几条测试用例包括正常审批、重复审批、宠物状态异常等场景每次改完代码跑一遍就能确认核心逻辑没被改坏。虽然写测试短期内看起来浪费时间但如果项目稍后还要继续迭代这笔投资回报率极高。7. 功能演示与项目扩展这套架构还能怎么玩宠物领养系统跑通之后可以沿着几个方向扩展既是简历亮点也是技术深度的体现消息通知模块领养申请状态变化后给用户发送站内信或邮件通知。技术实现上可以在申请状态变更的地方发布一个Spring事件ApplicationEvent监听器里异步处理通知逻辑这样核心审核逻辑不会因为通知发送失败而回滚。全文检索宠物列表页的关键字搜索目前只是SQL的LIKE模糊查询数据量大时性能会遇到瓶颈。可以引入Elasticsearch把宠物信息建立索引检索速度和相关性都会大幅提升。这个扩展对简历的加分效果非常明显。Redis缓存热点数据宠物详情页通常是访问最频繁的接口可以把热点宠物的详情数据缓存到Redis里设置过期时间减少数据库压力。用SpringCacheRedis整合改造成本很低。图片懒加载再优化目前粗粒度查看了正确的本地实现如果换用CDN缩略图方案上传时同时生成缩略图列表页加载缩略图详情页加载原图页面性能还会有明显改善。从一个技术练手项目的角度这套SpringBootVue3MyBatisMySQL的组合已经足够让你完整经历一个Web应用从需求分析、数据库设计、前后端开发到打包部署的全过程。认真做完再针对上面的扩展方向挑一个深入研究无论是继续做毕设还是写进简历做项目经验都完全拿得出手。
