1. 项目全貌：先想清楚家具商城小程序到底要装下什么

微信小程序家具商城系统，这几年几乎成了计算机专业毕业设计里的“常青树”。十个选小程序的同学里，至少有三四个会挑商城方向，而家具商城又比普通的数码、服饰商城更贴近实体行业，功能上既有通用电商的购物车、订单、支付，又带着大件商品的特殊性，比如多规格参数、运费策略、预约咨询。正因如此，一套能跑通、能讲明白、能写进论文里的家具商城，天然就是一份不错的中级难度题目。

但我也见过很多拿到类似标题和源代码的同学，步骤卡得五花八门：有人连项目都导不进微信开发者工具，有人登录成功后拿不到用户信息，有人把商品列表做成了“一次性加载全部”导致小程序性能分拉低，还有人被答辩老师追问“库存怎么扣”“订单状态怎么流转”时支支吾吾。问题基本不在功能多复杂，而是对整套系统的“为什么”没搞清楚。

这篇文章的价值，就是帮你把一条完整的链路理顺：从功能需求怎么拆、技术选型怎么定，到数据库表怎么设计、核心代码怎么写，再到论文、PPT、演示视频怎么准备。内容完全可以对应到你手里的这一套“微信小程序家具商城系统毕业论文+PPT（附源代码+演示视频）”上去，把它变成真正属于你自己的、能站得住脚的作品。

1.1 用户端：不是放几个页面就算完

先看小程序端，也就是用户能看到的那部分。一个合格的家具商城，至少要覆盖下面这些模块：

• 首页：轮播图、金刚区入口、热销推荐、新品上架、家具风格分类入口。首页是整个小程序的门面，也是答辩时老师最先看到的地方，做得干净、流畅，印象分直接拉满。
• 分类页：按客厅、卧室、餐厅、书房、定制家具等维度分类，支持二级分类和分类右侧的商品列表。
• 搜索：用户输入关键词，搜索商品名称、风格、材质，支持分页展示结果。
• 商品详情页：大图轮播、价格、SKU选择（颜色、材质、尺寸）、库存展示、收藏、加入购物车、立即购买、商品详情图文。
• 购物车：商品列表、数量加减、单选/全选、合计金额、删除商品、去结算。
• 结算页：收货地址选择、运费计算、订单备注、优惠信息展示。
• 订单中心：待付款、待发货、待收货、已完成、售后/退款，以及订单详情页。
• 个人中心：微信登录后的用户信息、我的收藏、收货地址管理、设置。

一个容易忽略的点是家具商城的“行业气质”。家具是大件、低频、高客单价的品类，用户在详情页里需要看得足够仔细才会下单。所以商品详情页一定要有多角度大图、材质说明、尺寸参数和风格标签。很多同学随便找几十张图塞上去就完事，这到了答辩现场很容易被问“你的商品信息模型是怎么设计的”。

1.2 管理端：缺少管理端的商城只能算半个系统

很多论文里的家具商城只做了小程序端，这是不完整的。完整系统必须有一个后台管理界面，哪怕是最精简的版本，也要能管理商品和订单。管理端一般放在 PC 端或 H5 后台，核心功能包括：

• 商品管理：添加商品、编辑商品、上下架、设置价格与库存、管理商品图片。
• 分类管理：维护分类树，调整排序。
• 订单管理：查看订单列表、确认发货、标记物流单号、处理取消订单。
• 数据概览：今日订单数、成交量、新增用户等基础统计。

我建议管理端即使写得简陋，也一定要做。原因很直接：论文里需要用例图和模块图，如果只有用户端，系统边界显得太窄。答辩时老师问“商家怎么管理商品”，你总不能说“用数据库直接改”，这一句话就能把分数拉低。有一个能跑起来的管理后台，哪怕只是网页版的商品和订单管理，整个系统的完整度就完全不同。

1.3 功能优先级：毕业设计最怕的不是少，而是乱

选功能时有的同学恨不得把优惠券、秒杀、直播、积分全塞进去，结果代码堆成山，论文里却讲不清楚。正确的思路是分优先级来做：

