每年这个时候都有不少同学被毕业设计题目卡住。尤其是看到“基于微信小程序实现电子商城购物平台管理系统【附项目源码论文说明】”这种题第一反应是“这还不简单就是一个购物小程序嘛”真正做起来才发现里面藏着两个词——“平台”和“管理系统”。这意味着你不光要做一个面向消费者的微信小程序还得把后端接口、数据库、管理后台、订单流转全部串起来工作量比想象中多一倍。这篇内容就是我从拿到这类题目到完成系统、写完论文、通过答辩的完整复盘。不是粘贴代码而是把设计思路、技术选型、数据库坑、前后端联调、论文编排这些真正决定成败的环节拆开讲。适合正在做“微信小程序商城/购物平台”类毕业设计的同学也适合想快速上手前后端分离项目的开发者参考。关键是你拿到手的每一份源码只有知道它为什么这么写、哪里能改、哪里有坑才能真正变成你自己的东西。1. 项目整体设计与技术选型解析1.1 题目里的“商城”和“管理系统”到底指什么很多同学看到“电子商城购物平台管理系统”就默认只需要做一个用户端小程序。这是最大的误判。毕业设计题目一旦出现“管理系统”基本意味着系统要分为两个视角一个是C端用户使用的小程序一个是B端运营/管理人员使用的后台。C端小程序解决的是“购物”问题用户注册登录、浏览商品、搜索分类、查看详情、加入购物车、生成订单、支付、查看订单状态。B端管理后台解决的是“管理”问题管理员维护商品信息、上下架商品、修改库存、处理订单发货、查看用户列表、看到基础的销售统计。缺少任何一端这个题目的核心考核点就不完整。你可以把B端做得很简单但不能没有。哪怕只是一个简单的Web管理页面把商品和订单的CRUD做出来论文里的功能结构图、用例图也都会丰满很多。另外要注意“平台”两个字。它暗示这不是单一卖家的静态展示页而是具备多商品、多分类、多状态、多用户交互的动态系统。动态系统必然要连数据库、写后端接口不是用WXML写死几个商品卡片就能交差的。1.2 前端为什么选微信小程序原生开发而不是 uni-app 或 H5微信小程序原生开发和 uni-app、Taro 这类跨端框架一直在被比较。就毕业设计这个场景我强烈建议优先选原生开发。理由很直接原生开发基于微信官方提供的 WXML、WXSS、JS、JSON 四件套微信开发者工具打开即调试出问题的地方大多能直接搜索到官方文档教师评判时也更认可“这是微信小程序技术栈”。uni-app 虽然能一套代码编译多端但在毕业设计中往往只用到微信小程序端额外引入 Vue 语法、编译链路反而增加了不必要的复杂度。一旦出现编译后样式错乱、组件兼容差异排查起来比原生慢得多。如果你已经会用 Vue又想用 uni-app 写也不是不行。但从答辩角度老师问“小程序是怎么实现的”你讲“原生组件、生命周期、Page 注册、wx.request 请求”比讲“uni-app 封装后的标签”更有说服力。原生开发还有一个隐藏优势很多已开源的项目源码就是原生写的入手快、改起来直接不需要先熟悉一层框架的抽象。1.3 后端选型Spring Boot MySQL 是最稳妥的组合后端可选的技术栈很多Java Spring Boot、Node.js Express、Python Flask/Django、Go Gin 等。但放在高校毕业设计的语境下Spring Boot MySQL 是安全系数最高的组合。原因是Spring Boot在国内教学和公司项目中使用广泛资料多、模板多遇到中文报错也容易搜到答案。它天然支持 RESTful APIController-Service-Mapper三层结构清晰论文里画架构图、时序图都很好讲。MySQL则是最常见的关系型数据库导入SQL脚本方便数据表和字段设计一目了然导师审核数据库设计时没有任何理解成本。还有一种思路是使用微信小程序云开发也就是云数据库、云函数那一套。云开发的优势是不用自己部署服务器省了环境配置但它有两个明显问题第一很多学校机房或演示环境网络受限云函数调试和部署可能卡壳第二论文里如果写“数据库设计”章节云数据库的集合结构和SQL关系型思维的展示效果弱很多。如果题目没有强制要求云开发我建议还是老老实实走 Spring Boot MySQL。1.4 系统模块划分与功能清单一个合格的商城系统功能模块可以拆成下面这些模块面向角色核心功能必做程度用户模块小程序用户登录、获取用户信息、收货地址维护高商品模块用户/管理员分类浏览、商品列表、商品详情、搜索高购物车模块用户加购、改数量、勾选、删除、结算高订单模块用户/管理员创建订单、支付/模拟支付、订单状态流转、发货高管理后台模块管理员商品管理、订单管理、用户管理、统计高轮播图/公告模块用户/管理员首页轮播图配置、公告维护中建议在动手写代码之前先画出系统角色和用例图。用户端至少五个页面首页、分类、购物车、订单列表、我的商品详情页可以单独算一个。管理后台至少三个页面商品管理、订单管理、数据概览。把页面清单和接口清单列出来后面写代码会快很多也不会写着写着漏功能。2. 数据库设计与核心功能实现2.1 核心数据表设计与字段解释数据库是商城系统的地基。表结构设计不合理后面所有代码都会别扭。我以一个跑通的项目为例把核心表列出来。用户表 user字段类型说明idbigint主键openidvarchar微信用户唯一标识nicknamevarchar昵称avatarvarchar头像路径phonevarchar手机号可手动录入roletinyint0普通用户 1管理员create_timedatetime注册时间商品表 goods字段类型说明idbigint主键category_idbigint分类idnamevarchar商品名称main_imagevarchar主图detail_imagestext详情轮播图逗号分隔pricedecimal售价original_pricedecimal原价用于划线展示stockint库存salesint销量statustinyint1上架 0下架descriptiontext富文本/普通描述create_timedatetime创建时间商品表里有一个 detail_images 用逗号拼接图片地址这是学生项目常见的做法。如果商品详情图片较多也可以拆成商品图片表但会增加联表查询复杂度。毕业设计用逗号分隔字段完全够用数据库设计说明里讲清楚即可。购物车表 cart 需要注意的一点是购物车应该冗余商品快照字段吗我的建议是只保存商品id、数量、选中状态商品名称、价格、图片实时从商品表联表查询。因为购物车不需要保留历史价格用户加购后如果商品价格变了应该展示最新价格。但订单表就不同了。订单表 orders 是整个系统的核心表字段设计尤其关键字段类型说明idbigint主键order_novarchar订单编号业务唯一user_idbigint下单用户idtotal_amountdecimal订单总金额statustinyint0待付款 1已付款 2已发货 3已完成 4已取消receiver_namevarchar收货人姓名receiver_phonevarchar收货人电话receiver_addressvarchar收货地址create_timedatetime下单时间pay_timedatetime支付时间ship_timedatetime发货时间订单明细表 order_item 需要保存和订单一致的商品快照商品名称、商品图片、单价、数量、小计金额。原因很简单用户下单后后台管理员可能修改商品名称或价格历史订单展示不能被商品表的变化影响。把下单那一刻的商品信息复制到订单明细中才是电商系统的正确做法。这个细节一定要在论文中写明属于加分项。其他表还包括 category 分类表、address 收货地址表、banner 轮播图表。整体表数量控制在 7~9 张比较合适太少显得系统单薄太多又增加无用复杂度。2.2 用户登录与手机号授权机制小程序登录是一个容易被新手搞混的点。它并不是传统意义上的“输入用户名密码”而是基于微信生态静默授权的流程。标准的登录链路是小程序端调用wx.login()获取临时 code小程序把 code 发送到后端接口后端调用微信官方接口code2Session用 code 换取openid和session_key后端用 openid 查询用户表如果不存在自动创建新用户后端生成自定义登录态 token 返回给小程序小程序把 token 存到wx.setStorageSync后续请求自动带上。这个流程里要注意wx.login返回的 code 五分钟内有效且只能使用一次后端需要把它作为临时凭证而不是长期依赖。真正的身份标识是 openid每个用户在小程序下的 openid 是唯一且稳定的。关于手机号获取现在微信小程序获取真实手机号需要企业主体认证并且使用button的open-typegetPhoneNumber才能触发用户点击后授权后端再利用 session_key 解密手机号。如果是个人主体的毕业设计很可能没有权限调用这个接口。稳妥的做法是把手机号做成个人中心的可编辑字段用户手动填写或者干脆不设计手机号模块收货地址里带联系电话即可。千万不要为了追求功能完整去硬接一个跑不通的接口答辩时翻车会很难看。另一个关键点是用户身份的管理员标识。不要指望微信授权就能区分管理员。最简单的方式是在用户表加 role 字段管理员账号由后端SQL预置比如设置指定 openid 或手动在数据库中将某个用户 role 改为 1管理后台登录时校验 role 字段。毕业设计用这种方式最直接。2.3 购物车、订单与支付流程的状态设计购物车的交互逻辑并不复杂但状态很容易混乱。我建议购物车表只存三个核心值用户id、商品id、数量。前端每次勾选或取消勾选时把当前购物车列表整体提交到后端重新计算总金额不要在后端维护“勾选状态”因为用户可能会换一个设备购物车的勾选状态没有必要持久化。从购物车生成订单的流程是这样的前端获取购物车中被勾选的商品列表前端把商品id列表和数量列表、收货地址一起传给后端后端循环检查每个商品的库存是否足够足够则生成订单主表和订单明细表扣减库存库存不足则统一返回失败不生成任何订单前端收到成功响应后跳转订单详情或收银台页面。订单状态我用 0~4 五个数字表示状态流转非常清晰待付款创建订单成功后的初始状态已付款用户点击“模拟支付”成功后已发货管理员在后台点击发货后已完成用户确认收货后已取消待付款状态下用户主动取消或超时未支付。这里有一个非常关键的细节扣减库存的 SQL 必须用条件更新防止并发情况下超卖。不要用“先查库存再 update”的两步方式因为两个请求同时读到库存为1然后都执行 update就会变成负数。正确写法是UPDATE goods SET stock stock - #{count} WHERE id #{goodsId} AND stock #{count}如果更新影响行数为0说明库存不足后端直接抛出“商品库存不足”异常。这个写法在论文中作为“解决超卖问题”的亮点写出来老师会认可。关于支付毕业设计一般不会真的接入微信支付因为个人主体没有商户号企业主体申请流程也长。最常见的做法是“模拟支付”在待付款订单页放一个“立即支付”按钮点击后调用后端接口直接把订单状态从待付款改为已付款同时把支付时间写入。如果论文里觉得模拟支付不够高级可以在系统设计说明中注明“为了演示方便支付环节采用模拟逻辑真实微信支付需要商户号资质此处保留接口设计”。3. 微信小程序端关键页面与接口联调3.1 自定义顶部导航栏与高度适配电商类小程序经常要自定义顶部导航栏不是为了炫技而是为了让首页头部能够融入背景图、搜索框或自定义胶囊布局。默认的导航栏只能显示标题、背景色、文字颜色想要实现沉浸式页面必须自定义。自定义导航栏需要先在app.json或者具体页面的 json 文件中配置{ navigationStyle: custom }然后在页面顶部用position: fixed定位一个自定义导航栏容器。这里最核心的问题是导航栏高度怎么算不然不同手机上样式会错位。正确的计算方式是在app.js初始化时获取系统信息wx.getWindowInfo({ success: (res) { const menu wx.getMenuButtonBoundingClientRect(); const statusBarHeight res.statusBarHeight; const navBarHeight (menu.top - statusBarHeight) * 2 menu.height; this.globalData.statusBarHeight statusBarHeight; this.globalData.navBarHeight navBarHeight; this.globalData.menuButton menu; } });这里的原理是微信右上角胶囊按钮包含胶囊按钮和它的上下留白区域垂直居中于导航栏所以导航栏总高度 状态栏高度 胶囊按钮顶部到状态栏底部的距离的两倍 胶囊按钮的高度。精确点理解menu.top - statusBarHeight是胶囊相对状态栏底部的上间距把上间距下面复制一份作为下间距再加胶囊高度就是自定义导航栏应占的总高度。这个公式我实测了很多机型适配度很高。自定义导航栏里一般左侧放返回箭头和标题右侧预留胶囊按钮的区域避免文字被胶囊盖住。页面内容需要给顶部padding-top留出导航栏高度否则内容会顶到状态栏里去。3.2 首页、分类、商品详情、购物车、订单页面的交互设计小程序前端页面数量不多但每个页面都有固定套路。首页建议用swiper做轮播图下面接一个分类金刚区用 flex 布局排列四五个小图标再往下是商品列表。商品列表可以用scroll-view或onReachBottom触底加载分页数据。分页接口用pageNum和pageSize两个参数后端返回总条数和当前页数据前端通过hasMore判断是否还能继续加载。分类页一般是经典的左右两栏结构左侧是分类列表右侧是当前分类下的商品列表。点击左侧分类右侧重新请求商品数据。这里需要注意右侧列表一旦用了position: fixed布局要计算好高度不然底部页面可能被遮挡。商品详情页的信息要足够完整主图轮播、价格、库存、销量、商品描述。底部固定两个按钮“加入购物车”和“立即购买”。“立即购买”可以走直接创建订单的流程绕过购物车。不过大多数项目里“立即购买”会先把商品加入购物车再跳转到购物车结算页逻辑实现更简单避免单独写一套购买接口。购物车页面的核心是选中状态管理。前端用checkbox实现全选和单选每当勾选状态或数量变化时重新计算“已选商品总价”。这里记住一点数量变化不要立刻调数据库接口实时改库存而是等用户点击“结算”时再验证库存否则用户只改了数量不下单库存却被扣减了会出现严重 bug。订单列表页面建议用几个tab切换不同订单状态状态对应关系在前端做一个字典映射。例如statusMap {0:待付款, 1:已付款, 2:已发货, 3:已完成, 4:已取消}。每张订单卡片展示订单号、商品缩略图、商品名称、总金额、状态按钮。如果状态是待付款就显示“去支付”“取消订单”如果是已发货就显示“确认收货”。3.3 网络请求封装与登录态保持小程序里每一个 HTTP 请求都要封装不能在页面里到处写wx.request。我习惯把所有请求集中到一个request.js中。一个比较实用的封装思路是const request (url, method, data) { return new Promise((resolve, reject) { wx.request({ url: ${BASE_URL}${url}, method: method || GET, data: data || {}, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) || }, success: (res) { if (res.data.code 401) { wx.redirectTo({ url: /pages/login/login }); return; } resolve(res.data); }, fail: reject }); }); };为什么要在 header 里统一带 Authorization因为后端的登录拦截器是根据 token 判断请求身份的。如果后端使用拦截器校验所有接口那么没有 token 的请求会被直接拒绝。所以登录接口本身要么放在白名单里要么单独使用另一个方法发送。登录态保持的核心在于wx.login是静默的不需要用户手动点击。小程序启动后可以立即用 code 换 token。但获取昵称头像时微信要求用button open-typechooseAvatar和昵称输入框方式不能像以前那样自动弹窗。所以常见的处理方式是用户进入“我的”页面时如果本地没有用户信息就展示一个引导授权的弹窗点击“微信用户一键登录”先wx.login获取 code 换 token然后用户设置头像昵称属于“用户信息完善”流程这样登录不再依赖受限接口。真正的坑在于联调环境。开发者工具中默认勾选了“不校验合法域名”可以请求http://localhost:8080或局域网地址。但真机预览时不能用 localhost必须把后端接口地址改成电脑的局域网 IP比如http://192.168.1.100:8080并且手机和电脑连同一个 Wi-Fi。如果后端开启了防火墙还要保证端口能访问到。前几次真机调试连不上接口十有八九是这个原因。4. 后台管理系统与论文写作、源码整理4.1 后台管理系统要做什么商品管理、订单管理、统计管理后台是区分“商城”和“管理系统”的关键。如果只做小程序端题目中的“管理系统”就名存实亡。管理后台不用做太复杂但功能必须闭环。我推荐用 Vue Element UI 做一个简单后台或者用 Bootstrap jQuery Thymeleaf 写一个服务端渲染后台也可以。如果项目源码是前后端分离的管理后台和用户端小程序共用同一套后端接口只是不同界面。管理后台至少包括登录页管理员输入账号密码后端校验后返回 token管理端保存 token 到 localStorage数据概览展示商品总数、用户总数、今日订单数、销售额总览可以引入 ECharts 画柱状图或折线图商品管理商品列表、新增商品、编辑商品、上下架切换、删除商品订单管理订单列表、按状态筛选、订单详情查看、订单发货操作用户管理用户列表、查看用户信息、禁用/启用用户。管理后台的接口要单独加上管理员校验。最简单的方案是后端写一个拦截器判断 token 对应用户的 role 是否为 1不是管理员直接返回 403。这个拦截器只需放在管理后台的接口路径前缀/admin下面。注意商品图片上传问题。后台新增商品时通常要上传图片如果本地没有配置静态资源映射图片路径无法被前端访问。Spring Boot 中可以加一个静态资源映射配置把本地磁盘目录映射成访问路径比如http://ip:8080/images/xxx.jpg。或者更省事直接用外部图床链接把网络图片地址填到商品图片字段里。图片能不能显示直接影响演示效果必须提前测。4.2 项目源码如何整理与使用说明无论是自己从零写还是基于网上开源项目改造源码整理都是毕业设计交付的重要环节。老师第一眼看的就是项目能不能跑起来README 不清晰印象分会打折扣。一个规范的源码结构长这样├── backend # Spring Boot后端工程 │ ├── src/main/java │ ├── src/main/resources │ └── pom.xml ├── miniprogram # 微信小程序前端工程 ├── admin # 管理后台前端工程 ├── database │ └── mall.sql # 数据库脚本 └── README.md # 部署说明README 中包含什么数据库导入方式、MySQL 版本和密码配置、后端启动端口、小程序 appid 配置、管理后台账号密码、接口文档地址。尤其要写清楚“默认管理员账号admin / 123456”方便老师测试。拿到开源源码时要注意几点先看数据库脚本是否存在再启动后端再看小程序。不要一上来就改代码。跑通后再按自己的需求改每一步都做一个小备份。源码里如果包含node_modules、target、dist这类目录提交压缩包前删除否则压缩包体积巨大老师下载也麻烦。4.3 毕业论文结构安排与查重经验论文是这个毕业设计的另一半工作量大纲通常是这样第一章 绪论研究背景、国内外现状、研究意义、论文组织结构。第二章 相关技术微信小程序、Spring Boot、MySQL、Vue等技术介绍。写这一章不要太长每个技术写清楚“是什么、为什么选它”即可。第三章 需求分析从普通用户和管理员两个角色出发写功能性需求和非功能性需求配用例图、业务流程图。第四章 系统设计总体架构图、功能模块设计、系统流程图、接口格式约定。第五章 数据库设计ER图、数据表清单、每张表的关键字段说明、表关系说明。第六章 系统实现按模块写核心功能的实现配页面截图和关键代码片段。第七章 系统测试功能测试用例表、测试结果、并发库存扣减测试等。第八章 总结展望对项目做总结提出未来可以优化的地方。写作时有个技巧需求分析章节画的图表越细致导师会觉得你的前期工作做得越扎实系统实现章节一定要配真实截图不要贴大段代码核心代码只需要贴关键片段并用文字解释逻辑。查重方面我的经验是不要直接复制网上博客的原话。技术背景、需求描述这些内容先自己理解再用自己的话写一遍。尤其“微信小程序”的背景介绍网上到处都有几乎每份论文都会写不改写几乎是必中查重。核心代码不会被算入重复很正常但如果你照抄别人的源码且代码中保留了相同注释有些查重系统会压缩代码后对比所以最好自己重新整理注释和变量命名。5. 从零到复现的常见问题与避坑指南5.1 微信开发者工具与真机调试的典型问题小程序开发过程中的报错五花八门但有一条规律80% 的问题都能通过“看报错信息 查官方文档”解决。最常见的坑是“不在合法域名列表里”。开发阶段你需要在微信开发者工具的“详情-本地设置”中勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”否则请求http://localhost:8080或内网 IP 会被拦截。真机调试时如果用的是同一局域网 IP也要保持该勾选项但要记住预览/真机调试时若后端不是 HTTPS必须用调试模式正式发布版本则要求合法域名还得是 HTTPS。另一个常见问题是顶部导航栏自定义后页面内容被状态栏遮挡。原因很简单只配置了navigationStyle: custom却没有给页面根节点的padding-top加上状态栏高度。解决办法在 3.1 中已经给出导航栏高度建议在app.js计算一次存到globalData中各页面通过getApp().globalData引用。还有同学会遇到按钮样式在 Android 和 iOS 上不一致的问题。这和微信的button默认样式有关解决方法是自己在 WXSS 里覆盖把button::after的边框去掉同时避免依赖系统字体渲染差异。关于“登录获取手机号”的热搜词这里再强调一次如果你的小程序没有企业认证getPhoneNumber接口大概率会报错或返回“该功能无法使用”。毕业设计演示时碰到这种情况非常尴尬。所以我的建议是手机号字段做成用户手动输入或绑定微信昵称头像登录不要把手机号获取作为登录硬性依赖。小程序开发工具经常提示“组件未找到”“文件不存在”检查是否删了文件但没有删掉 pages 配置里的注册项。“单选框”“复选框”样式不好看很多同学会直接引第三方 UI 库但刚上手的项目建议先自己写几个简单 flex 样式避免引入库后尺寸过大超过主包 2MB 限制。小程序压缩包一旦超过 2MB开发者工具会拒绝上传这个坑我已经见过太多次了。真遇到超包先删无用图片和组件再把 tabBar 图标压缩到 40KB 以下。5.2 后端启动与接口联调的坑后端项目跑不起来大多集中在几个点。Spring Boot 端口被占用。默认 8080 如果被其他程序抢走启动会直接报Port already in use。改端口的办法很简单在application.yml中设置server.port: 8081同时小程序端的BASE_URL要同步改。MySQL 连接失败要检查三件事数据库服务是否启动、连接用户名密码是否正确、MySQL 版本对应驱动。MySQL 8.x 的驱动类名是com.mysql.cj.jdbc.DriverURL 需要加serverTimezoneAsia/Shanghai否则会报时区错误。如果本地已经安装了 MySQL 5.7也能用直接改 URL 加 allowPublicKeyRetrievaltrue 即可。跨域问题只在管理后台网页访问后端时会出现小程序本身没有浏览器同源策略限制。管理后台如果用了 Vue 开发需要在 Spring Boot 里加一个CorsFilter或配置CrossOrigin否则浏览器控制台会报Access-Control-Allow-Origin错误。接口联调时最常见的返回格式不统一。后端要约定统一的response结构例如{ code: 200, message: success, data: {} }小程序端request.js先判断code再取data这样后续所有接口都依照同一个模式降低排查难度。分页是很多同学容易忽略的细节。列表接口返回的分页对象要包含total、records、current、size小程序端触底刷新时用total判断是否还有下一页。如果后端只返回了数组前端无法知道有没有更多数据用户滑到底部就会出现一直加载的错觉。5.3 答辩演示前的自查清单答辩能不能顺利很多时候不取决于项目有多少炫酷功能而取决于演示顺不顺、自圆其说的能力。我每次答辩前都会按下面这个清单过一遍第一准备一套完整的测试数据。至少 10 个商品、5 个分类、3 个不同状态的订单。商品图片要用清晰、能正常加载的图片不要用http://localhost或占位图。第二演示路径要通进入小程序 - 浏览首页 - 搜索/分类找商品 - 查看详情 - 加入购物车 - 结算 - 填写收货地址 - 模拟支付 - 查看订单状态 - 切到管理后台 - 处理发货 - 回到小程序确认收货。这条路径能完整走通项目的主流程就稳了。第三提前录制一份演示视频3~5 分钟放到电脑桌面上。万一现场 Wi-Fi 挂了、接口部署临时不可用可以直接播放视频同时口头讲解流程。这不是作弊是一种项目交付的完整性体现。第四背熟几个典型问题的回答思路。比如“订单状态有哪些如何流转”“购物车如何保存不登录能不能加购”“数据库索引如何设计”“怎么防止商品超卖”“为什么订单明细要存商品快照”。这些问题对应系统设计章节只要提前梳理完全答得上来。第五管理后台不要用真实验证码或短信登录避免现场收不到验证码。直接用账号密码登录密码写在演示 PPT 上。第六确认后端服务在演示机器上是开机自启状态数据库服务不要被安全软件拦截。最好避免现场手动敲命令启动项目用一键启动脚本或者提前启动完成。最后再分享一个实操里的体会我自己做这个项目时踩过最深的坑是“过度追求页面漂亮忽视了业务流程”。小程序商城再好看如果用户下不了单、订单状态改不过来答辩时就是致命伤。所以我的建议很简单先把一条主流程从数据库到后端再到小程序和管理后台全部打通之后再回头优化页面细节。拍照色调、按钮圆角、交互动效都是锦上添花不是雪中送炭。拿到项目源码也一样别急着改颜色改字体先看 SQL 脚本、跑通后端、用小程序的 AppID 把登录链路走通再考虑加自己的功能点。比如你可以给商品详情加一个“猜你喜欢”给订单列表加一个“售后申请”给管理后台加一个“销售排行”。这几个功能不大但足以让你在答辩时理直气壮地说“这个系统是在参考源码基础上我独立设计实现的”。另外一个小技巧微信开发者工具里养成清缓存、重新编译的习惯。很多奇怪的问题是缓存引发的。真机上如果接口正常但页面数据不刷新先清理小程序缓存再重新打开。这个小操作能帮你省下不少答辩前的焦虑时间。