1. 项目全貌先想清楚家具商城小程序到底要装下什么微信小程序家具商城系统这几年几乎成了计算机专业毕业设计里的“常青树”。十个选小程序的同学里至少有三四个会挑商城方向而家具商城又比普通的数码、服饰商城更贴近实体行业功能上既有通用电商的购物车、订单、支付又带着大件商品的特殊性比如多规格参数、运费策略、预约咨询。正因如此一套能跑通、能讲明白、能写进论文里的家具商城天然就是一份不错的中级难度题目。但我也见过很多拿到类似标题和源代码的同学步骤卡得五花八门有人连项目都导不进微信开发者工具有人登录成功后拿不到用户信息有人把商品列表做成了“一次性加载全部”导致小程序性能分拉低还有人被答辩老师追问“库存怎么扣”“订单状态怎么流转”时支支吾吾。问题基本不在功能多复杂而是对整套系统的“为什么”没搞清楚。这篇文章的价值就是帮你把一条完整的链路理顺从功能需求怎么拆、技术选型怎么定到数据库表怎么设计、核心代码怎么写再到论文、PPT、演示视频怎么准备。内容完全可以对应到你手里的这一套“微信小程序家具商城系统毕业论文PPT附源代码演示视频”上去把它变成真正属于你自己的、能站得住脚的作品。1.1 用户端不是放几个页面就算完先看小程序端也就是用户能看到的那部分。一个合格的家具商城至少要覆盖下面这些模块首页轮播图、金刚区入口、热销推荐、新品上架、家具风格分类入口。首页是整个小程序的门面也是答辩时老师最先看到的地方做得干净、流畅印象分直接拉满。分类页按客厅、卧室、餐厅、书房、定制家具等维度分类支持二级分类和分类右侧的商品列表。搜索用户输入关键词搜索商品名称、风格、材质支持分页展示结果。商品详情页大图轮播、价格、SKU选择颜色、材质、尺寸、库存展示、收藏、加入购物车、立即购买、商品详情图文。购物车商品列表、数量加减、单选/全选、合计金额、删除商品、去结算。结算页收货地址选择、运费计算、订单备注、优惠信息展示。订单中心待付款、待发货、待收货、已完成、售后/退款以及订单详情页。个人中心微信登录后的用户信息、我的收藏、收货地址管理、设置。一个容易忽略的点是家具商城的“行业气质”。家具是大件、低频、高客单价的品类用户在详情页里需要看得足够仔细才会下单。所以商品详情页一定要有多角度大图、材质说明、尺寸参数和风格标签。很多同学随便找几十张图塞上去就完事这到了答辩现场很容易被问“你的商品信息模型是怎么设计的”。1.2 管理端缺少管理端的商城只能算半个系统很多论文里的家具商城只做了小程序端这是不完整的。完整系统必须有一个后台管理界面哪怕是最精简的版本也要能管理商品和订单。管理端一般放在 PC 端或 H5 后台核心功能包括商品管理添加商品、编辑商品、上下架、设置价格与库存、管理商品图片。分类管理维护分类树调整排序。订单管理查看订单列表、确认发货、标记物流单号、处理取消订单。数据概览今日订单数、成交量、新增用户等基础统计。我建议管理端即使写得简陋也一定要做。原因很直接论文里需要用例图和模块图如果只有用户端系统边界显得太窄。答辩时老师问“商家怎么管理商品”你总不能说“用数据库直接改”这一句话就能把分数拉低。有一个能跑起来的管理后台哪怕只是网页版的商品和订单管理整个系统的完整度就完全不同。1.3 功能优先级毕业设计最怕的不是少而是乱选功能时有的同学恨不得把优惠券、秒杀、直播、积分全塞进去结果代码堆成山论文里却讲不清楚。正确的思路是分优先级来做P0 必须做微信登录、商品浏览、商品详情、SKU选择、购物车、下单、支付流程模拟、订单管理、后台商品与订单管理。P1 推荐做收藏、地址管理、搜索、分类、列表分页加载、订单状态流转。P2 能做就做优惠券、新品推荐、浏览历史、预约到店、物流信息查询。这套优先级基本对应答辩评分点功能完整度、数据一致性、业务逻辑闭环。P0 保证“闭环”P1 保证“体验”P2 则是你论文里的“创新点”。我个人的习惯是先闭环再扩展哪怕后期时间不够砍掉的也只是加分项核心系统站得住。2. 技术选型与核心原理每一个“为什么”都要能答上来技术选型这块是答辩老师最爱深挖的区域。你的论文里写了“采用微信小程序Spring BootMySQL”那就得能解释清楚为什么小程序用原生而不是 uni-app为什么后端选 Spring Boot 而不是 Node 或云开发前端和后端之间数据是怎么流转的。2.1 前端选型原生微信小程序还是 uni-app原生微信小程序指的是直接用微信开发者工具写 WXML、WXSS、JS、JSON。它的好处是零额外依赖启动快调试工具成熟对小程序生命周期和 API 的理解最透彻。uni-app 则是使用 Vue 语法开发一套代码同时编译到微信小程序、H5、App 等平台适合有 Vue 基础并且以后想多端复用的同学。如果只看“家具商城”这个题目我更推荐原生小程序。原因很实际第一原生小程序的控制台、真机调试、体验版生成都最直接遇到报错能快速定位第二论文里写“基于微信小程序原生开发”比“基于 uni-app”更容易展开原理细节比如页面生命周期、组件通讯、setData 机制这些原生概念答辩时讲起来扎实。当然如果你简历上主要写 Vue选 uni-app 也不是不行但要额外学会“小程序端的 uni-app 打包”流程避免答辩时连编译产物都说不清楚。2.2 后端选型自建后端与小程序云开发的取舍家具商城需要一个后端来管理用户、商品、订单数据。目前常见做法有两类自建后端和小程序云开发。自建后端通常用 Spring Boot、Node.jsExpress/Koa或 ThinkPHP数据库用 MySQL通过 HTTP 接口和小程序通信。优点是完全可控网络请求、鉴权逻辑、数据表设计都由自己写论文里的“系统设计”“接口设计”章节写得最丰满。缺点是部署麻烦一点需要一台服务器或本地环境。小程序云开发则是腾讯提供的后端服务数据库、云函数、存储一体化在小程序里可以直接调用云函数操作数据库。它的最大优点是省去服务器运维登录也简单云开发自带 openid 获取适合时间紧张、主要想聚焦前端展示的同学。我的建议是如果你论文篇幅要求不高、时间在 3 周以内可以选云开发快速把功能跑通如果想把论文写得厚实、而且被问到“项目怎么部署”“数据库在哪里”时不心虚还是老老实实自建后端。测评下来自建后端 小程序的组合虽然前两三天辛苦些但后期扩展功能、调试并发问题都要顺手得多。很多网上下到的“家具商城系统源代码”用的都是自建后端加 MySQL你接手时反而更好还原环境。2.3 数据流转链路从微信登录到支付回调一条线讲明白后端方案定了之后最重要的就是理解小程序的数据是怎么“绕”一圈回到界面的。微信登录是最典型的例子小程序端调用 wx.login()拿到临时凭证 code。小程序把 code 发给自己的后端服务器。后端拿 code appid appsecret 请求微信的 jscode2session 接口换取 openid 和 session_key。后端用 openid 查数据库判断是老用户还是新用户生成自定义登录态一般是 token返回给小程序。小程序把 token 存到 storage之后所有业务接口都带上 token后端解析 token 就知道是哪个用户。这里有一个必须先讲明白的安全原则后端账户体系一定要自己做。前端可能只用了 openid千万别把 appsecret 暴露给前端也千万别在小程序里直接调用 jscode2session。所有敏感信息都在后端完成前端拿到的只是后端下发的登录凭证。这一个点你能自己讲清楚答辩老师基本就不会再纠结你的登录实现了。数据流链路的另一头是“浏览商品到提交订单”。用户在首页或分类页看到商品列表点进详情页选择了颜色和尺寸后加入购物车。购物车数据可以只存在本地也可以用后端存储。提交订单时前端把商品 SKU、数量、地址、备注组装好发给后端后端先校验库存生成订单记录再返回订单号。订单状态从“待付款”开始流转支付成功后变为“已付款”商家发货变为“已发货”用户确认收货后变为“已完成”。这一条链路的每一步论文里的时序图或流程图都要能画出来。3. 数据库设计与核心功能实现家具商城的难点不在“有”而在“稳”商城类项目的代码量其实不大真正的难度核心在数据。商品、SKU、库存、订单之间的关系没理顺代码写再多也会在联调时崩给你看。本节我会把一张表一张表过一遍并把几个高频功能点背后的实现细节讲透。3.1 核心表结构商品、SKU、订单怎么建模一个完整的家具商城表至少包括这几张user用户表。字段有 id、openid、nickname、avatar、phone、create_time。openid 要加唯一索引。category分类表。字段有 id、parent_id、name、sort_order。支持二级分类所以 parent_id 是关键。product商品表。字段有 id、category_id、name、sub_title、main_image、detail、price、stock、sales、status、create_time。这里的 price 建议使用“分”为单位存储避免浮点精度问题。product_skuSKU 表。字段有 id、product_id、color、material、size、price、stock、sku_code。一件商品可以有多个 SKU每个 SKU 有自己的价格和库存。cart购物车表。字段有 id、user_id、product_id、sku_id、quantity、checked、create_time、update_time。address地址表。字段有 id、user_id、name、phone、province、city、district、detail、is_default。orders订单主表。字段有 id、order_no、user_id、total_amount、pay_amount、freight_amount、status、address_snapshot、remark、pay_time、create_time。order_item订单商品表。字段有 id、order_id、product_id、sku_id、product_name、product_image、price、quantity。banner轮播图表。字段有 id、image_url、link_type、link_value、sort_order、status。这里重点讲一下地址快照字段。订单生成时用户填入的地址必须单独存一份到 orders 表的 address_snapshot 字段而不是通过 user_id 去实时查 address 表。原因是用户以后可能修改地址而历史订单必须保存下单那一刻的收货信息。很多同学不做这个快照被追问“用户改了地址以前订单怎么办”时就会卡壳。3.2 商品列表“加载更多”分页不是 page 加一那么简单微信小程序里商品列表页最常见的效果是上滑加载更多也就是热搜词里提到的“微信小程序页面列表加载更多”。这一步看着简单实际细节不少小程序页面里配置 onReachBottom 生命周期触发“加载下一页”逻辑。页面 data 中维护 page、pageSize、hasMore、loading 四个状态。请求接口时先判断 hasMore 和 loading防止重复请求。接口返回 total 和 list前端计算是否有更多page * pageSize total。加载完成后 setData 把新数据追加到旧数据之后注意用数组展开而不是覆盖。网络错误或加载失败时要给用户一个“重新加载”的入口。这段逻辑我用一个示例说明。假定接口 /product/list 接受参数 page、pageSize、categoryId、keywordPage({ data: { productList: [], page: 1, pageSize: 10, hasMore: true, loading: false }, onReachBottom() { if (!this.data.hasMore || this.data.loading) return; this.loadProducts(); }, loadProducts() { this.setData({ loading: true }); wx.request({ url: https://your-api.com/api/product/list, data: { page: this.data.page, pageSize: this.data.pageSize }, success: (res) { const list res.data.data.list; const total res.data.data.total; this.setData({ productList: this.data.productList.concat(list), page: this.data.page 1, hasMore: this.data.productList.length list.length total, loading: false }); }, fail: () { this.setData({ loading: false }); wx.showToast({ title: 加载失败请重试, icon: none }); } }); } });注意一个很容易踩的坑setData 里如果直接写this.data.productList.push(...)再 setData小程序在某些版本下不会触发视图更新正确做法是先在局部构建新数组再赋值。另一个坑是 pageSize 如果设得太大比如 50首页白屏时间会明显变长家具商品图片多建议 8~12 条一页更稳。3.3 购物车与服务端状态为什么不能只在本地存很多初学同学做购物车直接用 storage 在本地存一个数组商品加购、数量加减都只操作本地。这个做法在小规模演示里确实能跑但有两个问题一是换设备或清缓存购物车就没了二是后端订单逻辑里校验不到购物车数据订单和购物车变成两条独立链路。更规范的方案是购物车数据也保存在后端。加购时前端把 productId、skuId、quantity 发给后端后端判断商品是否存在、库存是否充足、同一用户同一 SKU 是否已存在存在就加数量不存在就新增。购物车列表页从后端接口拉取并回显选中状态。订单状态机是另一个重点。订单表里的 status 字段建议用整数枚举方便代码里做状态判断和状态流转控制。推荐的状态定义如下0待付款1已付款/待发货2已发货/待收货3已完成4已取消5退款/售后中当用户提交订单时后端要做的核心校验有三步参数校验、价格重算、库存校验。价格重算的意思是前端传来的金额不能直接信后端要再次从数据库读取商品价格乘以数量加上运费得到最终应付金额。这步不做就等于你把定价权交给了用户属于电商系统里绝对不能被原谅的安全漏洞。库存扣减策略也建议在论文里写明。常见的两种是“下单减库存”和“支付减库存”。下单减库存的好处是占住库存避免超卖但用户不支付会占用库存支付减库存的好处是减少无效占用但高并发下可能出现“支付成功后发现库存不够”的问题。毕设规模下选“下单时校验库存并预占支付不成功或超时自动释放”就足够了和主流电商平台的思路是一致的。3.4 顶部导航栏高度与自定义导航栏适配其实有个固定公式热搜词里有“微信小程序顶部导航栏高度”这几乎是每个做小程序的人都会遇到的页面适配题。如果你不想让小程序顶部的大标题像默认导航栏一样死板而是希望首页放一张延伸到头部的轮播图那就必须自定义导航栏。自定义导航栏的第一步是在对应页面的 json 文件里配置{ navigationStyle: custom }然后代码里计算导航栏高度。这里有个固定公式顶部安全区高度 胶囊按钮高度 上下留白通常这样算const systemInfo wx.getSystemInfoSync(); const menuButton wx.getMenuButtonBoundingClientRect(); const statusBarHeight systemInfo.statusBarHeight; const navBarHeight (menuButton.top - statusBarHeight) * 2 menuButton.height;这段代码的含义是先拿到状态栏高度再拿到右上角胶囊按钮的位置和尺寸胶囊按钮顶部到状态栏底部的距离大约是上下留白乘 2 表示上下各留一份再加上胶囊本身高度就是自定义导航栏的总高度。很多初学者直接用固定值 44px遇到不同机型就会错位。把这段适配逻辑写进你的工具函数里答辩演示时用不同机型对比展示本身就是一个小亮点。4. 源代码工程结构与二次开发实战拿到一套源码后如何让它变成你的网上能下载到的“基于微信小程序的家具商城系统源代码”质量参差不齐。有的源码目录混乱注释几乎没有数据库脚本还是旧的有的接口域名写死成别人服务器你改了前端也没法跑。这节我会教你如何整理源码、如何替换成自己的环境以及如何在此基础上扩展功能。4.1 一份“答辩不丢人”的源码应该长什么样拿到或写出一份源码后第一步是检查目录结构。一个规范的小程序前端工程至少应该包括miniprogram/ ├── app.js // 小程序入口逻辑全局变量与登录态初始化 ├── app.json // 全局配置页面路径、tabBar、窗口样式 ├── app.wxss // 全局公共样式 ├── pages/ │ ├── index/ // 首页 │ ├── category/ // 分类页 │ ├── product/ // 商品详情页 │ ├── cart/ // 购物车 │ ├── checkout/ // 结算页 │ ├── order/ // 订单列表 │ ├── user/ // 个人中心 │ └── address/ // 地址管理 ├── components/ // 自定义组件如商品卡片、数量步进器、SKU弹层 ├── utils/ │ ├── request.js // 封装 wx.request统一处理 token 和错误码 │ ├── auth.js // 登录态管理token 存取与刷新 │ └── format.js // 金额、时间的格式化工具 ├── api/ // 按模块拆分的接口地址和请求方法 └── images/ // 本地静态图片资源除此之外项目中还应该有服务端源码目录、数据库初始化脚本.sql 文件、README 说明文档。README 至少要写清楚环境要求、启动步骤、默认账号密码、接口文档入口。如果你的作品包里缺少这些建议自己补上因为演示视频和答辩现场都可能需要现场还原环境。4.2 四个步骤把别人的源码替换成自己的项目很多同学第一步就卡在“改了代码但小程序里都是空白”上。这里有一套标准的替换流程修改 appid在微信开发者工具里打开项目把 appid 换成你自己的小程序 appid或者用测试号。如果不改部分接口和预览功能会受限。配置合法域名在小程序后台“开发管理 - 开发设置 - 服务器域名”里把后端接口域名加到 request 合法域名中。开发调试阶段可以暂时勾选开发者工具的“不校验合法域名”选项但演示时记得关掉。初始化数据库把项目自带的 .sql 文件导入 MySQL创建数据库和账号并修改后端配置里的数据库连接信息。替换图片资源把项目里的占位图片全部替换成自己的图片文件。注意别用微信后台图片压缩太狠的图模糊的商品图在详情页非常影响观感。替换完成后先在开发者工具里跑通“首页加载 - 商品详情 - 加购 - 下单”这条主链路再去翻其他页面。不要一次性改完所有页面再统一调试报错时很难定位是环境问题还是代码问题。4.3 二次开发给家具商城加一个能说出亮点的功能源码拿到手后直接原样交出去很容易被认定是“网上找的”。聪明做法是加一个自己能讲清楚的小功能让它变成你真正掌握的增量功能。以家具商城为例我给你两个低成本高收益的方向第一个是“预约到店”。这是家具品类的特色需求实现难度不高在详情页或个人中心加一个“预约到店”入口调用 wx.chooseLocation 选择门店地址填写预约时间和联系方式提交后生成一条预约记录。后端加一张 appointment 表管理端能看到预约列表。这个功能在论文章节里可以写成一节“面向家具行业的本地化服务功能”天然贴合题意。第二个是“订单超时自动取消”。下单但不支付会占用库存可以加一个定时任务或消息队列延迟处理。比如订单超过 30 分钟未支付自动把状态改成“已取消”并释放对应 SKU 的库存。如果后端用 Spring Boot可以用 Scheduled 做定时扫描使用云开发则可以用定时触发器。这个功能能引出“库存释放”“定时任务设计”“状态一致性”等话题答辩时非常好讲。做二次开发时注意别贪多。一个到两个功能足够核心是把改动点记录清楚论文里对应画出流程图和测试用例。5. 高频问题与排查技巧实录那些每次都有人踩的坑下面这张速查表是我结合大量同学做相似项目时踩过的坑整理出来的。建议收藏调试时对照着排查。问题现象可能原因解决思路首页白屏接口报 request 合法域名出错未配置合法域名或开发者工具未关闭校验开发时勾选“不校验合法域名”发布前在后台配置域名登录后发现小程序里没有用户昵称头像基础库版本低或未做用户信息授权新规范用 button 的 open-typechooseAvatar 获取头像昵称通过 input 输入onReachBottom 不触发页面没有足够滚动高度或滚动容器不是页面本身检查是否使用了 scroll-viewonReachBottom 只对页面滚动生效商品列表翻页后出现重复数据没有区分“刷新”和“加载更多”或 page 未重置下拉刷新时重置 page1 并清空列表再发起请求自定义导航栏在部分机型偏移使用了固定高度而非动态计算用 getMenuButtonBoundingClientRect statusBarHeight 计算导航栏高度购物车商品数量改了但总价没变选中状态或金额计算未监听数量变化每次 setData 数量后重新计算选中商品总价微信支付无法调起个人主体小程序不支持微信支付或未申请支付商户号毕设可用模拟支付在项目中标记“模拟支付完成”真机预览时图片加载慢图片没有压缩或未使用 CDN图片改 WebP/缩略图列表用懒加载 lazy-load表格之外还有三个值得展开讲的重点排查场景。第一个是登录态失效。微信的 code 是临时凭证只能用一次而且有效期短。你必须在后端完成 code 换 openid 后立刻生成自己系统的 token 返回。小程序端在 request.js 里统一在 header 带上 Authorization 字段后端每次校验。遇到“请求返回 401”时先看 token 是否过期再检查后端鉴权拦截器是否漏放行了登录接口。第二个是“小程序怎么发给其他人试用”。这是开发中最常见也最容易懵的需求。正确操作是在微信开发者工具里点击“上传”把代码上传到小程序后台作为开发版本然后在后台“版本管理”里把该版本设为“体验版”并添加至少一位体验成员体验成员在小程序里搜索你小程序的名字或者扫体验版二维码就能打开试用。如果你只是想临时给朋友看几眼也可以直接点开发者工具的“预览”生成一个有效期为几分钟的二维码。记住未发布的小程序普通用户是搜不到的。第三个是监听用户离开小程序。小程序的生命周期中onHide 代表小程序被切到后台比如用户按 Home 键、接电话onUnload 代表页面被关闭。如果要统计数据比如用户停留在某个页面多久需要组合使用 onShow 和 onHide 记录时间戳。有的同学想“用户一离开就自动提交订单”这种做法在需求上就不合理答辩时如果被问到“为什么不做”要能从用户体验角度解释清楚。另外开发调试期间我建议把后端返回的每一步数据都打点记录。最基础的是用 console.log 打印接口返回进阶一点在开发者工具 Network 面板里查看请求耗时、请求头和响应体。如果此时你还需要观察本地联调的完整协议细节可以用 Charles 之类的抓包工具辅助看请求但记住这单纯是本地开发调试手段与线上环境无关。对毕设而言开发者工具自带的调试面板已经覆盖了九成的排查场景把这面板用熟比什么都强。6. 毕业论文、PPT 与演示视频怎么把做出来的东西讲出高分做完系统、调完 bug离答辩还差最后一公里。很多同学代码写得还不错却倒在论文和 PPT 上论文结构像流水账PPT 全是代码截图演示视频录到一半接口报错。这部分我按交付顺序讲一遍。6.1 论文结构六个章节怎么安排既完整又不容易被挑刺一篇“基于微信小程序的家具商城系统”的论文建议按下面的框架写第一章 绪论写研究背景和意义概述目前电商与小程序发展现状然后明确本文主要工作。注意这里别抄“随着互联网的快速发展”这类空话直接写现实需求传统家具行业获客难、线上商城体验不佳、需要一种跨平台、轻量级的选购工具。第二章 相关技术介绍写微信小程序开发框架、WXML/WXSS/JS、后端框架如 Spring Boot、MySQL、HTTPS、RESTful API。每项技术写 200~300 字即可不要抄长篇教程。第三章 需求分析画用例图写功能性需求用户端和管理端和非功能性需求性能、安全、兼容性、易用性。第四章 系统设计给出总体架构图、功能模块图、核心流程图登录流程、下单流程、支付流程然后是数据库设计所有表字段要列表说明。第五章 系统实现分模块写页面效果和关键代码每个模块配合截图和简短分析。这里的关键代码不是整段贴而是贴最有代表性的部分比如登录封装、SKU 选择、分页加载、订单创建并加文字说明这段代码的作用和思路。第六章 系统测试写测试环境、功能测试用例表、兼容性测试、性能结果。测试用例表至少列 15 条以上包括输入、步骤、预期结果、实际结果。第七章 总结与展望总结你做了什么、有哪些不足展望后面可以增加什么。论文写作里最容易被老师盯住的坑是“图与文字对不上”。你画的架构图里有什么模块正文就必须讲到什么模块你测了哪些功能测试表就要完整覆盖。答辩前把论文里所有图表、术语过一遍确保每个名词你都能口头解释。6.2 PPT 怎么讲才像“亲手做过的”PPT 的页数控制在 25 页左右比较合理对应 15 分钟左右的陈述。页面分配可以这样封面和项目背景 3 页系统目标与技术选型 4 页系统设计与数据库 6 页核心功能实现 6 页测试与演示 4 页总结和致谢 2 页。PPT 上不要贴大段代码要贴核心代码片段和结果截图。比如讲分页加载就放三行关键代码加一张 Network 面板请求参数截图。截图上要有真实的商品数据不要用“商品1、商品2”这种占位文案答辩老师看到会扣印象分。讲稿里提前准备好几个“为什么”的答案。比如为什么选择微信小程序答相比 App 无需安装、开发成本低、微信生态内分享传播方便。为什么库存要在后端校验答前端的校验只是提升用户体验后端校验才是真实的安全防线。为什么订单金额要后端重算答前端传参可以被篡改所有关键业务数据以后端计算为准。这些问题答顺了基本就稳了。6.3 演示视频录制实操演示视频是线上评审或存档的重要材料录制时注意四个细节分辨率、时长、数据、流程。建议用手机录屏和小程序开发者工具的双机位方式一台手机展示小程序界面操作另一台展示开发者工具或后台管理界面后期把两路画面剪辑到一起。如果条件不够单拍小程序界面也是可行的但要保证画面清晰、没有晃动。视频时长控制在 8 到 12 分钟。流程走完这条线进入小程序首页 - 浏览分类 - 关键词搜索 - 打开商品详情 - 选择 SKU - 加入购物车 - 进入购物车勾选商品 - 填写地址 - 提交订单 - 模拟支付 - 查看订单列表 - 切换后台管理端 - 管理商品/发货。每一个节点停留 2 秒以上方便评审看清。录制前先把数据准备好测试账号、库存充足的几个商品、可以用的收货地址。录制时不要在页面上临时输入长文本容易断节奏也容易录进尴尬的输入错误。如果某个环节容易报错提前多试几遍找到最稳定的操作路径。最后导出视频文件时格式选 MP4命名规范一些比如“家具商城系统演示视频.mp4”放进你的源码交付包。最后再分享一个我自己的习惯做完整个项目后我会先把论文里每个模块对应的页面都点一遍然后对着论文的“系统实现”章节逐一确认截图和描述没有夸大。接下来会在交付包的 README 里写一遍完整的环境搭建步骤照着步骤从零到一重新部署一次确保任何拿到源码的人都能复现。这一套流程下来项目稳不稳、能不能讲明白你自己心里就有数了。如果你正在为这套家具商城项目熬夜希望这篇内容能帮你少走一点弯路把该拿到的分数稳稳拿住。