• P0 必须做：微信登录、商品浏览、商品详情、SKU选择、购物车、下单、支付流程模拟、订单管理、后台商品与订单管理。
• P1 推荐做：收藏、地址管理、搜索、分类、列表分页加载、订单状态流转。
• P2 能做就做：优惠券、新品推荐、浏览历史、预约到店、物流信息查询。

这套优先级基本对应答辩评分点：功能完整度、数据一致性、业务逻辑闭环。P0 保证“闭环”，P1 保证“体验”，P2 则是你论文里的“创新点”。我个人的习惯是先闭环再扩展，哪怕后期时间不够，砍掉的也只是加分项，核心系统站得住。

2. 技术选型与核心原理：每一个“为什么”都要能答上来

技术选型这块是答辩老师最爱深挖的区域。你的论文里写了“采用微信小程序+Spring Boot+MySQL”，那就得能解释清楚：为什么小程序用原生而不是 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.js（Express/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_sku：SKU 表。字段有 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、keyword：

Page({ 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 四个步骤，把别人的源码替换成自己的项目

很多同学第一步就卡在“改了代码但小程序里都是空白”上。这里有一套标准的替换流程：

1. 修改 appid：在微信开发者工具里打开项目，把 appid 换成你自己的小程序 appid，或者用测试号。如果不改，部分接口和预览功能会受限。
2. 配置合法域名：在小程序后台“开发管理 -> 开发设置 -> 服务器域名”里，把后端接口域名加到 request 合法域名中。开发调试阶段可以暂时勾选开发者工具的“不校验合法域名”选项，但演示时记得关掉。
3. 初始化数据库：把项目自带的 .sql 文件导入 MySQL，创建数据库和账号，并修改后端配置里的数据库连接信息。
4. 替换图片资源：把项目里的占位图片全部替换成自己的图片文件。注意别用微信后台图片压缩太狠的图，模糊的商品图在详情页非常影响观感。

替换完成后，先在开发者工具里跑通“首页加载 - 商品详情 - 加购 - 下单”这条主链路，再去翻其他页面。不要一次性改完所有页面再统一调试，报错时很难定位是环境问题还是代码问题。

4.3 二次开发：给家具商城加一个能说出亮点的功能

源码拿到手后，直接原样交出去很容易被认定是“网上找的”。聪明做法是加一个自己能讲清楚的小功能，让它变成你真正掌握的增量功能。以家具商城为例，我给你两个低成本高收益的方向：

第一个是“预约到店”。这是家具品类的特色需求，实现难度不高：在详情页或个人中心加一个“预约到店”入口，调用 wx.chooseLocation 选择门店地址，填写预约时间和联系方式，提交后生成一条预约记录。后端加一张 appointment 表，管理端能看到预约列表。这个功能在论文章节里可以写成一节“面向家具行业的本地化服务功能”，天然贴合题意。

第二个是“订单超时自动取消”。下单但不支付会占用库存，可以加一个定时任务或消息队列延迟处理。比如订单超过 30 分钟未支付，自动把状态改成“已取消”，并释放对应 SKU 的库存。如果后端用 Spring Boot，可以用 @Scheduled 做定时扫描；使用云开发，则可以用定时触发器。这个功能能引出“库存释放”“定时任务设计”“状态一致性”等话题，答辩时非常好讲。

做二次开发时，注意别贪多。一个到两个功能足够，核心是把改动点记录清楚，论文里对应画出流程图和测试用例。

5. 高频问题与排查技巧实录：那些每次都有人踩的坑

下面这张速查表，是我结合大量同学做相似项目时踩过的坑整理出来的。建议收藏，调试时对照着排查。

表格之外，还有三个值得展开讲的重点排查场景。

第一个是登录态失效。微信的 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 里写一遍完整的环境搭建步骤，照着步骤从零到一重新部署一次，确保任何拿到源码的人都能复现。这一套流程下来，项目稳不稳、能不能讲明白，你自己心里就有数了。如果你正在为这套家具商城项目熬夜，希望这篇内容能帮你少走一点弯路，把该拿到的分数稳稳拿住。