SpringBoot+Vue校园商铺系统实战：从架构设计到核心功能开发全解析

1. 项目整体拆解校园商铺系统到底在做什么看到“SpringBootVue校园商铺管理系统”这个标题很多同学第一反应是“又是一个增删改查”说实话这话对了一半。如果只是把几张表的CRUD套上管理后台那确实没什么含金量但一个真正能跑的校园商铺系统背后藏着的是多角色权限控制、订单状态机、库存并发扣减、文件上传、JWT鉴权这一整串在实际业务里绕不开的问题。毕设和课设拿它来练手性价比非常高因为麻雀虽小五脏俱全前端、后端、数据库、部署全链路都能摸一遍。这个项目从业务上说很贴近校园场景学生卖家在平台上开店上架二手书、零食、小商品之类买家浏览商品、加购物车、下单支付管理员负责审核商铺和商品、处理投诉和统计报表。等你把这套逻辑跑通市面上大多数To C商城类项目的核心流程你就都心里有数了。从技术上说它选的是SpringBoot Vue这套国内应用面极广的组合再配上MySQL存数据正好把Java后端的工程化习惯和前端组件的组织方式都练到手。我见过不少同学拿到这个题目后第一句就问“有没有现成的源码”但源码只是答案不是理解。你要真能在答辩时把“为什么用JWT不用Session”“订单状态为什么要用枚举”“库存扣减为什么不能只做判断”这几个问题说清楚那比源代码本身值钱得多。这篇内容就是围绕这些核心问题来拆的既讲清楚系统结构也把关键步骤和容易踩的坑一并梳理出来给做毕设、做课设、或者想拿这个项目练手的同学一条比较顺的路。2. 系统架构与核心模块设计思路2.1 前后端分离的架构选型为什么会以SpringBootVue为主体先聊架构。校园商铺管理系统采用前后端分离不是什么标新立异而是因为这个模式在分工、部署和后期扩展上都有实在的好处。前端用Vue跑在Node环境下通过HTTP请求访问后端接口互相之间只认JSON数据后端用SpringBoot暴露RESTful API不关心页面长什么样只负责处理业务逻辑和读写MySQL。前后端分离之后一个最直观的好处是开发时可以并行推进。做后端的同学专心设计接口把参数和返回结构定清楚做前端的同学可以用模拟数据先渲染页面不用等后端完全写好再动手。对于毕设来说这一点很关键因为它意味着你一个人也能把“两个团队”的活拆开干每一块的进度都可控。SpringBoot在这个项目里承担的角色是“地基加框架”。它的自动配置机制省掉了大量繁琐的XML配置内嵌Tomcat也让打包部署变得很简单一个Jar包扔到服务器上就能跑。Vue这边则负责页面交互和组件复用用Vue Router管理路由用Vuex或Pinia管理全局状态再配合Element UI这类组件库后台管理页面的开发速度会快很多。有一点要提醒前后端分离不等于前后端没有约定。接口路径、参数命名、返回码规范、日期格式这些都需要提前定好。很多项目死在联调阶段原因就是两边各写各的接口一对接就大量返工。我的习惯是先用一个简单的接口文档把“路径、入参、出参、异常返回”四件事定清楚再分头开发这个习惯放到工作中同样受用。2.2 三个核心角色与业务闭环校园商铺系统的角色一般分成三类学生用户、商铺管理员、平台管理员。这三类角色看起来简单但它们的权限边界决定了很多功能的设计方式。学生用户是系统的使用主体。游客可以看到商品列表和商铺信息但要下单、加入购物车、评价商品就必须登录。登录后用户可以维护个人资料管理自己的收货地址查看订单状态还可以提交“成为卖家”的申请等平台审核通过后创建自己的商铺。商铺管理员实际上是已入驻的卖家。他可以在自己的商铺里管理商品分类、上架下架商品、调整库存、处理订单发货。这里有个关键点商铺管理员只能操作属于自己的商铺和商品不能越权看到别人的数据。这意味着所有的数据查询都必须带着商铺归属条件而不能直接查全表再在前端过滤。平台管理员是最高权限负责审核商铺入驻申请、审核商品上架、处理用户投诉以及查看全平台的交易统计和用户数据。他看到的页面和普通用户完全不同这也是前后端分离项目里“按角色渲染不同界面”的典型场景。这三个角色的闭环是这样的学生申请开店→管理员审核→商铺通过→商品上架→学生浏览下单→生成订单→商铺管理员发货→学生确认收货→订单完成。每个环节都涉及一张核心表和若干状态变化把这些变化串联起来整个系统的业务骨架就立住了。2.3 数据库设计商铺、商品、订单、用户四大核心表数据库设计往往是评委老师最喜欢追问的部分。一个校园商铺系统的MySQL表结构至少要覆盖用户、商铺、商品、分类、购物车、订单、订单详情、收货地址、评价、通知这几个维度核心的四张表需要好好设计。用户表是登录和权限的基础字段上除了username、password、phone、email一般还会加上role字段来区分角色。密码不要明文存储要用BCrypt或MD5加盐的方式加密这个点在答辩时很容易被问到也是一个很加分的细节。角色和用户可以直接放在一张表里用字符串区分对于这种规模的系统已经够用不需要单独拆权限表增加复杂度。商铺表要记录商铺名称、简介、头像、所属用户ID和审核状态。审核状态是重点新创建的商铺默认是待审核只有管理员把它变为已通过之后这个商铺才能在用户端被检索到。很多同学做这部分时会忽略“状态驱动可见性”的思路结果商铺一创建就能被所有人看到审核功能就形同虚设了。商品表关联商铺ID和分类ID核心字段包括商品名称、描述、价格、库存、主图、状态。状态一定要用好几个值来区分比如草稿、待审核、已上架、已下架、已删除。商品图建议用URL地址存储图片文件本身上传到服务器或对象存储数据库只存链接这样表结构干净也方便迁移。订单表和订单详情表需要特别注意。订单表保存订单编号、用户ID、商铺ID、总金额、状态、收货信息快照订单详情表保存每个商品的下单数量、单价和快照信息。为什么要有快照因为商品价格和标题可能随时变动而订单一旦生成就必须保留下单那一刻的信息否则用户和商家扯皮时说不清楚。这个设计在电商系统里是标配也是这篇项目里值得好好讲的一个点。2.4 JWT鉴权与接口安全的设计细节校园商铺系统属于多角色系统接口安全一定不能忽视。这里推荐使用JWT做无状态登录认证而不是传统的Session。JWT的工作流程不复杂用户登录成功后后端生成一个包含用户ID、用户名、角色等信息的加密Token返回给前端前端存在本地存储里之后每次请求都在Header里带上这个Token后端通过拦截器或过滤器统一解析Token验证通过后才放行接口访问。这样做的好处是后端不用存储会话状态服务重启后用户也不需要重新登录水平扩展时也无缝衔接。要注意的是生成Token时一定要设置过期时间并在JWT的payload中带上角色信息。这样后端在拦截器里既验证身份又做一次简单的角色判断比如商铺管理员的接口就只允许持有seller角色的Token访问。更细粒度的话可以通过自定义注解加Spring AOP实现权限校验但对这个项目来说拦截器加角色判断已经足够了。另外还有几个安全细节容易被忽略一是登录失败要统一返回错误码不要暴露用户是否存在二是对于文件上传接口要限制文件类型和大小防止恶意上传三是所有写操作都要校验当前登录用户的身份和资源归属防止水平越权。曾经有个同学在毕设里没做归属校验导致只要登录任意账号就能修改别人的商品信息这种问题一旦被老师发现会很扣分。3. 核心功能实现与关键代码复盘3.1 登录认证与前、后端的信息交互流程先看登录认证这条线怎么走。前端有一个登录页用户输入账号密码后点击提交Vue这边调用axios发起POST请求到后端的/api/auth/login接口。后端Controller接收到请求后调用Service层查询用户表比对密码。密码匹配成功就生成JWT并返回给前端失败则统一返回“用户名或密码错误”。前端拿到Token后的处理方式很重要推荐的方案是把Token存储到localStorage然后用axios的请求拦截器在每个请求头里统一加上Authorization字段。响应拦截器也要做统一处理当后端返回401时自动清除本地Token并跳转到登录页。这一步如果没做好就会出现用户登录过期后页面还在正常展示但所有请求都报错体验很差。还有一个实用的细节是登录后获取用户信息。前端在页面刷新时要向后端请求一个类似/api/auth/info的接口根据Token解析出用户ID再拿到用户的基本信息和角色。这个信息会存到全局状态里供各个页面使用。这样无论是判断“这个按钮要不要显示”还是展示“欢迎XX同学”都有统一的数据来源。3.2 商品检索、购物车与下单的完整链路用户端最核心的链路是“找商品→加购物车→下订单”。商品检索一般支持按分类筛选、按关键词搜索、按价格排序。对应后端的接口就是带查询参数的商品列表接口用MyBatis-Plus的QueryWrapper或者写动态SQL都能实现关键是要处理空参数的情况不能让用户不选分类时不传条件就报错。购物车的实现有两种常见做法一种是单独建购物车表用户点击加购就插入一条记录另一种是把购物车数据放在前端本地存储下单时才传给后端。这里我比较推荐用数据库表方式因为学生在宿舍换电脑、换浏览器登录时购物车数据还在体验一致。购物车表的核心字段是用户ID、商品ID、数量加车时要校验商品是否上架、库存是否足够避免加一个根本买不了的商品进去。下单流程是业务的重头戏。用户从购物车勾选商品后点击结算前端把商品ID和数量列表传给后端后端要做几件事先查询商品当前状态和价格计算总金额再判断库存是否充足充足则扣减库存然后生成订单主记录和订单详情记录最后清空对应的购物车记录。这里“先查再扣”的操作在高并发下有并发风险但对毕设项目而言保证逻辑完整、状态一致配合数据库事务就已经达到要求了。事务在这里是必须的。为什么因为“扣库存”和“生成订单”中间一旦任何一步失败都不能出现库存扣了但订单没生成或者订单生成了但库存没扣的现象。所以Service层的方法上要加Transactional注解由Spring帮你管理事务回滚。这个细节在答辩时几乎是必问的你得能讲清楚“事务保证的是多个操作要么全部成功要么全部失败”这个道理。3.3 订单状态机的设计从待付款到已完成订单状态是这个系统里最容易写乱的部分。很多同学喜欢在代码里直接用数字表示订单状态然后到处写if (status 1)过几天再看已经分不清1到底是待付款还是待发货。建议用状态枚举来管理。订单至少要有待付款、已付款待发货、已发货、已完成、已取消这几种状态。每一种状态对应一组允许的操作比如只有待付款状态可以执行支付只有已付款状态可以执行发货只有已发货状态可以执行确认收货。这个状态之间的流转要设计清晰不能让用户从已取消的订单再去点支付那就会闹笑话了。实现上有两种思路。简单粗暴的方案是在Service层写状态判断如果当前状态不匹配则抛出异常。更好的方案是定义一个订单状态变更的处理器接口每种状态变化对应一个实现类用策略模式管理起来。后者代码量会多一些但对状态边界的管理非常清晰后续加“退款”之类的状态时只需要新增一个处理器不用改动原有逻辑。状态机的设计还有一个好处就是前端页面展示起来非常省事。订单列表直接读取后端计算好的状态文本比如“待付款”“待发货”“已完成”不用在前端维护一套状态到文字的映射关系。如果业务复杂还可以增加状态变化历史表记录每次状态变更的时间、操作人和变更前后的值用于用户和商家的纠纷追溯。3.4 管理后台审核、统计与数据看板管理后台是平台管理员的主要阵地页面布局一般用侧边栏加顶栏的结构能看到的模块包括用户管理、商铺审核、商品审核、订单概览、投诉处理、数据统计。商铺审核是最典型的“状态审批流”功能。管理员打开待审核列表查看商铺信息和资质点击通过或驳回。通过后商铺状态变为已通过用户端立即可见驳回时需要填写理由同时系统要通知申请的学生。这个流程虽然不复杂但非常考验前后端配合。前端要能展示待办数量和状态标签后端要提供不同状态下的列表查询和状态更新接口。数据统计模块可以直接用MySQL的聚合函数完成比如查询某天的订单数、销售额、新增用户数。需要重点注意的是日期参数的处理前端传的是字符串后端要正确解析成日期范围如果用MyBatis写原生SQL要注意时间边界别把当天零点或次日零点算重了。图表方面Vue侧可以用ECharts柱状图、折线图、饼图各来一个整个管理后台的完整度立刻上一个档次。3.5 文件上传与图片存储方案商品的图片上传几乎是每个商城系统都绕不开的功能。常见的做法是后端提供一个上传接口接收前端传过来的MultipartFile然后把文件保存到服务器的指定目录最后把访问URL返回给前端前端再把URL作为商品图片字段的值提交给后端保存。实现时有几个要点需要留意。第一上传目录最好是配置在application.yml里单独的绝对路径不要硬编码在代码里这样部署到不同服务器时只需要改配置就行。第二要校验文件的扩展名和大小比如只允许jpg、png、jpeg大小不超过5MB通过就保存不通过就返回上传失败的提示。第三图片访问要配置静态资源映射SpringBoot中重写WebMvcConfigurer的addResourceHandlers方法把虚拟路径/images/**映射到真实存储目录。这一步如果漏了前端能上传成功但是图永远显示不出来。对于毕设项目用本地文件存储是完全够用的。等以后想升级再把存储层替换成对象存储服务其实也只是换了上传接口的实现逻辑前端调用方式不需要变动这也算是“面向接口设计”带来的好处。4. 从零到一实操环境准备、数据库初始化与项目启动4.1 开发环境与工具版本组合建议动手之前先把环境理清楚能省掉后面一堆莫名其妙的坑。这块我用的是比较稳定而且社区教程多的组合软件建议版本作用JDK1.8或11运行SpringBoot后端Maven3.6以上依赖管理与构建MySQL5.7或8.0数据存储Node.js14以上运行Vue开发环境IDEA最新版即可开发工具Vue CLI4.x或5.x初始化前端工程Element UI2.15管理端UI组件这个组合的好处是每个环节都有大量现成教程可查遇到问题时按版本号搜索基本都能找到答案。如果你用的JDK版本和新版SpringBoot不匹配启动时可能会碰到“Unsupported class file major version”之类的报错解决方法是把JDK版本降到项目要求的版本或者升级SpringBoot版本。4.2 数据库初始化脚本的关键要点项目拿到手后第一步就是建库和初始化表。执行sql脚本之前建议用Navicat或MySQL命令行先建一个名为campus_shop的数据库再运行脚本。脚本里除了建表语句一般还应该包含基础数据比如分类数据、一个管理员账号、一个测试学生账号这些直接INSERT进去能让你跳过注册环节快速看到效果。查看脚本时重点看四类约束主键、外键、唯一约束和默认值。主键一般用自增ID外键用于保证引用完整性比如订单详情表的商品ID必须存在于商品表唯一约束常用于用户名、手机号等字段默认值用于创建时间、状态之类的字段减少代码里重复赋值。导入数据时如果报错提示主键冲突或者字段不存在多半是脚本和你选的MySQL版本有兼容问题。比如MySQL 8.0默认使用utf8mb4字符集如果脚本里有旧的utf8设置一般也能兼容。只要sql整体没问题执行顺序按脚本内注释走即可。初始化完成后建议先用SQL查一下测试数据是否正确。比如SELECT * FROM user看管理员是否存在SELECT * FROM shop看是否有待审核的商铺都正常就说明数据库这关过了。4.3 后端配置修改与启动排查后端启动最常出问题的就是配置文件。把application.yml打开重点看数据源、JWT和文件上传这几块的配置。数据源要改成你本机的MySQL地址、端口、库名、用户名和密码有些项目还会用到Redis做缓存如果你的环境没装Redis最简单的办法是把相关配置去掉并改用本地存储等后续想扩展再加回来否则服务一直连不上Redis就会频繁报错。修改完配置后用IDEA直接运行主类。如果启动失败控制台会打印异常堆栈大部分情况下都是以下三种数据库连不上看URL和账号密码、端口被占用8080被占了改端口或杀进程、依赖没有下载完重新reload Maven项目。后端成功启动的标志是控制台出现“Started xxxApplication in xx seconds”以及SpringBoot的日志输出同时访问http://localhost:8080/api/health之类的测试接口能返回结果说明服务已经可用了。这时可以先不用管前端用Postman或者浏览器直接调几个公开接口确认后端独立工作正常。4.4 前端安装依赖与跨域联调后端跑起来之后把前端项目用IDEA或VSCode打开在终端执行npm install安装依赖。这一步网络不好时容易卡住建议用国内镜像源也就是配置registry地址为https://registry.npmmirror.com。依赖装完后执行npm run serveVue项目默认跑在http://localhost:8081如果8080被后端占了的话。到这一步就该处理跨域问题了因为前端在8081后端在8080浏览器出于同源策略会拦截跨域请求。解决跨域的常规办法是后端添加一个CORS配置类允许指定的前端来源访问接口并放行GET、POST、PUT、DELETE等请求方法和自定义Header。SpringBoot实现起来也就是写一个添加CorsFilter的配置类代码量不大但确实是前后端联调最关键的一环。跨域解决后打开浏览器访问前端地址先试一下登录接口点击登录后看Network面板确认请求正常发出并且拿到200响应。能看到订单数据、商品数据在页面上正常渲染说明整体通道已经打通接下来就是按功能模块逐个验证和debug了。5. 常见问题与避坑经验整理5.1 不同角色权限混乱接口怎么守住边界很多校园商铺系统最明显的Bug就是权限控制不严格。比如普通学生直接调用后端接口就能把某个商铺的商品下架这是因为后端接口没有做角色判断。解决思路是把校验做成统一拦截器加注解的方式。自定义一个RequireRole注解标在需要权限的Controller方法上然后实现一个AOP切面在方法执行前解析当前用户的角色和请求参数中的资源归属。角色不匹配直接抛异常资源归属不匹配也一样拒绝。有同学问过那前端把按钮藏起来不就行了吗不行。前端隐藏按钮只是体验上的处理真正的安全边界必须放在后端因为接口是可以被直接调用的。期末答辩时如果能主动讲清楚“前端控制展示后端控制权限”老师印象分会加不少。5.2 订单超时未支付如何处理订单状态订单超时未支付是一个在实际项目中一定会遇到的需求但不少毕设项目选择了忽略。这类需求在答辩时容易被追问建议至少给出两种处理方案。方案一定时扫描。后端通过Spring的Scheduled定时任务每隔一段时间扫描订单表把超过一定时间仍未支付的订单自动变成已取消并回补库存。实现简单可接受一定程度的延迟。方案二延迟消息。用消息中间件或本地的延迟队列在订单生成时发送一条延迟消息消息到期后检查订单是否已支付未支付则取消。这个方案实时性更好但实现复杂度高一些适合有Redis或MQ基础的同学作为加分项去讲。两种方案的核心点都是同一个取消订单的同时要回补库存否则会出现库存被未支付订单占着用户却不能购买的尴尬情况。5.3 前端打包后接口报404部署时要改什么开发环境下一切正常部署上线后白屏或接口报错这个坑几乎人人都会踩。根因是前端打包后的静态资源文件和路由模式的问题。Vue项目默认使用history路由模式这种模式下刷新一个子路由页面时服务器会按照实际路径去找文件找不到就返回404。解决办法有两个一是把路由模式改成hash模式路径里会带#号刷新不会请求服务器二是在Nginx配置中添加try_files指令让所有路径都回退到index.html。另外打包后的前端页面请求的接口地址也要改。开发时写的是http://localhost:8080/api部署后就要改成服务器的实际地址。这个地址建议配置在环境变量文件里npm run build时注入不要写死在代码里。我曾经见过一个人把地址直接写在axios实例中换环境就要改代码重新打包非常痛苦。5.4 数据库连接池和时区报错的常见处理MySQL 8.0连接时经常报The server time zone value is unrecognized或者中文乱码问题。解决办法是JDBC连接串上加参数设置时区为Asia/Shanghai或serverTimezoneCTT同时指定characterEncodingutf8和useSSLfalse参数。这些参数加上后数据库连接和中文存储的问题基本都能解决。如果后端运行一段时间后出现连接超时或连接池耗尽可能是连接池的最大连接数配置过小或者代码里连接没有正常释放。SpringBoot默认的HikariCP连接池只要数据源配置正确一般不会出问题可以先调大maximum-pool-size观察情况同时检查一下自己写的JDBC原生代码是否用了try-with-resources正确关闭连接。5.5 常见问题速查表遇到报错时先别慌多数问题都可以归到固定的几类。我把项目里最高频的问题整理成一个速查表排查时可以对号入座报错或现象可能原因解决办法启动时数据库连接失败URL、账号、密码错误或库没建检查application.yml数据源配置前端请求接口404跨域未配置或接口路径不对后端加CORS配置比对接口文档路径登录成功后刷新页面又回到登录页Token未保存或路由守卫判断失败检查Axios拦截器和路由守卫逻辑上传图片显示不出来静态资源映射未配置或路径前缀不对配置资源映射核对访问URL订单支付后状态不变回调接口没写或状态更新逻辑没触发检查支付流程中状态更新的调用列表数据重复或漏数据SQL分页语句或查询条件错误检查分页参数和动态SQL拼接修改密码后反而登录不了密码加密逻辑不一致统一使用同一加密方式注册和登录这张表基本覆盖了从开发到部署最常见的卡点遇到问题时按表排查能省下大量时间。6. 适合哪些场景以及怎么把它做得更有含金量6.1 毕设、课设、自学三种场景的侧重点不同毕设场景下重点不在功能多不多而在技术展示是否成体系。如果你的选题是“校园商铺管理系统”那关键要突出工程化能力前后端分离、JWT鉴权、统一异常管理、事务控制、项目结构分层。这些是评审老师眼里体现“你会做项目”的证据而不是看你会不会堆砌页面。课设场景通常时间紧这时要优先保证核心链路跑通用户注册登录、商品展示、购物车、下单、后台管理。把这条链路做流畅再加上几个亮眼的页面和简单的统计图表就已经能拿到不错的成绩。不要贪多状态机、定时任务这些可以作为加分项但核心链路的稳定性永远是第一位的。自学场景则要主动加码。用这个项目练手时建议不满足于“能跑”而是思考几个进阶问题高并发下如何防止库存超卖、订单状态变化如何做成事件驱动、商品搜索怎样接入全文检索、文件存储怎样换到对象存储。哪怕只是把思路写成文档学习效果也比只看源码好得多。6.2 怎样在答辩和面试中讲这个项目不管是答辩还是面试讲项目都要遵守一个原则先讲业务和架构再讲自己遇到的坑和解决思路。很多人一上来就念技术名词SpringBoot、Vue、MySQL报了一堆但是完全没解释这些技术在这个系统里解决什么问题这是最容易减分的讲法。建议你准备一个这样结构的介绍第一句说清“这个系统是一个面向校园场景的C2C商城平台核心用户有三种角色”然后说“技术上选了前后端分离前端Vue负责交互后端SpringBoot暴露REST API用MySQL做持久化”再往下挑两三个“我遇到的难点”来讲比如“订单状态机如何设计避免非法状态流转”“库存扣减如何用事务保证一致性”“JWT登录后如何做权限校验”。面试官听到这里基本就判断出你是真做了项目而不是只会背概念。再多说一句源码可以下载项目也可以复现但答辩时是没法照着念的。把每个核心模块“为什么这么设计、怎么实现、遇到什么问题”想明白这个项目才算真正属于你自己。6.3 系统后续可以怎么扩展校园商铺系统扩展空间非常大。基础款如果想加分可以加支付模拟功能不用接真实支付只要模拟支付回调并正确更新订单状态就是一个让人眼前一亮的功能。再往后可以加消息通知下单成功给商家发通知、订单发货给用户发通知、审核结果给学生发通知用WebSocket做站内信技术含量和体验完整度都会立刻提升。数据层面可以把统计报表做成定时任务每天汇总前一天的数据写入统计表这样管理后台看大屏图表时性能会好很多。用户体系上可以接入邮箱验证或者短信验证码增加找回密码功能。这些扩展不是说必须做而是让你知道这个项目不像表面看起来那么简单它背后有一整条可以深挖的技术线。7. 最后分享一点项目心得这个项目我前后接触过不少案例也和用过这套系统的同学聊过。个人最大的感受是校园商铺系统是一道“看似简单实则很考验工程基本功”的题目。如果只是搭个页面、建几张表、写几个接口一天就能糊完但如果你想把它做成一个经得起追问、能拿得出手的项目那些边界情况、状态控制、权限校验、事务一致性每一个都值得多花两小时去搞清楚。给正在做这个项目的同学一个建议不要只在本地跑通就算完尝试着把后端打成Jar包、前端执行打包、部署到一台服务器上用Nginx反向代理全程自己亲手做一遍。你会在部署过程中遇到编码问题、路径问题、端口问题、进程管理问题每解决一个你对整个系统的理解就加深一层。最后分享一个小技巧数据库里一定要多准备几种状态的测试数据。比如有刚创建的待审核商铺、有订单卡在待发货、有用户已经取消订单。这样你在联调和管理后台时每个状态下的页面渲染都能直接验证到不会出现“功能写好了但从来没看到对应界面”的情况。测试数据准备得越充分开发和答辩时越从容。