拓冰网站定制 
1. 这个毕设到底要做什么功能清单与工作量估算先说句实话微信小程序类的电商项目在毕业设计里属于烂大街但就是稳的类型。选题不算新颖但它不容易翻车为什么因为微信小程序生态成熟文档齐全云开发、支付、登录这些能力都有现成接口哪怕你不会后端也能用云函数凑出一套完整业务闭环。而我这次要讲的项目是基于微信小程序的米家商城也就是模拟米家商城核心购物链路的一个毕业设计。在做功能清单之前必须要先给自己泼一盆冷水毕设不是商业项目你不要想着把米家商城全部功能搬过来。真实米家商城有智能硬件绑定、场景自动化、社区、售后工单、视频专区……这些你全做做到答辩那天都做不完。正确的做法是抓住电商系统的主干也就是逛 选 买 查。我最终敲定的功能范围是这样的用户模块微信一键登录、个人资料展示、收货地址管理商品模块首页Banner与金刚区入口、商品分类、商品列表、商品搜索、商品详情交易模块SKU选择、加入购物车、购物车编辑、下单结算、订单创建订单模块订单列表、订单详情、取消订单、确认收货我的模块我的订单、我的钱包余额展示非必须、售后入口只做页面这里我建议每个模块都先列成一张功能表再给每项标一个工作量等级比如登录 SSKU M退款 L。为什么会建议标工作量因为很多同学做毕设容易陷入越做越嗨、最后收不住的状态。你做了两天促销秒杀系统觉得很酷但到了答辩前一周发现订单页面还没做然后就慌了。所以第一步先把功能边界确定写在论文需求分析那一章里后面所有开发都在这个清单内推进。工作量我用了一个倒推法毕业设计给到开发的时间一般是三到八周按每天有效编码3小时来算分类页我规划了2天购物车1天半登录加token体系2天支付联调4天——因为微信支付和商户号申请本身就是最拖时间的环节后面我会专门讲怎么用模拟支付降低风险。2. 小程序架构与米家商城页面地图tabBar、分包与导航设计2.1 tabBar的选择为什么我用四个tab而不是五个微信小程序的全局配置里app.json的tabBar是最先要定的。我见过很多商城项目底部栏放五个入口首页、分类、购物车、消息、我的看着很全但对毕设来说消息中心是个很尴尬的模块——你既没有客服系统也没有推送体系做出来就是一个空壳页面答辩时一打开就是暂无消息反而暴露功能没做全。我的方案是四个tab也就是{ tabBar: { color: #999999, selectedColor: #FF6B00, backgroundColor: #ffffff, list: [ { pagePath: pages/index/index, text: 首页 }, { pagePath: pages/category/category, text: 分类 }, { pagePath: pages/cart/cart, text: 购物车 }, { pagePath: pages/user/user, text: 我的 } ] } }选中色我用了米家风格的橙色#FF6B00这个颜色在视觉上也很有辨识度。四个tab的好处是每个页面都有明确的核心任务答辩时老师问这个tab为什么存在你能答出它承载的业务价值。比如分类页对应逛购物车对应选不会答不上来。tabBar的图标建议用PNG图片尺寸81px*81px且必须是纯色可识别的小图标。这里有个坑微信开发者工具可以直接用iconfont字体图标吗不建议在tabBar里用因为tabBar的icon只支持图片路径不支持字体图标。你可以在页面内用字体图标但tabBar一定得准备图片资源。我当时从iconfont下载了SVG再转成PNG注意选色要匹配selectedColor否则选中的时候图片颜色对不上。2.2 分包加载为什么首页和商品详情必须拆开米家商城首页信息密度高图片多商品列表长。如果不做分包所有页面打成一个包主包很容易超过2MB限制。但这里我要补充一个容易忽略的点微信小程序的包限制分两个维度一个是主包大小2MB一个是整个小程序总大小20MB现在主包上限是2M分包总大小上限30M具体以官方文档为准。对毕设项目来说老老实实把图片资源放云端是避免包体积炸掉的根本方案。我这个项目的分包结构大概是这样的├── pages/ // 主包 │ ├── index/ │ ├── category/ │ └── cart/ ├── packageGoods/ // 商品分包 │ ├── pages/goods-list/ │ ├── pages/goods-detail/ │ └── pages/search/ └── packageOrder/ // 订单分包 ├── pages/confirm-order/ ├── pages/order-list/ └── pages/order-detail/分包配置写在app.json的subPackages字段里用root指定目录。这里有个实操细节如果某个页面要从A分包跳转到B分包微信开发者工具会自动要求你用url带上前缀比如/packageGoods/pages/goods-detail/goods-detail?idxxx。一旦分包多了这种路径字符串很容易写错我的习惯是单独建一个constants/route.js文件把页面路径全部导出跳转时统一引用。分包的另一个隐藏好处是首屏加载更快。因为小程序启动时只加载主包商品详情这种大页面在用户点进去的时候才加载体感上流畅很多。答辩的时候你可以把分包加载作为技术亮点讲这个点比我用了flex布局要有分量得多。2.3 顶部导航栏高度自定义导航与机型适配商城类小程序对顶部导航的要求比较特殊。米家商城的首页顶部是一个搜索框而不是默认的微信小程序标题栏。如果用系统默认导航栏只能显示一个固定在左上角的胶囊按钮标题栏背景色可以配但搜索框、城市定位这些都得放在页面里很容易出现搜索框顶着状态栏、或者视觉上高低不齐的问题。因此我选择自定义导航栏。关键是拿到状态栏高度和胶囊按钮位置。// 获取状态栏高度单位px const systemInfo wx.getSystemInfoSync(); // 胶囊按钮位置信息 const menuButton wx.getMenuButtonBoundingClientRect();wx.getMenuButtonBoundingClientRect()这个API很关键它会返回胶囊按钮的 top、right、width、height。自定义导航栏的高度计算业界常用公式是导航栏高度 (胶囊top - 状态栏height) * 2 胶囊height这个公式的原理是胶囊按钮在垂直方向上是居中的胶囊顶部到状态栏底部的距离和胶囊底部到导航栏底部的距离是对称的。所以导航栏总高度就是上间距 胶囊高度 下间距而上间距等于“胶囊top - 状态栏height”。实操里我会把这段逻辑抽成一个工具函数function getNavBarInfo() { const systemInfo wx.getSystemInfoSync(); const menuButton wx.getMenuButtonBoundingClientRect(); const statusBarHeight systemInfo.statusBarHeight; const navBarHeight (menuButton.top - statusBarHeight) * 2 menuButton.height; return { statusBarHeight, navBarHeight, menuButton }; }开发时在页面用padding-top: {{statusBarHeight}}px撑开状态栏再用height: {{navBarHeight}}px放导航内容。这个代码看起来简单但做毕设时很容易踩一个真机坑wx.getSystemInfoSync在部分安卓机型上拿到的statusBarHeight是过时的尤其是小屏手机横竖屏切换之后所以现在更推荐用wx.getWindowInfo()来获取。老API虽然还能用但你写论文的时候建议标注清楚本项目使用新版API替代已废弃的getSystemInfo。3. 核心功能实现商品列表加载更多、SKU选择与购物车3.1 页面列表加载更多不要再用onReachBottom无脑兜底页面列表加载更多是我从热搜词里看到最高频的一个问题也是每个电商小程序必做的核心交互。发起一个商品列表不可能一次性加载1000条所以要做分页。微信小程序里触发加载更多的传统方式是onReachBottom也就是页面滚动到底部时触发。但你要是真做一个商城项目只靠这个远远不够因为页面底部可能还有其他内容比如为您推荐模块用户滑到底部后先看到推荐还是先触发加载体验很微妙。我的做法是列表滚动区域独立出一个scroll-view用scroll-view的bindscrolltolower来触发加载。注意scroll-view必须设置固定高度否则不会触发滚动。我在代码里用了height: calc(100vh - 顶部高度)来撑开列表区域。分页请求的核心参数有三个page、pageSize、hasMore。我强烈建议不要只用一个page判断是否还有下一页而是后端返回total或者hasNext。因为商城列表如果筛选了分类总数会变化page单纯加1没法准确判断边界。Page({ data: { goodsList: [], page: 1, pageSize: 10, hasMore: true, loading: false }, async loadGoodsList() { if (this.data.loading || !this.data.hasMore) return; this.setData({ loading: true }); const res await request({ url: /api/goods/list, data: { page: this.data.page, pageSize: this.data.pageSize } }); const list res.data.list || []; this.setData({ goodsList: this.data.goodsList.concat(list), page: this.data.page 1, hasMore: res.data.hasMore, loading: false }); } });重点讲三个防坑点第一防重复请求。用loading标志位当下拉加载还在请求中用户再触发一次就直接return否则会出现数据翻倍、顺序错乱。第二列表渲染时的wx:key一定要用唯一id我见过有人直接用wx:keyindex这在纯前端写死的Demo里没问题但只要列表涉及增删、排序用index当key会导致组件状态错乱。第三加载更多的UI状态。要让用户明确感知正在加载还是没有更多了。底部通常有三种状态加载中显示加载中...加载完成且还有更多显示上拉加载更多没有更多显示已经到底了。这个状态不要拼在一个字符串里用loadStatus字段控制更清晰。3.2 SKU选择弹窗规格组合背后的数据模型米家商城的商品很多是多规格的比如智能灯的亮度、色温、套餐版本。SKUStock Keeping Unit库存量单位选择是电商项目里中等偏难的功能。我建议毕设至少要做出S1 S2 两种规格组合出唯一SKU的逻辑不要只做单选。这里我贴一个简化的SKU数据结构// 商品详情返回的SKU列表 skus: [ { skuId: 1, color: 白色, version: 标准版, price: 199, stock: 50 }, { skuId: 2, color: 白色, version: 礼盒版, price: 229, stock: 20 }, { skuId: 3, color: 灰色, version: 标准版, price: 199, stock: 0 }, { skuId: 4, color: 灰色, version: 礼盒版, price: 229, stock: 10 } ]当用户选中color白色还没选version时应该把可选的version优先展示出来如果某个组合库存为0比如灰色标准版那个按钮要置灰。这种联动逻辑我建议用一个已经验证过的算法思路把SKU列表转成一个规格属性 - 可选规格值的映射。每次选中一个属性就遍历所有SKU判断包含当前已选组合的SKU有哪些再把这些SKU的可选值合并得到下一级可选规格。很多同学习惯性用三层if嵌套来判断代码写出来又臭又长而且一旦加第三个规格比如带充电器/不带充电器整个判断就要推翻重写。用映射表加遍历的方式扩展性会好很多。答辩时这段数据模型可以重点讲老师只要看到你不是写死规格的基本就能认定项目有设计感。3.3 购物车的选中态与价格联动购物车这个页面看起来很普通但实现时有一个细节容易忽略入库购物车的是什么是商品还是SKU正确的做法是购物车列表的每一项应该对应一个SKU而不是一个商品。因为你选了白色 标准版和灰色 礼盒版是两个不同的SKU价格也可能不同。如果购物车只存goodsId用户改了规格之后价格就乱了。购物车需要保存的字段我建议至少包含cartItem: { cartId, // 购物车条目id goodsId, // 商品id skuId, // 规格id goodsName, skuSpecText, // 白色 标准版 price, count, checked }价格联动的核心就是选中的购物车条目发生变化时重新计算总价。这个在WXML里可以用watch或者计算函数但我更推荐在setData更新购物车列表后单独调用一个calcTotalPrice()函数把总价写在data里。不要在模板里写{{totalPrice}}依赖多个字段的复杂计算那会很难调试。总价永远保存成单独字段这是一个很朴素的建议但能救你命。购物车里还有一个对毕设特别重要的点空购物车视图。米家商城这种大厂产品是不会让新用户看到一个白屏购物车的。你要在购物车里判断cartList.length 0时显示购物车还是空的快去逛逛搭配一个去首页的按钮。别小看这个很多毕设项目空状态没有做用户把商品删光之后页面直接空白答辩演示时老师一操作就露怯。所有列表类页面订单、优惠券、消息都要做空状态。4. 微信登录与会话保持从wx.login()到自定义token的完整链路4.1 为什么不能只靠wx.getUserProfile微信小程序的登录体系最容易踩的坑就是——旧项目用的wx.getUserProfile和wx.getUserInfo拿用户头像昵称到了新版本经常拿不到真实数据因为微信在2022年之后调整了隐私接口规则现在获取用户头像昵称必须通过头像昵称填写能力input typenickname和头像选择组件引导用户自主填写。所以如果你还在代码里写wx.getUserProfile({ success: ... })直接给用户一个弹窗授权这个思路已经行不通了。正确登录链路是这样的前端 wx.login() 获取code → 发送到后端或云函数 → 后端调用微信接口 code2Session 换取 openid 和 session_key → 生成自定义token自己造的登录态返回前端 → 前端把token存入storage → 后续请求带上 token后端验证token先看第一步wx.login()。注意wx.login()拿到的code有效期只有五分钟且只能使用一次它本身不是登录凭证而是换取 openid 的临时票据。很多同学误以为拿到code就可以当token用这是不对的。如果使用云开发可以用云函数来简化// 云函数 login const cloud require(wx-server-sdk) cloud.init() exports.main async (event) { const { OPENID, APPID } cloud.getWXContext() const db cloud.database() const userTable db.collection(users) let user await userTable.where({ openid: OPENID }).get() if (user.data.length 0) { // 新用户写入用户记录 await userTable.add({ data: { openid: OPENID, createTime: Date.now() } }) } // 生成一个自定义登录态用openid时间戳做摘要 const token ${OPENID}_${Date.now()} return { token, openid: OPENID } }这里我故意没写真正的JWT加密因为毕设阶段只要你有一个不透明的token、后端能校验就已经满足会话保持的课程设计目标了。但如果你有余力可以引入JWT把openid作为payload的一部分。这在论文里的写法就是采用JWT方案维护用户态状态避免明文传递openid。4.2 token过期与401刷新后端返回token时一定要考虑过期时间。我非常推荐在响应头或者响应体里带一个expire时间比如7200秒。前端在请求拦截器里做统一处理const request (options) { return new Promise((resolve, reject) { const token wx.getStorageSync(token); wx.request({ ...options, header: { Authorization: Bearer ${token}, ...options.header }, success(res) { if (res.statusCode 401) { // token过期重新登录 wx.removeStorageSync(token); handleLoginRedirect(); return; } resolve(res.data); }, fail: reject }); }); };这个401拦截是所有依赖登录态接口的生命线。如果没有做用户token过期后所有请求都会莫名其妙返回错误页面显示一堆网络异常到时候你排查半天根本定位不到是登录态问题。把401统一处理掉整站的登录体验就稳了一截。4.3 登录按钮与个人信息的交互设计米家商城的我的页面登录前一般显示一个占位头像和点击登录。这里我建议直接用button组件开放能力设为bindtap自己实现wx.login而不是用open-typegetPhoneNumber来拿手机号。手机号接口现在也是隐私接口而且毕设用不上短信验证码绑定手机号的意义不大没必要给自己增加工作量。如果项目需要显示用户昵称和头像不要用原来的授权弹窗方式改用官方推荐的昵称填写。具体到小程序里就是放一个input标签设置typenickname头像则用一个按钮让用户调用chooseAvatar上传。这里我不展开贴完整代码但你要记住这是2023年后小程序个人中心的标准写法网上很多老教程已经过时了。5. 支付模块的毕设级实现从微信支付到模拟支付的降级方案5.1 微信支付为什么难不是你写得慢是你申请不下来支付是整个毕设里最特别的一环因为它不仅仅是代码问题。要在自己的小程序里真正拉起微信支付必须满足几个硬条件小程序已完成微信认证、主体是企业或者个体工商户个人主体不支持开通微信支付、并且要申请微信支付商户号、绑定AppID并签署协议。对于大多数在校本科生来说个人身份根本申请不下来。就算申请下来答辩现场用真钱支付也不现实总不能为了演示让老师转你一块钱。所以我对毕设项目的建议是代码按真实微信支付流程写但运行环境切成模拟支付。真实支付的下单链路是前端请求后端创建订单 → 后端调用微信支付统一下单API参数有openid、订单号、金额、回调地址 → 微信返回 prepay_id → 后端将 prepay_id 和签名参数返回前端 → 前端调用 wx.requestPayment(参数) 拉起支付面板 → 用户付款成功微信服务器回调后端通知支付结果 → 后端修改订单状态这些流程你在论文里可以写清楚代码也可以预留wx.requestPayment的调用位置。但在开发环境我建议做一个payType开关当payType mock时点击立即支付直接弹窗提示模拟支付成功然后把订单状态改成已支付。async handlePay(orderId) { const payType this.data.payType; // 通过配置控制mock / real if (payType mock) { wx.showModal({ title: 模拟支付, content: 演示环境确认支付成功, success: async (res) { if (res.confirm) { await request({ url: /api/order/pay, method: POST, data: { orderId } }); wx.showToast({ title: 支付成功, icon: success }); } } }); return; } // 真实支付逻辑调后端获取支付参数再 wx.requestPayment }为什么建议写一个开关而不是直接注释掉真实支付因为你答辩时如果老师问你微信支付怎么做的你直接展示模拟支付老师会质疑你没做过真实流程。但如果你代码里保留了完整的真实支付函数并且能讲清楚统一下单、回调验签、订单状态同步这就是一个工程降级的思路。反而显得你有抗风险意识。5.2 订单状态机从待付款到待收货的状态流转支付这块还有一个必做项就是订单状态。订单状态不要用字符串到处传我推荐用数字枚举const OrderStatus { CREATED: 10, // 已创建/待付款 PAID: 20, // 已支付/待发货 SHIPPED: 30, // 已发货/待收货 FINISHED: 40, // 已完成 CANCELED: 0 // 已取消 };状态机是电商项目里低成本高收益的设计。你在数据库里存订单状态如果存的是中文待付款后面想做统计、做筛选都会很别扭。用数字枚举前端再映射成对应的中文文案逻辑清晰很多。状态流转要写死在代码里不能出现用户点一下确认订单订单状态就从待付款跳到已完成这种情况。正常的流转是创建订单 - 支付成功 - 卖家发货 - 用户确认收货 - 完成。其中取消订单只能在待付款状态执行。你在答辩时画一张简单的状态图代码注释里也可以用但不能用mermaid直接文字描述即可老师一看就懂。5.3 确认订单页地址选择与库存校验确认订单页是我觉得整个项目里细节密度最高的页面。要干的事有选择收货地址、展示商品清单、计算运费、计算总价、提交订单。地址选择这一块如果做全套要用wx.chooseAddress获取微信收货地址需要用户授权也可以自己做地址管理CRUD。我当时选了后者因为毕设要体现数据库增删改查地址管理正好是一组完整的CRUD还能顺带展示表单校验。地址列表存在云数据库的addresses集合里用户新增地址时做简单的字段校验比如手机号正则、姓名非空。提交订单前一定要做库存校验。原因很简单如果用户在商品详情页停留了很久等到下单时他选的那个SKU可能已经被别人买完或者库存少了这时再拿旧库存创建订单后面发货环节一定会出问题。所以在后端的创建订单接口里先查SKU库存再减库存而且要保证这两个操作在同一事务里。云开发数据库支持事务微信云开发有db.runTransaction如果你用自建后端那就在MySQL里用FOR UPDATE行锁。6. 数据统计、云开发与答辩展示把工作量讲成系统设计6.1 为什么我推荐云开发而不是自建后端先讲结论毕设用微信云开发云函数 云数据库 云存储能省掉后端部署、服务器、域名备案的一长串麻烦。你只需要在微信开发者工具里开通云开发就会得到一个免费的测试环境云函数直接写JavaScript数据库是文档型存储放商品图片前端用wx.cloud.callFunction调用云函数。这个选型最大的好处是整个系统都在微信生态内不需要额外维护服务器答辩演示不容易翻车。万一现场网络不行云端服务全都不可用那才是灾难。当然云开发也有缺点比如不能直接用传统的关系型SQL做复杂的联表查询。但对于商城这种业务来说可以通过冗余字段解决商品列表接口直接返回需要的商品名、价格、主图而不是像MySQL那样用join去关联三张表。我在做米家商城的时候后端接口是这样拆的goodsService商品列表、商品详情、搜索cartService购物车增删改查orderService创建订单、订单列表、订单详情、取消/支付/收货userService登录、地址管理每个服务对应一个云函数目录云函数内部再调云数据库。这样一个云函数就是一个小模块后续好维护。对应论文里你就可以画一个后端微服务划分图文字形式比那些一个云函数里塞1000行代码的毕设强太多。6.2 云数据库集合设计直接照抄可用我把数据库集合结构和关键字段列在这里你可以直接参考goods商品集合{ _id: 商品id, name: 米家智能台灯, category: 台灯, mainImage: cloud://xxx/xxx.jpg, images: [..., ...], price: 199, originalPrice: 259, sales: 1000, skus: [ { skuId, spec, price, stock } ], detail: 富文本描述, status: 1 // 1上架 0下架 }orders订单集合{ _id: 订单id, orderNo: 20240501123456, userId: openid, address: { name, phone, province, city, detail }, goodsList: [ { goodsId, skuId, name, specText, price, count, image } ], totalAmount: 499, status: 10, createTime: Date.now() }cart购物车集合注意我建议购物车数据放云数据库而不是本地storage这样换设备购物车不丢答辩也更像真实系统。每个购物车条目一个文档字段参考前面讲的cartItem。addresses地址集合当前用户的所有地址isDefault标记是否默认地址。这里特别提醒一个云数据库坑**在云函数里读数据库权限不受前端权限限制所以判断用户数据归属时要自己在代码里加where({ userId: openid })过滤。**如果你把权限设成所有人可读就会出现一个用户能读到别人订单的严重安全问题。这个细节在答辩时老师大概率会问你要主动讲云数据库的权限控制默认是仅创建者可读写但这不是绝对安全的我在云函数中统一根据openid做数据隔离。6.3 搜索与分类从分类筛选到关键词搜索的降级方案真正的米家商城搜索有搜索历史、热门搜索、联想建议。毕设项目中我建议做搜索历史 结果列表就够。搜索历史可以存在本地wx.setStorageSync不用走后端。好处是省一个集合、也不用处理用户画像坏处是不算真正的用户行为记录数据库设计但毕设重心不在这里。分类页我用的是一个典型的电商左侧一级分类 右侧商品列表布局。左侧scroll-view显示一级分类右侧用scroll-view显示该分类下的商品。这个页面看起来结构简单但有一个性能细节右侧商品列表图片多一定要在image标签上设置lazy-load属性并且控制一次渲染的数据量。千万不要在右侧一次性渲染全部商品先用分类id请求接口再做加载更多。分类数据可以这样设计categories: [ { _id: c1, name: 智能家居, children: [智能音箱, 智能传感器] }, { _id: c2, name: 生活电器, children: [吸尘器, 加湿器] } ]点击左侧一级分类时右侧展示对应的二级分类tab再点击二级分类请求对应商品列表。这个交互相对完整页面不算复杂也很适合作为答辩讲解的一个模块。7. 上线前后最容易翻车的五个细节以及我踩过的坑7.1 图片资源本地化是第一个大坑很多同学做商城项目图省事直接在项目里塞几十张商品图一张图500KB整个项目瞬间超过2MB。更稳妥的做法是图片全部传到云存储代码里只存cloud://开头的路径。如果你还没有云开发环境也可以用临时图床但答辩现场还是建议用云存储因为cloud://路径在开发者工具里可直接预览在真机上也能正常加载。本地图片只保留tabBar图标和默认占位图。7.2 页面栈溢出不要一直用navigateTo小程序页面栈最多10层超过之后wx.navigateTo会失效。电商项目里用户从首页进入商品列表再进商品详情再进确认订单然后返回再进订单详情……如果每次都navigateTo很容易超过10层。我建议列表进入详情用navigateTo但详情跳确认订单用redirectTo关闭当前页。因为从确认订单还能返回详情没有太大意义这能避免页面栈堆积。7.3 富文本详情的解析问题商品详情页要展示长图或富文本。最简单的方式是后端直接返回一段HTML富文本前端用rich-text组件渲染。但这里有个坑rich-text不支持部分HTML标签例如section可能解析异常。如果你从别处复制的富文本可能样式全乱。我在做的时候把商品详情图片单独存数组详情页用swiper轮播图加图片列表来展示反而不容易出问题。7.4 真机调试和开发者工具的差异开发者工具上正常的CSS真机上可能会不一样。最常见的几个差异是flex布局中gap属性在旧版安卓WebView上不支持建议用margin代替吸顶效果用position: sticky在部分iOS版本有问题我用scroll-view的sticky-header属性解决页面滚动和scroll-view嵌套的时候滚动会互相干扰要设置scroll-y并注意高度控制我建议至少在答辩前一周开始天天用真机预览调试不要最后一天才拿手机测试。7.5 微信小程序年审、域名与体验版关于微信小程序年审个人主体小程序认证是免费的但如果是学校要求用企业主体年审要交300元左右费用。毕设一般不用考虑年审但如果从申请注册到开发再到答辩体验版测试你最好能有一个已经注册好的小程序AppID。没有AppID也可以用测试号但测试号的功能有限比如支付、云开发都可能受限所以尽量提前用学校或者自己的身份注册一个小程序账号。域名这块更要注意如果在云开发模式下请求都是wx.cloud.callFunction不需要配置request合法域名但如果你用的是自建后端就必须在小程序管理后台配置request合法域名且该域名必须备案。这就是为什么我反复建议云开发的原因之一省事。8. 论文与复盘这套商城走完我沉淀了什么看到这里其实你已经拥有一套可以照着写的米家商城毕设方案了。最后我想说一点和大作业完全不同的东西毕设做小程序代码写得漂亮是一方面更重要的是能把为什么这样设计讲清楚。我做这个项目时最大的感受就是小程序开发的上手门槛真不高但它逼着你去想一个完整业务链路的边界。比如下了单没付款怎么办付款了没发货怎么办发货了用户不确认收货怎么办这些问题不是一个前端页面能解决的背后全是状态机、数据一致性、权限控制这些软件工程课上学过的东西。答辩的时候你可以这样讲主线以微信小程序为前端载体利用云开发构建了商品管理、购物车、订单、支付模拟的一体化系统重点解决了SKU多规格选择、列表分页加载、用户登录态保持等实际问题。这一段话朴实无华但每一环你都真的动过手和背题库的完全不一样。最后分享一个小技巧我会在项目根目录放一个README.md把启动步骤、目录结构、功能清单、测试账号如果有全部写清楚。这个文件不仅方便你过两周再看自己代码答辩前给老师看一眼也会有加分效果。这套项目从0到1走完代码量大概五千行上下工作量恰好卡在毕设的合理区间。剩下你要做的就是先把环境搭好从 tabBar 和首页开始一步步把清单上的功能划掉。做毕设没有捷径但每多做一个功能你离能讲清楚项目就更近一步。 微信小程序商城开发实战：从云开发到购物车与SKU设计
1. 这个毕设到底要做什么功能清单与工作量估算先说句实话微信小程序类的电商项目在毕业设计里属于烂大街但就是稳的类型。选题不算新颖但它不容易翻车为什么因为微信小程序生态成熟文档齐全云开发、支付、登录这些能力都有现成接口哪怕你不会后端也能用云函数凑出一套完整业务闭环。而我这次要讲的项目是基于微信小程序的米家商城也就是模拟米家商城核心购物链路的一个毕业设计。在做功能清单之前必须要先给自己泼一盆冷水毕设不是商业项目你不要想着把米家商城全部功能搬过来。真实米家商城有智能硬件绑定、场景自动化、社区、售后工单、视频专区……这些你全做做到答辩那天都做不完。正确的做法是抓住电商系统的主干也就是逛 选 买 查。我最终敲定的功能范围是这样的用户模块微信一键登录、个人资料展示、收货地址管理商品模块首页Banner与金刚区入口、商品分类、商品列表、商品搜索、商品详情交易模块SKU选择、加入购物车、购物车编辑、下单结算、订单创建订单模块订单列表、订单详情、取消订单、确认收货我的模块我的订单、我的钱包余额展示非必须、售后入口只做页面这里我建议每个模块都先列成一张功能表再给每项标一个工作量等级比如登录 SSKU M退款 L。为什么会建议标工作量因为很多同学做毕设容易陷入越做越嗨、最后收不住的状态。你做了两天促销秒杀系统觉得很酷但到了答辩前一周发现订单页面还没做然后就慌了。所以第一步先把功能边界确定写在论文需求分析那一章里后面所有开发都在这个清单内推进。工作量我用了一个倒推法毕业设计给到开发的时间一般是三到八周按每天有效编码3小时来算分类页我规划了2天购物车1天半登录加token体系2天支付联调4天——因为微信支付和商户号申请本身就是最拖时间的环节后面我会专门讲怎么用模拟支付降低风险。2. 小程序架构与米家商城页面地图tabBar、分包与导航设计2.1 tabBar的选择为什么我用四个tab而不是五个微信小程序的全局配置里app.json的tabBar是最先要定的。我见过很多商城项目底部栏放五个入口首页、分类、购物车、消息、我的看着很全但对毕设来说消息中心是个很尴尬的模块——你既没有客服系统也没有推送体系做出来就是一个空壳页面答辩时一打开就是暂无消息反而暴露功能没做全。我的方案是四个tab也就是{ tabBar: { color: #999999, selectedColor: #FF6B00, backgroundColor: #ffffff, list: [ { pagePath: pages/index/index, text: 首页 }, { pagePath: pages/category/category, text: 分类 }, { pagePath: pages/cart/cart, text: 购物车 }, { pagePath: pages/user/user, text: 我的 } ] } }选中色我用了米家风格的橙色#FF6B00这个颜色在视觉上也很有辨识度。四个tab的好处是每个页面都有明确的核心任务答辩时老师问这个tab为什么存在你能答出它承载的业务价值。比如分类页对应逛购物车对应选不会答不上来。tabBar的图标建议用PNG图片尺寸81px*81px且必须是纯色可识别的小图标。这里有个坑微信开发者工具可以直接用iconfont字体图标吗不建议在tabBar里用因为tabBar的icon只支持图片路径不支持字体图标。你可以在页面内用字体图标但tabBar一定得准备图片资源。我当时从iconfont下载了SVG再转成PNG注意选色要匹配selectedColor否则选中的时候图片颜色对不上。2.2 分包加载为什么首页和商品详情必须拆开米家商城首页信息密度高图片多商品列表长。如果不做分包所有页面打成一个包主包很容易超过2MB限制。但这里我要补充一个容易忽略的点微信小程序的包限制分两个维度一个是主包大小2MB一个是整个小程序总大小20MB现在主包上限是2M分包总大小上限30M具体以官方文档为准。对毕设项目来说老老实实把图片资源放云端是避免包体积炸掉的根本方案。我这个项目的分包结构大概是这样的├── pages/ // 主包 │ ├── index/ │ ├── category/ │ └── cart/ ├── packageGoods/ // 商品分包 │ ├── pages/goods-list/ │ ├── pages/goods-detail/ │ └── pages/search/ └── packageOrder/ // 订单分包 ├── pages/confirm-order/ ├── pages/order-list/ └── pages/order-detail/分包配置写在app.json的subPackages字段里用root指定目录。这里有个实操细节如果某个页面要从A分包跳转到B分包微信开发者工具会自动要求你用url带上前缀比如/packageGoods/pages/goods-detail/goods-detail?idxxx。一旦分包多了这种路径字符串很容易写错我的习惯是单独建一个constants/route.js文件把页面路径全部导出跳转时统一引用。分包的另一个隐藏好处是首屏加载更快。因为小程序启动时只加载主包商品详情这种大页面在用户点进去的时候才加载体感上流畅很多。答辩的时候你可以把分包加载作为技术亮点讲这个点比我用了flex布局要有分量得多。2.3 顶部导航栏高度自定义导航与机型适配商城类小程序对顶部导航的要求比较特殊。米家商城的首页顶部是一个搜索框而不是默认的微信小程序标题栏。如果用系统默认导航栏只能显示一个固定在左上角的胶囊按钮标题栏背景色可以配但搜索框、城市定位这些都得放在页面里很容易出现搜索框顶着状态栏、或者视觉上高低不齐的问题。因此我选择自定义导航栏。关键是拿到状态栏高度和胶囊按钮位置。// 获取状态栏高度单位px const systemInfo wx.getSystemInfoSync(); // 胶囊按钮位置信息 const menuButton wx.getMenuButtonBoundingClientRect();wx.getMenuButtonBoundingClientRect()这个API很关键它会返回胶囊按钮的 top、right、width、height。自定义导航栏的高度计算业界常用公式是导航栏高度 (胶囊top - 状态栏height) * 2 胶囊height这个公式的原理是胶囊按钮在垂直方向上是居中的胶囊顶部到状态栏底部的距离和胶囊底部到导航栏底部的距离是对称的。所以导航栏总高度就是上间距 胶囊高度 下间距而上间距等于“胶囊top - 状态栏height”。实操里我会把这段逻辑抽成一个工具函数function getNavBarInfo() { const systemInfo wx.getSystemInfoSync(); const menuButton wx.getMenuButtonBoundingClientRect(); const statusBarHeight systemInfo.statusBarHeight; const navBarHeight (menuButton.top - statusBarHeight) * 2 menuButton.height; return { statusBarHeight, navBarHeight, menuButton }; }开发时在页面用padding-top: {{statusBarHeight}}px撑开状态栏再用height: {{navBarHeight}}px放导航内容。这个代码看起来简单但做毕设时很容易踩一个真机坑wx.getSystemInfoSync在部分安卓机型上拿到的statusBarHeight是过时的尤其是小屏手机横竖屏切换之后所以现在更推荐用wx.getWindowInfo()来获取。老API虽然还能用但你写论文的时候建议标注清楚本项目使用新版API替代已废弃的getSystemInfo。3. 核心功能实现商品列表加载更多、SKU选择与购物车3.1 页面列表加载更多不要再用onReachBottom无脑兜底页面列表加载更多是我从热搜词里看到最高频的一个问题也是每个电商小程序必做的核心交互。发起一个商品列表不可能一次性加载1000条所以要做分页。微信小程序里触发加载更多的传统方式是onReachBottom也就是页面滚动到底部时触发。但你要是真做一个商城项目只靠这个远远不够因为页面底部可能还有其他内容比如为您推荐模块用户滑到底部后先看到推荐还是先触发加载体验很微妙。我的做法是列表滚动区域独立出一个scroll-view用scroll-view的bindscrolltolower来触发加载。注意scroll-view必须设置固定高度否则不会触发滚动。我在代码里用了height: calc(100vh - 顶部高度)来撑开列表区域。分页请求的核心参数有三个page、pageSize、hasMore。我强烈建议不要只用一个page判断是否还有下一页而是后端返回total或者hasNext。因为商城列表如果筛选了分类总数会变化page单纯加1没法准确判断边界。Page({ data: { goodsList: [], page: 1, pageSize: 10, hasMore: true, loading: false }, async loadGoodsList() { if (this.data.loading || !this.data.hasMore) return; this.setData({ loading: true }); const res await request({ url: /api/goods/list, data: { page: this.data.page, pageSize: this.data.pageSize } }); const list res.data.list || []; this.setData({ goodsList: this.data.goodsList.concat(list), page: this.data.page 1, hasMore: res.data.hasMore, loading: false }); } });重点讲三个防坑点第一防重复请求。用loading标志位当下拉加载还在请求中用户再触发一次就直接return否则会出现数据翻倍、顺序错乱。第二列表渲染时的wx:key一定要用唯一id我见过有人直接用wx:keyindex这在纯前端写死的Demo里没问题但只要列表涉及增删、排序用index当key会导致组件状态错乱。第三加载更多的UI状态。要让用户明确感知正在加载还是没有更多了。底部通常有三种状态加载中显示加载中...加载完成且还有更多显示上拉加载更多没有更多显示已经到底了。这个状态不要拼在一个字符串里用loadStatus字段控制更清晰。3.2 SKU选择弹窗规格组合背后的数据模型米家商城的商品很多是多规格的比如智能灯的亮度、色温、套餐版本。SKUStock Keeping Unit库存量单位选择是电商项目里中等偏难的功能。我建议毕设至少要做出S1 S2 两种规格组合出唯一SKU的逻辑不要只做单选。这里我贴一个简化的SKU数据结构// 商品详情返回的SKU列表 skus: [ { skuId: 1, color: 白色, version: 标准版, price: 199, stock: 50 }, { skuId: 2, color: 白色, version: 礼盒版, price: 229, stock: 20 }, { skuId: 3, color: 灰色, version: 标准版, price: 199, stock: 0 }, { skuId: 4, color: 灰色, version: 礼盒版, price: 229, stock: 10 } ]当用户选中color白色还没选version时应该把可选的version优先展示出来如果某个组合库存为0比如灰色标准版那个按钮要置灰。这种联动逻辑我建议用一个已经验证过的算法思路把SKU列表转成一个规格属性 - 可选规格值的映射。每次选中一个属性就遍历所有SKU判断包含当前已选组合的SKU有哪些再把这些SKU的可选值合并得到下一级可选规格。很多同学习惯性用三层if嵌套来判断代码写出来又臭又长而且一旦加第三个规格比如带充电器/不带充电器整个判断就要推翻重写。用映射表加遍历的方式扩展性会好很多。答辩时这段数据模型可以重点讲老师只要看到你不是写死规格的基本就能认定项目有设计感。3.3 购物车的选中态与价格联动购物车这个页面看起来很普通但实现时有一个细节容易忽略入库购物车的是什么是商品还是SKU正确的做法是购物车列表的每一项应该对应一个SKU而不是一个商品。因为你选了白色 标准版和灰色 礼盒版是两个不同的SKU价格也可能不同。如果购物车只存goodsId用户改了规格之后价格就乱了。购物车需要保存的字段我建议至少包含cartItem: { cartId, // 购物车条目id goodsId, // 商品id skuId, // 规格id goodsName, skuSpecText, // 白色 标准版 price, count, checked }价格联动的核心就是选中的购物车条目发生变化时重新计算总价。这个在WXML里可以用watch或者计算函数但我更推荐在setData更新购物车列表后单独调用一个calcTotalPrice()函数把总价写在data里。不要在模板里写{{totalPrice}}依赖多个字段的复杂计算那会很难调试。总价永远保存成单独字段这是一个很朴素的建议但能救你命。购物车里还有一个对毕设特别重要的点空购物车视图。米家商城这种大厂产品是不会让新用户看到一个白屏购物车的。你要在购物车里判断cartList.length 0时显示购物车还是空的快去逛逛搭配一个去首页的按钮。别小看这个很多毕设项目空状态没有做用户把商品删光之后页面直接空白答辩演示时老师一操作就露怯。所有列表类页面订单、优惠券、消息都要做空状态。4. 微信登录与会话保持从wx.login()到自定义token的完整链路4.1 为什么不能只靠wx.getUserProfile微信小程序的登录体系最容易踩的坑就是——旧项目用的wx.getUserProfile和wx.getUserInfo拿用户头像昵称到了新版本经常拿不到真实数据因为微信在2022年之后调整了隐私接口规则现在获取用户头像昵称必须通过头像昵称填写能力input typenickname和头像选择组件引导用户自主填写。所以如果你还在代码里写wx.getUserProfile({ success: ... })直接给用户一个弹窗授权这个思路已经行不通了。正确登录链路是这样的前端 wx.login() 获取code → 发送到后端或云函数 → 后端调用微信接口 code2Session 换取 openid 和 session_key → 生成自定义token自己造的登录态返回前端 → 前端把token存入storage → 后续请求带上 token后端验证token先看第一步wx.login()。注意wx.login()拿到的code有效期只有五分钟且只能使用一次它本身不是登录凭证而是换取 openid 的临时票据。很多同学误以为拿到code就可以当token用这是不对的。如果使用云开发可以用云函数来简化// 云函数 login const cloud require(wx-server-sdk) cloud.init() exports.main async (event) { const { OPENID, APPID } cloud.getWXContext() const db cloud.database() const userTable db.collection(users) let user await userTable.where({ openid: OPENID }).get() if (user.data.length 0) { // 新用户写入用户记录 await userTable.add({ data: { openid: OPENID, createTime: Date.now() } }) } // 生成一个自定义登录态用openid时间戳做摘要 const token ${OPENID}_${Date.now()} return { token, openid: OPENID } }这里我故意没写真正的JWT加密因为毕设阶段只要你有一个不透明的token、后端能校验就已经满足会话保持的课程设计目标了。但如果你有余力可以引入JWT把openid作为payload的一部分。这在论文里的写法就是采用JWT方案维护用户态状态避免明文传递openid。4.2 token过期与401刷新后端返回token时一定要考虑过期时间。我非常推荐在响应头或者响应体里带一个expire时间比如7200秒。前端在请求拦截器里做统一处理const request (options) { return new Promise((resolve, reject) { const token wx.getStorageSync(token); wx.request({ ...options, header: { Authorization: Bearer ${token}, ...options.header }, success(res) { if (res.statusCode 401) { // token过期重新登录 wx.removeStorageSync(token); handleLoginRedirect(); return; } resolve(res.data); }, fail: reject }); }); };这个401拦截是所有依赖登录态接口的生命线。如果没有做用户token过期后所有请求都会莫名其妙返回错误页面显示一堆网络异常到时候你排查半天根本定位不到是登录态问题。把401统一处理掉整站的登录体验就稳了一截。4.3 登录按钮与个人信息的交互设计米家商城的我的页面登录前一般显示一个占位头像和点击登录。这里我建议直接用button组件开放能力设为bindtap自己实现wx.login而不是用open-typegetPhoneNumber来拿手机号。手机号接口现在也是隐私接口而且毕设用不上短信验证码绑定手机号的意义不大没必要给自己增加工作量。如果项目需要显示用户昵称和头像不要用原来的授权弹窗方式改用官方推荐的昵称填写。具体到小程序里就是放一个input标签设置typenickname头像则用一个按钮让用户调用chooseAvatar上传。这里我不展开贴完整代码但你要记住这是2023年后小程序个人中心的标准写法网上很多老教程已经过时了。5. 支付模块的毕设级实现从微信支付到模拟支付的降级方案5.1 微信支付为什么难不是你写得慢是你申请不下来支付是整个毕设里最特别的一环因为它不仅仅是代码问题。要在自己的小程序里真正拉起微信支付必须满足几个硬条件小程序已完成微信认证、主体是企业或者个体工商户个人主体不支持开通微信支付、并且要申请微信支付商户号、绑定AppID并签署协议。对于大多数在校本科生来说个人身份根本申请不下来。就算申请下来答辩现场用真钱支付也不现实总不能为了演示让老师转你一块钱。所以我对毕设项目的建议是代码按真实微信支付流程写但运行环境切成模拟支付。真实支付的下单链路是前端请求后端创建订单 → 后端调用微信支付统一下单API参数有openid、订单号、金额、回调地址 → 微信返回 prepay_id → 后端将 prepay_id 和签名参数返回前端 → 前端调用 wx.requestPayment(参数) 拉起支付面板 → 用户付款成功微信服务器回调后端通知支付结果 → 后端修改订单状态这些流程你在论文里可以写清楚代码也可以预留wx.requestPayment的调用位置。但在开发环境我建议做一个payType开关当payType mock时点击立即支付直接弹窗提示模拟支付成功然后把订单状态改成已支付。async handlePay(orderId) { const payType this.data.payType; // 通过配置控制mock / real if (payType mock) { wx.showModal({ title: 模拟支付, content: 演示环境确认支付成功, success: async (res) { if (res.confirm) { await request({ url: /api/order/pay, method: POST, data: { orderId } }); wx.showToast({ title: 支付成功, icon: success }); } } }); return; } // 真实支付逻辑调后端获取支付参数再 wx.requestPayment }为什么建议写一个开关而不是直接注释掉真实支付因为你答辩时如果老师问你微信支付怎么做的你直接展示模拟支付老师会质疑你没做过真实流程。但如果你代码里保留了完整的真实支付函数并且能讲清楚统一下单、回调验签、订单状态同步这就是一个工程降级的思路。反而显得你有抗风险意识。5.2 订单状态机从待付款到待收货的状态流转支付这块还有一个必做项就是订单状态。订单状态不要用字符串到处传我推荐用数字枚举const OrderStatus { CREATED: 10, // 已创建/待付款 PAID: 20, // 已支付/待发货 SHIPPED: 30, // 已发货/待收货 FINISHED: 40, // 已完成 CANCELED: 0 // 已取消 };状态机是电商项目里低成本高收益的设计。你在数据库里存订单状态如果存的是中文待付款后面想做统计、做筛选都会很别扭。用数字枚举前端再映射成对应的中文文案逻辑清晰很多。状态流转要写死在代码里不能出现用户点一下确认订单订单状态就从待付款跳到已完成这种情况。正常的流转是创建订单 - 支付成功 - 卖家发货 - 用户确认收货 - 完成。其中取消订单只能在待付款状态执行。你在答辩时画一张简单的状态图代码注释里也可以用但不能用mermaid直接文字描述即可老师一看就懂。5.3 确认订单页地址选择与库存校验确认订单页是我觉得整个项目里细节密度最高的页面。要干的事有选择收货地址、展示商品清单、计算运费、计算总价、提交订单。地址选择这一块如果做全套要用wx.chooseAddress获取微信收货地址需要用户授权也可以自己做地址管理CRUD。我当时选了后者因为毕设要体现数据库增删改查地址管理正好是一组完整的CRUD还能顺带展示表单校验。地址列表存在云数据库的addresses集合里用户新增地址时做简单的字段校验比如手机号正则、姓名非空。提交订单前一定要做库存校验。原因很简单如果用户在商品详情页停留了很久等到下单时他选的那个SKU可能已经被别人买完或者库存少了这时再拿旧库存创建订单后面发货环节一定会出问题。所以在后端的创建订单接口里先查SKU库存再减库存而且要保证这两个操作在同一事务里。云开发数据库支持事务微信云开发有db.runTransaction如果你用自建后端那就在MySQL里用FOR UPDATE行锁。6. 数据统计、云开发与答辩展示把工作量讲成系统设计6.1 为什么我推荐云开发而不是自建后端先讲结论毕设用微信云开发云函数 云数据库 云存储能省掉后端部署、服务器、域名备案的一长串麻烦。你只需要在微信开发者工具里开通云开发就会得到一个免费的测试环境云函数直接写JavaScript数据库是文档型存储放商品图片前端用wx.cloud.callFunction调用云函数。这个选型最大的好处是整个系统都在微信生态内不需要额外维护服务器答辩演示不容易翻车。万一现场网络不行云端服务全都不可用那才是灾难。当然云开发也有缺点比如不能直接用传统的关系型SQL做复杂的联表查询。但对于商城这种业务来说可以通过冗余字段解决商品列表接口直接返回需要的商品名、价格、主图而不是像MySQL那样用join去关联三张表。我在做米家商城的时候后端接口是这样拆的goodsService商品列表、商品详情、搜索cartService购物车增删改查orderService创建订单、订单列表、订单详情、取消/支付/收货userService登录、地址管理每个服务对应一个云函数目录云函数内部再调云数据库。这样一个云函数就是一个小模块后续好维护。对应论文里你就可以画一个后端微服务划分图文字形式比那些一个云函数里塞1000行代码的毕设强太多。6.2 云数据库集合设计直接照抄可用我把数据库集合结构和关键字段列在这里你可以直接参考goods商品集合{ _id: 商品id, name: 米家智能台灯, category: 台灯, mainImage: cloud://xxx/xxx.jpg, images: [..., ...], price: 199, originalPrice: 259, sales: 1000, skus: [ { skuId, spec, price, stock } ], detail: 富文本描述, status: 1 // 1上架 0下架 }orders订单集合{ _id: 订单id, orderNo: 20240501123456, userId: openid, address: { name, phone, province, city, detail }, goodsList: [ { goodsId, skuId, name, specText, price, count, image } ], totalAmount: 499, status: 10, createTime: Date.now() }cart购物车集合注意我建议购物车数据放云数据库而不是本地storage这样换设备购物车不丢答辩也更像真实系统。每个购物车条目一个文档字段参考前面讲的cartItem。addresses地址集合当前用户的所有地址isDefault标记是否默认地址。这里特别提醒一个云数据库坑**在云函数里读数据库权限不受前端权限限制所以判断用户数据归属时要自己在代码里加where({ userId: openid })过滤。**如果你把权限设成所有人可读就会出现一个用户能读到别人订单的严重安全问题。这个细节在答辩时老师大概率会问你要主动讲云数据库的权限控制默认是仅创建者可读写但这不是绝对安全的我在云函数中统一根据openid做数据隔离。6.3 搜索与分类从分类筛选到关键词搜索的降级方案真正的米家商城搜索有搜索历史、热门搜索、联想建议。毕设项目中我建议做搜索历史 结果列表就够。搜索历史可以存在本地wx.setStorageSync不用走后端。好处是省一个集合、也不用处理用户画像坏处是不算真正的用户行为记录数据库设计但毕设重心不在这里。分类页我用的是一个典型的电商左侧一级分类 右侧商品列表布局。左侧scroll-view显示一级分类右侧用scroll-view显示该分类下的商品。这个页面看起来结构简单但有一个性能细节右侧商品列表图片多一定要在image标签上设置lazy-load属性并且控制一次渲染的数据量。千万不要在右侧一次性渲染全部商品先用分类id请求接口再做加载更多。分类数据可以这样设计categories: [ { _id: c1, name: 智能家居, children: [智能音箱, 智能传感器] }, { _id: c2, name: 生活电器, children: [吸尘器, 加湿器] } ]点击左侧一级分类时右侧展示对应的二级分类tab再点击二级分类请求对应商品列表。这个交互相对完整页面不算复杂也很适合作为答辩讲解的一个模块。7. 上线前后最容易翻车的五个细节以及我踩过的坑7.1 图片资源本地化是第一个大坑很多同学做商城项目图省事直接在项目里塞几十张商品图一张图500KB整个项目瞬间超过2MB。更稳妥的做法是图片全部传到云存储代码里只存cloud://开头的路径。如果你还没有云开发环境也可以用临时图床但答辩现场还是建议用云存储因为cloud://路径在开发者工具里可直接预览在真机上也能正常加载。本地图片只保留tabBar图标和默认占位图。7.2 页面栈溢出不要一直用navigateTo小程序页面栈最多10层超过之后wx.navigateTo会失效。电商项目里用户从首页进入商品列表再进商品详情再进确认订单然后返回再进订单详情……如果每次都navigateTo很容易超过10层。我建议列表进入详情用navigateTo但详情跳确认订单用redirectTo关闭当前页。因为从确认订单还能返回详情没有太大意义这能避免页面栈堆积。7.3 富文本详情的解析问题商品详情页要展示长图或富文本。最简单的方式是后端直接返回一段HTML富文本前端用rich-text组件渲染。但这里有个坑rich-text不支持部分HTML标签例如section可能解析异常。如果你从别处复制的富文本可能样式全乱。我在做的时候把商品详情图片单独存数组详情页用swiper轮播图加图片列表来展示反而不容易出问题。7.4 真机调试和开发者工具的差异开发者工具上正常的CSS真机上可能会不一样。最常见的几个差异是flex布局中gap属性在旧版安卓WebView上不支持建议用margin代替吸顶效果用position: sticky在部分iOS版本有问题我用scroll-view的sticky-header属性解决页面滚动和scroll-view嵌套的时候滚动会互相干扰要设置scroll-y并注意高度控制我建议至少在答辩前一周开始天天用真机预览调试不要最后一天才拿手机测试。7.5 微信小程序年审、域名与体验版关于微信小程序年审个人主体小程序认证是免费的但如果是学校要求用企业主体年审要交300元左右费用。毕设一般不用考虑年审但如果从申请注册到开发再到答辩体验版测试你最好能有一个已经注册好的小程序AppID。没有AppID也可以用测试号但测试号的功能有限比如支付、云开发都可能受限所以尽量提前用学校或者自己的身份注册一个小程序账号。域名这块更要注意如果在云开发模式下请求都是wx.cloud.callFunction不需要配置request合法域名但如果你用的是自建后端就必须在小程序管理后台配置request合法域名且该域名必须备案。这就是为什么我反复建议云开发的原因之一省事。8. 论文与复盘这套商城走完我沉淀了什么看到这里其实你已经拥有一套可以照着写的米家商城毕设方案了。最后我想说一点和大作业完全不同的东西毕设做小程序代码写得漂亮是一方面更重要的是能把为什么这样设计讲清楚。我做这个项目时最大的感受就是小程序开发的上手门槛真不高但它逼着你去想一个完整业务链路的边界。比如下了单没付款怎么办付款了没发货怎么办发货了用户不确认收货怎么办这些问题不是一个前端页面能解决的背后全是状态机、数据一致性、权限控制这些软件工程课上学过的东西。答辩的时候你可以这样讲主线以微信小程序为前端载体利用云开发构建了商品管理、购物车、订单、支付模拟的一体化系统重点解决了SKU多规格选择、列表分页加载、用户登录态保持等实际问题。这一段话朴实无华但每一环你都真的动过手和背题库的完全不一样。最后分享一个小技巧我会在项目根目录放一个README.md把启动步骤、目录结构、功能清单、测试账号如果有全部写清楚。这个文件不仅方便你过两周再看自己代码答辩前给老师看一眼也会有加分效果。这套项目从0到1走完代码量大概五千行上下工作量恰好卡在毕设的合理区间。剩下你要做的就是先把环境搭好从 tabBar 和首页开始一步步把清单上的功能划掉。做毕设没有捷径但每多做一个功能你离能讲清楚项目就更近一步。