“宠物商城”这个题目在计算机类毕业设计里属于又经典又常青的存在。每年都有人拿来当毕设每年也都有人做到一半卡壳停在“登录注册写完了下一步不知道干吗”的状态。今天把手上这套基于Web的宠物商城平台编号49149完整拆一遍——不管你是用Java、PHP、Python做后端还是配合C#小程序做客户端业务设计这套东西都是通用的。从需求怎么拆、表怎么建、技术怎么选到订单事务怎么处理、后端怎么部署我尽量讲得实在一点你照着走能少踩不少坑。先交代一下本篇的适用范围。我默认你有基本编程能力至少写过循环、建过类、知道SQL是什么。如果你是刚学完JavaSE就被导师扔来写Spring Boot建议先补一下Maven和HTTP的基础再回来往下看不然中间的依赖配置就够你懵两天。整篇文章的结构是先想清楚项目架构再选好技术路线然后设计表最后写代码和排坑。这个顺序也是我建议你实际开发时遵循的顺序。1. 项目定位与需求拆解打开IDE之前先把思路理清1.1 宠物商城本质上是一套电商系统很多人拿到题目就急着建工程结果页面还没写两张数据库表已经改了三遍。正确的姿势是先想明白宠物商城在业务上跟淘宝、京东没有任何区别只不过商品是猫、狗、猫粮和狗窝。电商核心链路只有一条——商品展示、加购、下单、支付、发货、收货。你把这个链路在脑子里过一遍功能清单自然就出来了前台要有商品列表、商品详情、购物车、订单确认、模拟支付、个人订单。 后台要有商品管理、分类管理、订单处理、用户管理。 底层要有登录鉴权、文件上传、数据统计这些公共能力。项目能不能立住就看这条主链路能不能跑通。好多同学做毕设翻车不是代码能力差而是链路里某个环节断了要么下单不扣库存要么支付完订单状态没变。所以第一步不是写代码是把链路拆清楚每一步对应哪张表、哪个接口先画出来。1.2 功能模块按“用户端后台”两层拆这里给一个可以直接抄的模块拆分表。模块用户端管理后台商品模块分类浏览、关键词搜索、商品详情、收藏商品增删改、上下架、分类维护购物车模块加入购物车、修改数量、删除、批量结算无订单模块创建订单、模拟支付、取消、查看进度订单查询、发货、状态变更用户模块注册、登录、个人信息、收货地址用户列表、禁用/启用公告模块首页公告展示公告发布与下架统计模块首页推荐商品商品数量、订单金额、销量图表这个表的作用不只是开发时的功能规划它同时就是你论文里“系统功能设计”那一章的素材——画用例图、写功能描述全都能从表里抄出来。我见过不少同学等到写论文时才回头整理功能结果发现功能设计得七零八落连用例图都不知道怎么画。开发之前就把这个表填好后面舒服很多。1.3 先做MVP再谈加分功能我强烈建议按“最小可用版本”的思路来做。所谓MVP就是先完成这七个功能注册登录、商品列表、商品详情、购物车、下单、模拟支付、后台商品管理。这七个做完系统已经是一个可以拿出手的完整项目了。剩下的功能都属于锦上添花收藏、评论、销量榜、数据图表、公告、地址管理。这里我得提个很多人都会犯的错以为功能越多分越高于是一股脑加了一堆列表页面每个功能都只做到“能显示数据”的程度。答辩老师随便一问“这个数据的实时性怎么保证”就答不上来。我的建议是加分功能宁可少做但要做闭环。比如收藏功能不做就算了要做就做到详情页可以收藏/取消、收藏按钮有即时反馈、个人中心有收藏列表、点击列表项跳回详情。一个功能自成一环比十个半成品有用得多。2. 技术选型Java、PHP、Python、C#小程序四条路线怎么挑2.1 四种方案横向对比方案后端框架前端方案开发速度工作量答辩亮点适合人群JavaSpring Boot MyBatis PlusVue Element Plus中等偏大工程化、RESTful、JWT鉴权打算找Java后端工作PHPThinkPHP 8 / LaravelVue 或 Bootstrap快适中上手快、部署简单工期紧、纯应付毕设PythonDjango DRFVue 或模板较快适中Django Admin自动后台学Python方向C#小程序ASP.NET Core EF Core微信小程序/uni-app中等偏大小程序实战、跨平台想学C#或小程序开发说实话这四种方案做出来的东西功能上不会有区别区别全在“你会不会讲亮点”和“代码你能不能自己控制住”。选型的唯一原则是选你最有把握的而不是选看起来最高级的。2.2 Java路线Spring Boot MyBatis Plus Vue 的组合如果你打算毕业以后走Java后端方向用Spring Boot做这个项目是当下最优解。我测试过最顺手的一组版本搭配Spring Boot 2.7.x MyBatis Plus 3.5.x MySQL 8.0前端Vue 3 Element Plus Axios鉴权用JWT构建工具用Maven。为什么推荐这套首先是生态成熟你搜“Spring Boot 宠物商城”之类的关键词能找到大量教程踩过的坑几乎都有答案。其次是工程结构清晰controller、service、mapper三层各管各的事答辩时讲“分层设计的好处”会非常顺畅。最后是部署简单Maven打包成一个jar文件服务器上一条java -jar就起来了不需要额外配置Tomcat。核心依赖只需要盯住两个dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency2.3 PHP和Python方案让开发速度最大化PHP这门语言虽然被人黑得很多但做这类管理系统的效率确实高。以ThinkPHP 8为例路由、ORM、验证器都是现成的配合宝塔面板一键部署从开写原型到在线可访问一个周末就能搞定。你要做的核心事情就是把Pet模型、Order模型定义好规则写在模型里控制器里直接调用模型方法就行。Python方案我推荐Django DRF。Django的最大优势在于自带Admin后台建好model后往admin.py里一注册后台增删改查页面就有了等于省出一个完整管理端。前端再用Vue调DRF写的API开发体验很爽。但要注意一个细节Django模型外键一定要设on_delete策略。分类表下面有宠物时如果直接删分类默认行为可能把宠物一起级联删掉我在这里丢过一次演示数据面色相当难看。2.4 C#小程序方案的理解标题里的“C#小程序”通常指两种理解。第一种是后端用C#写ASP.NET Core Web API前端用微信小程序第二种是直接用C#开发桌面端小程序工具但做宠物商城显然第一种更合理。ASP.NET Core和Spring Boot是同一个level的框架EF Core做ORM写起来很优雅。前端微信小程序原生语法加一个登录页、商品列表页、详情页、购物车页就能覆盖核心场景。做小程序必须知道的是真机调试时小程序要求后端接口必须是HTTPS开发期间可以在微信开发者工具里勾选“不校验合法域名”来调试但上线必须准备一个备案域名并配好SSL证书。这个限制不算大坑但经常有人到答辩前才发现接口调不通浪费一整天。3. 数据库设计一张表一张表地建3.1 从业务链路推导出数据表很多新手问“要建几张表”答案是跟着业务走就行。用户要注册所以有user表商品要分类所以有category和pet两张表用户要加购所以有cart表下单所以有orders和order_item收藏、评论、公告、地址这类辅助功能对应favorite、comment、notice、address。表与表之间的关系也很清晰user是核心延伸出cart、orders、favorite、comment、addresspet挂在category下面orders和order_item是一对多。设计的时候把关系写清楚后面所有业务代码都是围绕这些表展开的根本不会乱。3.2 核心建表SQL下面以宠物表pet为例这是整个系统里最核心的商品表CREATE TABLE pet ( id int(11) NOT NULL AUTO_INCREMENT, category_id int(11) NOT NULL COMMENT 分类id, name varchar(50) NOT NULL COMMENT 宠物名称, cover varchar(255) DEFAULT NULL COMMENT 封面图, images text COMMENT 详情图,逗号分隔, price decimal(10,2) NOT NULL COMMENT 售价, original_price decimal(10,2) DEFAULT NULL COMMENT 原价, stock int(11) NOT NULL DEFAULT 0 COMMENT 库存, sales int(11) NOT NULL DEFAULT 0 COMMENT 销量, description text COMMENT 描述, status tinyint(1) NOT NULL DEFAULT 1 COMMENT 1上架 0下架, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category_id (category_id), KEY idx_name (name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT宠物商品表;其他表结构我列一个字段速查表方便你照着一一建出来表关键字段userid, username, password, nickname, phone, avatar, create_timecategoryid, name, iconcartid, user_id, pet_id, quantity, checkedordersid, order_no, user_id, total_price, receiver, phone, address, status, pay_time, create_timeorder_itemid, order_id, pet_id, pet_name, price, quantityfavoriteid, user_id, pet_id, create_timecommentid, pet_id, user_id, content, rating, create_timenoticeid, title, content, create_timeaddressid, user_id, receiver, phone, detail, is_default3.3 订单为什么拆成主表和明细表我见过有同学图省事把订单信息全塞一张表用JSON存商品列表被导师怼到说不出话。拆表的原因很简单一个订单包含多种宠物每种的“价格、数量”都不一样如果塞在同一行里后面做统计、退款、发货都会很痛苦。所以orders负责存订单整体状态和收货信息order_item负责存一个个具体商品。查订单详情时按order_id把明细查出来逐个展示就行。另外三个细节金额字段必须用decimal(10,2)坚决不用float浮点误差在钱上出现就是事故逻辑外键而不是物理外键因为物理外键在后续删除和关联操作上会带来无数麻烦MyBatis Plus的联表查询完全够用user_id、order_no这种查询高频字段加上索引论文里也能写一笔“通过索引优化查询效率”。4. 核心功能实现从注册到下单的完整代码4.1 注册登录与JWT鉴权注册接口的完整逻辑是三件事校验用户名唯一、密码加密、插入用户。密码加密这个点特别重要我见过有同学直接明文存user表答辩老师一打开数据库就笑了。Java里用Spring Security自带的BCrypt即可PostMapping(/register) public Result register(RequestBody User user) { long count userMapper.selectCount( new QueryWrapperUser().eq(username, user.getUsername())); if (count 0) { return Result.error(用户名已存在); } user.setPassword(BCrypt.hashpw(user.getPassword(), BCrypt.gensalt())); userMapper.insert(user); return Result.success(); }登录接口则是查出用户、校验密码、签发一个JWT返回给前端。前端把Token存到本地存储之后每次请求在请求头带上Authorization: Bearer Token后端拦截器统一校验PostMapping(/login) public Result login(RequestBody User user) { User dbUser userMapper.selectOne( new QueryWrapperUser().eq(username, user.getUsername())); if (dbUser null || !BCrypt.checkpw(user.getPassword(), dbUser.getPassword())) { return Result.error(用户名或密码错误); } String token JwtUtil.createToken(dbUser.getId(), dbUser.getUsername()); return Result.success(token); }JWT的好处就是无状态后端不需要存session。Web端和小程序端共用同一套登录逻辑将来接移动端也好扩展。4.2 商品列表、搜索与分页商品接口是日后的访问热点三个维度查询要支持关键词模糊搜名称、分类id过滤、价格排序。用MyBatis Plus的QueryWrapper写起来很直观PagePet page petMapper.selectPage( new Page(current, size), new QueryWrapperPet() .eq(StringUtils.isNotBlank(categoryId), category_id, categoryId) .like(StringUtils.isNotBlank(keyword), name, keyword) .eq(status, 1) .orderByDesc(sort null ? create_time : sort) );这里有个关键细节查询时必须固定status1只把上架的商品展示给用户。不然后台下架的商品还在前台售卖会成为一个业务逻辑bug。另外分页插件要在配置类注册一下Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }4.3 购物车实现逻辑购物车的核心操作就四个加入、列表、修改数量、删除。加购时要先判断库存够不够不能把库存为0的商品加进去同一用户加同一商品时如果已存在则累加数量而不是插入新记录。接口大致是PostMapping(/add) public Result add(RequestBody CartDTO dto) { Pet pet petMapper.selectById(dto.getPetId()); if (pet null || pet.getStock() 0) { return Result.error(商品已下架或库存不足); } Cart cart cartMapper.selectOne(new QueryWrapperCart() .eq(user_id, dto.getUserId()) .eq(pet_id, dto.getPetId())); if (cart null) { cart new Cart(); cart.setUserId(dto.getUserId()); cart.setPetId(dto.getPetId()); cart.setQuantity(1); cartMapper.insert(cart); } else { cart.setQuantity(cart.getQuantity() 1); cartMapper.updateById(cart); } return Result.success(); }这里要提醒的是购物车的user_id必须从前端传递并校验与Token中的用户一致绝不能只信前端。很多同学偷懒直接从前端拿user_id很容易被别人改参数这也是答辩老师喜欢抓的安全漏洞。4.4 下单流程事务和库存是命门下单是整个项目里最有含金量的一段逻辑也是答辩时最值得讲的点。完整流程是接收提交的购物车id列表查出商品计算总价生成订单号写订单主表和明细表扣库存清掉对应购物车记录然后跳转支付。这一串操作里只要有一半成功一半失败数据就全乱了。所以必须用事务保证原子性。Spring里直接在方法上标注TransactionalTransactional public OrderVO createOrder(OrderCreateDTO dto) { ListCart carts cartMapper.selectBatchIds(dto.getCartIds()); if (carts.isEmpty()) { throw new RuntimeException(购物车为空); } BigDecimal total BigDecimal.ZERO; String orderNo System.currentTimeMillis() (int)((Math.random() * 9 1) * 1000); for (Cart cart : carts) { Pet pet petMapper.selectById(cart.getPetId()); if (pet.getStock() cart.getQuantity()) { throw new RuntimeException(商品[ pet.getName() ]库存不足); } total total.add(pet.getPrice().multiply(BigDecimal.valueOf(cart.getQuantity()))); } Orders order new Orders(); order.setOrderNo(orderNo); order.setUserId(dto.getUserId()); order.setTotalPrice(total); order.setStatus(0); ordersMapper.insert(order); for (Cart cart : carts) { Pet pet petMapper.selectById(cart.getPetId()); OrderItem item new OrderItem(); item.setOrderId(order.getId()); item.setPetId(pet.getId()); item.setPetName(pet.getName()); item.setPrice(pet.getPrice()); item.setQuantity(cart.getQuantity()); orderItemMapper.insert(item); petMapper.update(null, new UpdateWrapperPet() .setSql(stock stock - cart.getQuantity()) .setSql(sales sales cart.getQuantity()) .eq(id, pet.getId())); } cartMapper.deleteBatchIds(dto.getCartIds()); return buildOrderVO(order); }这个方法的亮点也就是你答辩时可以讲三分钟的东西在于 第一为什么用selectBatchIds而不循环查是为了减少数据库I/O 第二扣库存用的是条件更新SQL而不是先查后改避免并发时库存变成负数 第三所有写操作都在同一个事务里任何一个环节异常都会整体回滚。4.5 模拟支付与订单状态机个人开发拿不到微信/支付宝的企业商户号所以毕设里统一采用“模拟支付”。支付页放一个“确认支付”按钮点击后调后端接口把订单状态从0待付款改成1已付款记录支付时间就完成了。从业务上这就是一个完整的状态机流转。订单状态建议定义为0待付款、1已付款/待发货、2已发货/待收货、3已完成、4已取消。后台每完成一步前台订单列表的进度条就向前走一格。讲清楚这套状态机比接一个真的支付通道更能体现你对业务的理解。如果真想接真实支付答辩前跟导师确认资质是个绕不开的问题但这已经超出系统设计本身了。5. 前端与小程序端让项目完整落地5.1 管理后台用现成框架还是自己写管理后台我推荐两种做法根据你的时间预算来。第一种用RuoYi若依这类开源框架二次开发。它自带用户权限、菜单管理、代码生成器你只要定义好数据表代码生成器就能生成增删改查页面。适合时间紧张或者想要“系统很完整”观感的人。缺点是需要花时间熟悉它的结构。第二种自己写一个轻量后台。前端用vue-element-admin的简化版后端自己起一套简单的增删改查接口页面不用多把商品管理、订单管理、用户管理三个页面做精致就够了。对毕设来说“少而精”的后台其实比堆功能的后台更稳。我自己更倾向于第二种因为每个接口都是自己写的答辩被问时不会露怯。用若依的话一旦老师问到代码生成器的内部原理答不上来会比较尴尬。5.2 用户端核心页面要点用户端页面有一个原则主流程页面必须完整不只停留在UI。我给你列一下每个页面的核心交互首页顶部搜索框、轮播图、宠物分类导航、今日推荐商品卡片。搜索框要能跳转到列表页并带上关键词。 商品列表页分类tab切换、筛选条件、卡片网格、空状态提示、分页加载。筛选参数要用query参数存到url里刷新不丢。 商品详情页图片预览、名称价格、库存/销量信息、收藏按钮、加入购物车和立即购买。库存信息要实时显示归零时禁用按钮。 购物车页商品勾选与全选、数量加减组件、合计金额实时计算、“结算”按钮进入下单页。 结算页收货人信息、商品清单、总价、提交订单按钮。订单提交后跳转模拟支付页。页面的交互细节能体现你这套系统的完成度。比如购物车数量减到0时给出删除确认商品缺货时打上“已下架”水印这些都是加分点。5.3 小程序端如何复用这套后端如果选了C#小程序或者微信小程序路线前端完全复用不了Vue页面但要调用的后端接口完全一样。小程序端一般只需要做五个页面登录、首页、商品列表、商品详情、购物车/订单。小程序的登录逻辑和Web略有区别Web是用户名密码登录小程序推荐先用wx.login拿到code再传给后端换取用户信息或者为了省事沿用Web的用户名密码登录也行就是体验差一点。数据同步方面要注意小程序和Web如果同时放出去演示用户数据是共享的后台看到的数据要一致。域名和HTTPS的问题前面说过开发阶段记得在开发者工具里关闭域名校验上线前再改成正式域名。6. 实战踩坑这些问题我全都遇到过6.1 环境搭建问题速查表现象原因解决方案Maven依赖一直下载中默认中央仓库访问慢在settings.xml配阿里云镜像启动Spring Boot报端口占用8080被其他进程占用netstat -ano|findstr 8080找到PID后killMySQL连接失败时区参数没配jdbc连接串加serverTimezoneAsia/ShanghaiVue安装依赖卡住npm源慢设置npm config set registry https://registry.npmmirror.com前端请求接口404后端路径和前端url没对齐把前后端日志打开逐一核对请求路径我多说一句端口占用这个问题十个人里有九个会遇到。Windows用户用netstat -ano找到8080的PID然后在任务管理器里结束进程就能解决不用重启电脑。6.2 跨域、乱码、图片404三大经典问题跨域基本是前后端分离项目的必修课。后端加一个CORS配置几分钟就解决Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowCredentials(true); } }注意allowCredentials(true)和allowedOriginPatterns(*)要配套用如果使用旧版的allowedOrigins(*)配合allowCredentials会直接报错。中文乱码这个坑在Spring Boot 2.x时代基本不存在了重点在数据库。建库时一定写DEFAULT CHARSETutf8mb4表也尽量明确字符集别偷懒。PHP项目则要注意页面文件和数据库连接都是UTF-8一个环节不一致就乱码。图片上传后404是另一个高频坑。根本原因是你把文件保存到了本地磁盘但没有把磁盘路径映射成URL能访问的静态资源。Spring Boot里这样配Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath /); }上传的文件URL就能用/upload/xxx.jpg访问了。如果上传接口返回的地址本身就是全路径那检查一下数据库存的路径字段是否和实际保存路径一致。6.3 并发扣库存别让库存变成负数库存扣成负数这个问题我用一个生活类比一只猫库存是1同时来了10个人下单如果每个人下单前都先查库存再减10个人可能都查到“还有1只”然后10单全成功库存变成-9。这是经典的并发问题。解决方案是“条件更新”把“查库存再减”变成“减库存时检查库存大于0”一条SQL完成UPDATE pet SET stock stock - #{quantity} WHERE id #{petId} AND stock #{quantity}如果更新影响行数为0说明库存不足抛出异常让事务回滚。把这句话写进下单方法里库存负数的问题就杜绝了。对毕设来说用这条SQL已经足够不需要上分布式锁。课堂上讲清楚这个思路老师会觉得你理解了并发的本质。6.4 部署上线的标准动作开发完成后部署到云服务器是很多学校要求的一步。标准动作很简单后端用Maven打成jar包服务器上执行nohup java -jar pet-mall.jar app.log 21 日志重定向到文件方便排查。启动前确保MySQL和Redis在运行防火墙放行8080端口或者用Nginx反代。前端Vue项目npm run build生成dist目录用Nginx托管配置里把/api开头的请求代理到后端服务的8080端口。我实测过的缺点是在本地IDEA里跑得非常顺的应用到服务器上第一个坑往往是数据库连接。因为本地连的是localhost服务器上要改成内网/公网地址或者时区/用户名密码对不上。所以部署前先写一个简单的健康检查接口放到服务器上先curl一下确认数据库通了再启动完整项目能省掉至少半小时的排查时间。7. 毕设文档与答辩准备别让论文拖后腿7.1 文档怎么在开发期间就顺手准备好很多人的毕设论文是最后半个月赶出来的质量可想而知。过来人经验是开发期间顺手把素材攒齐写论文只是把片段连起来。你要攒的素材包括每个功能模块的截图、核心代码片段、测试用例表格、遇到的问题与解决记录。比如每测完一个模块就顺手填一张测试用例表测试模块用例描述预期结果实际结果注册输入已存在用户名提示用户名已存在通过登录输入正确密码返回Token并跳转首页通过商品搜索搜索“猫”展示相关宠物通过下单-正常库存充足下单生成订单、库存减1通过下单-超库存数量大于库存提示库存不足、事务回滚通过模拟支付点击确认支付订单状态变为已付款通过论文里“系统测试”这一章直接拿来用。然后再补几张数据库表结构截图、接口文档截图论文素材就够了。不用边写边截图零散时间就能做完但效果比一个月后临时抱佛脚强得多。7.2 答辩演示怎么演才不会翻车答辩演示有个固定剧本先讲背景和需求再讲技术选型第三步直接登录前台走一遍搜索、加购、下单、支付流程最后打开后台看订单状态和商品管理。这个顺序有讲究主流程走完所有功能模块都被覆盖了听众不会乱。讲的时候记住三句话第一句讲“这里解决什么问题”第二句讲“怎么解决的”第三句讲“为什么这么做”。以下单为例“订单提交涉及多张表写入如果不处理并发库存可能变负数所以我用条件更新的SQL配合事务保证数据一致。”这样讲比背代码流畅而且显得你真的干过。还有一条血的教训演示前一天把电脑重启一次所有服务重新启动确保点击十分钟内不会出环境问题。数据别用测试数据提前准备几只名猫名犬的商品图片和数据视觉效果好答辩观感会直观高一个档次。把这套项目从0做到跑通我自己最大的体会是宠物商城这种“增删改查”系统真正的难度不在写代码而在把流程想清楚、把坑提前踩明白。下单要加事务、库存要条件更新、图片路径要映射、跨域要配置这四件事每件都有人栽过。希望你读完这篇能少翻几次车。最后再啰嗦一句不管选Java、PHP还是Python先把那七个MVP功能完完整整做出来再谈花活。链路通了项目就活了。