做毕设或者个人练手项目的时候一说到“购物平台”十个人里有八个都选微信小程序。原因很简单微信有流量、有生态小程序开发门槛又不高做完还能直接用手机扫一扫演示比纯Web页面有说服力多了。但如果真动手去做你会发现从注册AppID、搭项目、写接口到审核上线每一步都有坑。“基于uni-app的在线购物平台”这个题目听起来像烂大街的毕设题目实际上把它做扎实了含金量并不低。这期就把我完整做过的这套uni-app购物小程序的全过程拆开聊。内容覆盖技术选型、目录结构、核心页面、后端接口、数据库设计、支付流程、常见报错不整虚的都是能直接上手的实操方案。无论你是拿它做毕业设计、课程设计还是单纯想学小程序开发这篇文章都能少走不少弯路。1. 项目整体设计与技术选型思路1.1 为什么选uni-app而不是原生小程序选uni-app做跨端购物小程序核心原因就三个一套代码多端复用、Vue语法上手快、插件生态省事。原生微信小程序用的是WXMLWXSSJS那一套虽然也简单但写完之后你会发现同样的业务逻辑换个端就得重写。比如你做完微信小程序想再出一版支付宝小程序、抖音小程序原生写法基本是推倒重来。uni-app基于Vue语法编译时通过条件编译把代码分发到不同平台业务层只需要维护一套这个优势在项目后期特别明显。对于购物类项目来说uni-app还有一个隐藏优势它的API封装粒度更接近业务。比如选择收货地址原生需要调用wx.chooseAddress换到支付宝端要改成my.chooseAddress在uni-app里统一成uni.chooseAddress内部自动做平台转换。这个封装层省掉的不是几行代码而是跨端适配时的排查时间。当然原生小程序也有它的价值包体更小、运行时有更强的平台能力调优空间性能敏感型应用可以考虑。但购物平台这种以业务逻辑为主的场景性能瓶颈在图片、列表、接口响应上跟用的是不是原生关系不大。uni-app的损耗在可接受范围内换取的是开发效率和维护成本的大幅降低。1.2 购物平台的模块边界划分一个完整的在线购物系统从功能模块上可以拆成两个端C端用户小程序和B端管理后台。小程序端面向消费者核心模块包括首页、分类、购物车、订单、个人中心五大Tab再往下拆是商品详情、搜索、下单结算、支付、收货地址、售后等二级页面。管理后台面向运营者负责商品上下架、分类管理、订单处理、库存维护、数据统计。做毕设时很多人会忽略一件事管理后台的复杂度往往比小程序端还高。你可以用uni-app再做一套管理端也可以直接用Vue Element UI做一套Web管理后台甚至为了演示方便做成一个内嵌在小程序里的管理员页面。我的建议是尽量前后端分离、管理端独立部署这样技术难点展示得更充分答辩或汇报时也更有说头。两个端共用同一套后端API通过角色权限做区分。用户在登录时带上身份标识比如role字段后端根据角色决定接口返回的数据量级和操作权限。这样设计的好处是数据模型统一商品、订单、用户这些核心表不需要做双份。1.3 技术栈选型与版本取舍前端框架uni-appVue 3语法HBuilderX 3.x及以上版本直接支持状态管理Vuex项目不大时Pinia也可以但uni-app对Pinia的支持目前还不算特别稳UI组件库uView Plus 或 uni-ui两者二选一即可不要混用后端PHPThinkPHP框架、Node.jsExpress/Koa或 JavaSpring Boot任选一个你熟悉的。PHP和Node在毕设里最常用Spring Boot适合写进简历数据库MySQL 5.7及以上表结构以订单、商品、用户为核心接口风格RESTful API返回JSON数据登录鉴权用JWT Token这里有个切身体会选UI组件库时不要贪多。uView Plus虽然组件全、颜值高但引入方式要注意否则会跟uni-app自带的样式起冲突。我一个朋友就是全量引入uView之后原生button的默认样式被改得乱七八糟排查了半天。建议按需引入或只引入UI组件不要全量导入CSS。2. 前端核心细节与实操要点2.1 项目初始化与三个核心配置文件的职责用HBuilderX创建uni-app项目在“文件 - 新建 - 项目”里选择“uni-app”模板输入项目名称即可。生成目录后必须处理好三个文件这是整个小程序的“地基”。pages.json是页面路由和窗口样式的总配置文件相当于原生小程序的app.json。所有页面都要在pages数组里注册tabBar里配置底部导航。这里有个常被忽略的点tabBar页面必须放在pages数组的前几项而且tabBar.list最多只能配置5个超出会直接编译报错。manifest.json配置应用名称、AppID、组件库版本。微信小程序AppID在微信公众平台注册后获取测试时可以先用测试号。特别注意mp-weixin节点下的appid字段很多人把AppID填到了mp-alipay或其它平台结果运行到微信时还是提示AppID无效。App.vue是整个应用的根组件应用生命周期onLaunch在这里触发适合做全局登录检查、检查更新、初始化全局数据等操作。但要注意App.vue里的onLaunch在冷启动时执行异步请求不要写得太重否则会影响首页首屏渲染速度。2.2 顶部导航栏与iPhone刘海屏适配“微信小程序顶部导航栏高度”这个搜索词的点击量一直不低就是因为自定义导航时不同机型的状态栏高度不一致导致导航栏布局错乱。默认导航栏用原生渲染不需要考虑适配。但很多购物平台为了视觉统一会选择自定义导航栏把pages.json里页面的navigationStyle设为custom然后自己在页面顶部画一个导航条。自定义导航时状态栏高度需要动态获取// utils/system.js export function getStatusBarHeight() { // 注意uni.getSystemInfoSync是同步方法可以安全在onLoad里调用 const systemInfo uni.getSystemInfoSync() return systemInfo.statusBarHeight || 20 } export function getMenuButtonBoundingClientRect() { // 胶囊按钮位置只在微信小程序中有效 // #ifdef MP-WEIXIN const menuButtonInfo uni.getMenuButtonBoundingClientRect() return menuButtonInfo // #endif // 非微信环境给个兜底值 return { top: 20, height: 30 } }拿到状态栏高度和胶囊按钮位置后导航栏高度 状态栏高度 胶囊按钮高度 胶囊按钮上下间距 × 2。这个公式在自定义导航时通用能精确计算出导航栏的实际高度避免内容被刘海遮挡或导航栏偏矮。2.3 请求封装与登录态管理购物平台的每个用户操作基本都要带登录态所以请求封装是第一优先级。我的做法是在utils/request.js里封装一个基于Promise的request函数统一处理baseURL、请求头、Token注入、状态码拦截、错误提示。// utils/request.js const BASE_URL https://你的服务器域名.com export function request({ url, method GET, data {}, needAuth true }) { return new Promise((resolve, reject) { const token uni.getStorageSync(token) const header { Content-Type: application/json } if (needAuth token) header[Authorization] Bearer ${token} uni.request({ url: BASE_URL url, method, data, header, success: (res) { if (res.statusCode 401) { // Token过期或无效清除本地登录态并跳转登录 uni.removeStorageSync(token) uni.removeStorageSync(userInfo) uni.navigateTo({ url: /pages/login/login }) return } if (res.statusCode 200 res.statusCode 300) { resolve(res.data) } else { uni.showToast({ title: res.data.msg || 请求失败, icon: none }) reject(res.data) } }, fail: (err) { uni.showToast({ title: 网络异常, icon: none }) reject(err) } }) }) }登录流程走的是微信登录小程序端调用uni.login拿临时code把code发给后端后端拿着code向微信接口换取openid和session_key再签发自己的JWT Token返回给前端。前端把Token存入Storage后续请求自动带上。这里有一个非常容易踩的坑code只能用一次换完openid就失效所以不能让前端反复提交同一个code。调试时遇到“40029 code无效”报错八成是这里的问题。2.4 商品列表与购物车状态管理购物车是典型的跨页面共享数据场景。首页点“加入购物车”购物车页面要立即显示最新数量和金额中间如果只靠onShow重新拉接口体验会慢半拍而且还要处理并发。用Vuex管理购物车数据是最合理的方案。我在store/modules/cart.js里维护购物车列表、选中状态、总金额三个核心状态const state { cartList: [], // [{ goodsId, goodsName, price, count, checked }] checkedGoods: [], // 选中的商品项 } const getters { cartTotal(state) { return state.cartList.reduce((total, item) total item.count, 0) }, checkedTotalPrice(state) { return state.cartList .filter(item item.checked) .reduce((total, item) total item.price * item.count, 0) } }所有修改购物车的操作通过mutations同步修改比如ADD_TO_CART、TOGGLE_CHECKED、UPDATE_COUNT、DELETE_ITEM。组件内部computed里用mapGetters映射cartTotal和checkedTotalPrice这样不管在哪个页面修改了购物车所有引用的页面都会自动更新。这个方案有一个好处用户从购物车进结算页时不需要再次请求接口直接用内存里的数据就能拼出订单预览速度快、体验好。缺点也很明显如果用户同时在多端操作购物车本地状态会和服务端不一致。解决办法是加购、删购时同步调接口但页面展示以本地Vuex为主以后端返回为准形成“本地优先、后端兜底”的同步策略。2.5 全局弹窗组件封装思路官方uni.showToast确实只支持文本和icon自定义程度低。如果想让弹窗支持图片、按钮、自定义插槽最简单的方案是自己封装一个全局弹窗组件。我之前写过一个轻量的customToast组件核心思路是在components目录里建一个popup-dialog组件组件内部用uni.showModal的样式做基础但内容用slot自定义。再用一个全局的uni.$emit事件机制触发弹窗。template view v-ifvisible classpopup-wrapper view classmask clickonClose/view view classpopup-content slot namecontent/slot view classbtn-group button clickonCancel取消/button button typeprimary clickonConfirm确定/button /view /view /view /template script export default { name: CustomPopup, data() { return { visible: false } }, methods: { open(config) { this.visible true // config里可以传 title, content, confirmText等 }, close() { this.visible false } } } /script封装好了在需要弹窗的页面里引入一次通过uni.$emit(open-popup, {...})即可唤起。这样比每个页面单独写一套弹窗逻辑省事得多样式也统一。需要注意弹窗组件的visible状态要记得在页面卸载时重置否则从A页跳到B页再返回弹窗可能还在。我就是踩过一次这个坑后来在onUnload里补了一个close处理。3. 后端接口设计与数据库实现3.1 数据库核心表结构设计购物平台的数据表设计是整个系统的重心。表结构设计得合理后面写接口、做统计都会很顺畅设计不合理订单和库存对不上、退款状态混乱是你后期debug最痛苦的事情。我的核心表一共7张用户表、商品表、商品分类表、购物车表、订单表、订单商品表、收货地址表。订单表与订单商品表分离是为了支持一个订单包含多个商品多商品合并结算场景如果一张订单只对应一个商品那订单商品表可以直接并入订单表。用户表 user字段名类型说明idint主键自增openidvarchar(64)微信openid唯一索引nicknamevarchar(50)昵称avatarvarchar(255)头像URLphonevarchar(20)手机号选填roletinyint角色0普通用户1管理员create_timedatetime注册时间商品表 goods字段名类型说明idint主键category_idint分类ID关联分类表titlevarchar(100)商品标题subtitlevarchar(200)商品副标题main_imagevarchar(255)主图URLimagestext商品轮播图JSON数组存储pricedecimal(10,2)售价original_pricedecimal(10,2)原价划线价stockint库存salesint销量detailtext富文本或图文详情statustinyint状态0下架1上架create_timedatetime创建时间订单表 order字段名类型说明idint主键order_novarchar(32)订单号唯一索引user_idint用户IDtotal_pricedecimal(10,2)订单总金额pay_pricedecimal(10,2)实付金额pay_typetinyint支付方式1微信支付statustinyint订单状态见下方状态机address_idint收货地址IDtransaction_idvarchar(64)微信支付交易号remarkvarchar(255)用户备注create_timedatetime下单时间pay_timedatetime支付时间ship_timedatetime发货时间finish_timedatetime完成时间订单号生成建议用date(YmdHis) rand(1000,9999)这种格式或者直接用年月日时分秒用户ID后四位保证可读性和唯一性。不要用自增ID直接当订单号会被用户猜到订单规模。3.2 接口清单与RESTful规范接口按模块划分统一返回格式为{ code, msg, data }成功时code为0失败时为错误码。RESTful风格上列表用GET新增用POST更新用PUT/PATCH删除用DELETE。用户模块POST /api/auth/login微信登录参数code返回token和用户信息GET /api/user/info获取用户信息请求头带TokenPUT /api/user/info更新用户资料商品模块GET /api/goods/list商品列表参数keyword、categoryId、page、pageSize、sortByGET /api/goods/detail商品详情参数goodsIdGET /api/category/list分类列表购物车模块GET /api/cart/list获取购物车列表POST /api/cart/add加入购物车参数goodsId、countPUT /api/cart/update修改购物车数量或选中状态DELETE /api/cart/remove删除购物车条目订单模块POST /api/order/create创建订单参数addressId、goodsList、remarkPOST /api/order/pay发起支付参数orderNoGET /api/order/list订单列表参数status0全部1待付款等GET /api/order/detail订单详情参数orderNoPOST /api/order/cancel取消订单POST /api/order/confirm确认收货接口的鉴权策略很简单除登录和商品列表、详情外其他接口都要求请求头携带Authorization: Bearer token。后端在Controller里写一个基础类的checkAuth方法每个需要鉴权的接口先调这个方法减少重复代码。3.3 后端登录接口实现PHP示例用PHP写登录接口思路很直观。拿前端的code调微信官方接口换openid然后查库决定是登录还是自动注册。// Api/AuthController.php public function login(Request $request) { $code $request-post(code); $appid 你的小程序AppID; $secret 你的小程序AppSecret; // 向微信服务器换取 openid $url https://api.weixin.qq.com/sns/jscode2session?appid{$appid}secret{$secret}js_code{$code}grant_typeauthorization_code; $result file_get_contents($url); $result json_decode($result, true); if (isset($result[errcode])) { return json([code 500, msg 登录失败]); } $openid $result[openid]; // 查询用户不存在则自动注册 $user Db::name(user)-where(openid, $openid)-find(); if (!$user) { $userId Db::name(user)-insertGetId([ openid $openid, nickname 微信用户 . mt_rand(10000, 99999), create_time date(Y-m-d H:i:s) ]); } else { $userId $user[id]; } // 生成Token这里用简单的md5拼接生产环境建议用JWT $token md5($openid . time() . mt_rand(1000, 9999)); Db::name(user_token)-insert([ user_id $userId, token $token, expire_time date(Y-m-d H:i:s, time() 7200) ]); return json([code 0, data [token $token, userInfo $user]]); }注意file_get_contents拉远程接口在开发环境没问题但生产环境有的服务器禁用了allow_url_fopen就调用失败。更稳妥的方式是用cURL封装或者用ThinkPHP自带的Http类。另外一个调试技巧微信的jscode2session接口在开发者工具里能正常返回但真机预览时报invalid code很可能是AppID配错了检查manifest.json里是不是填的AppID和后端secret对应的是同一个小程序。3.4 订单状态机设计订单状态是购物平台最容易写乱的模块。我建议把状态定义写在接口文档和维护手册的第一页前后端统一下来。状态值状态含义前端按钮展示用户可执行操作0待付款去支付、取消订单继续支付 / 关闭订单1待发货提醒发货申请退款2待收货查看物流、确认收货确认收货3待评价去评价发表评价4已完成查看详情再次购买5已关闭删除订单删除6退款中查看进度撤销申请这里有个容易漏掉的状态用户付款后、商家发货前订单是“待发货”状态商家发货后、用户确认收货前是“待收货”状态。两者在用户侧看起来都是已付款但后端逻辑不同待发货时用户可申请退款待发货状态商家可发货。我在做第一次版本时把这两个状态合并了导致用户付款后直接看到“确认收货”按钮点下去商家还没发货订单就完成了场面一度很尴尬。后来才把状态细分建模。4. 实操过程从零搭建购物平台的完整流程4.1 HBuilderX创建项目并运行到微信开发者工具首次用HBuilderX开发微信小程序需要先把运行环境配置好关键两步微信开发者工具的安全设置里开启“服务端口”HBuilderX才能自动拉起小程序。打开HBuilderX新建项目选择“uni-app”模板在manifest.json的mp-weixin节点填入微信小程序的AppID菜单栏“运行 - 运行到小程序模拟器 - 微信开发者工具”首次运行会在微信开发者工具中自动打开项目后续代码保存会自动同步编译这个阶段经常遇到的报错是“HBuilderX连接微信开发者工具失败”原因基本是微信开发者工具没有开启服务端口。解决路径微信开发者工具 → 设置 → 安全设置 → 打开“服务端口”。另一个报错是“appid为空”检查manifest.json里的配置是否正确测试阶段可以填测试号AppID但要注意测试号的接口权限有限wx.requestPayment这类支付接口没法完全测试。4.2 首页与商品详情页的实现要点首页是商品的门面一般由“搜索框 轮播图 分类金刚区 商品瀑布流”组成。轮播图和金刚区都是静态配置数据可以从后端接口拉取也可以直接在store里写死看项目需要。商品瀑布流用scroll-view配合触底加载分页每页拉10条或20条性能更好。商品列表的分页是高频考点。后端接口接收page和pageSize返回total、list、hasMore三个字段。前端用onReachBottom触发加载下一页判断hasMore为false时不再请求// pages/home/home.vue data() { return { goodsList: [], page: 1, pageSize: 10, hasMore: true, loading: false } }, methods: { async loadGoods(isRefresh false) { if (this.loading) return this.loading true const res await request({ url: /api/goods/list, data: { page: this.page, pageSize: this.pageSize } }) if (isRefresh) this.goodsList [] this.goodsList this.goodsList.concat(res.data.list) this.hasMore res.data.list.length this.pageSize this.page 1 this.loading false } }, onReachBottom() { if (this.hasMore) this.loadGoods() }商品详情页主要是展示和操作轮播图用swiper组件商品价格、库存、销量是静态渲染参数规格的展示可以先用纯文本列表加购按钮触发Vuex的ADD_TO_CARTmutation同时调后端购物车接口同步。这里有一个非常实用的交互细节加购成功后在按钮位置上弹一个小气泡动画体验提升明显。uni-app用uni.createAnimation就能实现不用引入额外库。4.3 购物车页面的全选、单选、金额计算与删除购物车页面的核心是数据联动单选/全选影响总金额数量增减影响总金额删除影响列表和总金额。这些都在Vuex里维护组件内部只需要调用mutation和getter。全选逻辑// store/modules/cart.js setAllChecked(state, checked) { state.cartList.forEach(item { item.checked checked }) }计算总金额const getters { totalPrice(state) { return state.cartList .filter(item item.checked) .reduce((sum, item) sum item.price * item.count, 0) .toFixed(2) } }删除时要注意和本地缓存的同步。如果购物车数据同时存在本地和Server端删除时先乐观更新本地Vuex再向Server发起删除请求失败时回滚。这种“乐观UI”策略能让界面响应更快但必须在失败时做好提示和回滚否则会出现“删了又出现”的笑话。购物车页面还有一个隐藏需求空状态。数据为空时要展示一个可爱的空车提示和一键去逛逛的按钮。这个状态是很多新手容易忽略的实际上线后用户很常见。4.4 下单与微信支付流程下单的流程是购物车选中商品 → 进入确认订单页 → 选择收货地址 → 填写备注 → 点击提交 → 创建订单 → 发起支付 → 支付成功 → 回到订单列表。微信支付在当前项目里的具体实现后端调用微信支付统一下单接口拿到prepay_id后端根据prepay_id生成支付参数timeStamp、nonceStr、package、signType、paySign返回给前端前端调用uni.requestPayment传入支付参数用户在微信内完成支付微信服务器把支付结果回调到后端配置的回调URL// pages/order/confirm.vue 核心支付代码 const res await request({ url: /api/order/pay, method: POST, data: { orderNo: this.orderNo } }) if (res.code 0) { const payParams res.data uni.requestPayment({ provider: wxpay, timeStamp: payParams.timeStamp, nonceStr: payParams.nonceStr, package: payParams.package, signType: MD5, paySign: payParams.paySign, success: (res2) { uni.showToast({ title: 支付成功, icon: success }) setTimeout(() { uni.redirectTo({ url: /pages/order/list?status1 }) }, 1500) }, fail: (err) { uni.showToast({ title: 支付取消, icon: none }) } }) }支付这块有个大坑个人主体的小程序无法开通微信支付必须是企业主体、个体工商户主体才能申请。如果只是做毕设演示可以用“模拟支付”——前端点支付时直接调一个/api/order/mockPay接口后端把订单状态改成“待发货”。答辩时说明这是演示环境的模拟支付正式环境接入微信支付即可。千万不要在毕设演示时真去用一个没有资质的小程序调支付审核过不了演示也尴尬。4.5 订单列表与个人中心订单列表按状态筛选全部、待付款、待发货、待收货、待评价。每个tab对应一个订单状态值界面用scroll-view做横向tab滚动列表本身用onReachBottom做分页加载。个人中心需要展示用户头像、昵称、订单入口、收货地址入口、售后入口。数据来源有两个本地Storage里的用户信息缓存 后端/api/user/info接口。头像和昵称在微信小程序里获取有改版从wx.getUserProfile改成头像昵称填写能力很多老教程还在用旧API照抄会拿不到数据。实际操作里个人中心的头像可以用button的open-typechooseAvatar实现昵称用input的typenickname实现这是目前微信官方推荐的做法。5. 常见问题与排查技巧实录5.1 request:fail url not in domain list这是新手最容易遇到的报错意思是请求的域名没有在小程序后台配置为合法域名。解决方法是到微信公众平台 → 开发管理 → 开发设置 → 服务器域名里把接口域名配置到request合法域名里。开发阶段有个临时办法在微信开发者工具里勾选“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”这样本地调试可以绕过域名校验。但注意这个选项只对开发者工具生效真机预览时必须配好合法域名否则接口全部失败。另一个容易忽略的点开发阶段用http://localhost或者http://192.168.x.x调试接口换真机预览时发现连不上因为你的手机和电脑不在同一个局域网或者防火墙没放行端口。解决办法是让手机和电脑连同一个WiFi用电脑的局域网IP作为接口地址。5.2 安全区域与底部小黑条适配iPhone从X开始有底部小黑条Home Indicator页面底部如果有“提交订单”“立即支付”这类吸底按钮会被小黑条遮住一部分。解决办法是给吸底按钮容器加上安全区适配.safe-bottom { padding-bottom: constant(safe-area-inset-bottom); /* iOS 11.0 */ padding-bottom: env(safe-area-inset-bottom); /* iOS 11.2 */ }uni-app里更简单的方案是在pages.json的app-plus节点下配置safearea或者在页面上直接用uni.getSystemInfoSync()拿到safeAreaInsets动态计算底部高度。5.3 商品数据量大的列表渲染优化购物平台商品列表动辄几百上千条一次性渲染会卡顿。常规优化手段有3个分页加载控制每次渲染10-20条图片懒加载image组件加lazy-load属性使用uni.createSelectorQuery监听滚动到指定位置时再渲染可视区内容类似虚拟列表分页是首要手段简单有效。图片懒加载是默认必须开的。虚拟列表在数据量超过100条时再考虑毕设级别用分页就够。5.4 原生组件层级遮挡问题微信小程序里canvas、video、map这类原生组件层级最高会覆盖普通view组件。购物平台里如果商品详情页用了video底部的加购栏会被视频盖住。旧方案的解决办法是用cover-view包裹底部按钮或者把视频封装进一个容器里设置同层渲染属性。新版本微信基础库已经默认同层渲染但遇到层级问题时要第一时间想到是原生组件在捣鬼。5.5 Token过期与登录态丢失Token的过期策略一般是2小时或7天。过期后请求会返回401。前端的处理方式是清掉本地Token和用户信息跳登录页同时给用户一个toast提示“登录已过期请重新登录”。如果用户正在填写购物车跳走之后数据会丢。更人性化的做法是弹出一个Modal提示登录过期给用户两个按钮“重新登录”和“取消”取消则停留在当前页面重新登录成功后回到原页面。这个功能的实现不复杂但很加分答辩时可以提一下。5.6 真机调试时白屏白屏是最让人头大的问题。我遇到过的原因按概率排序接口域名没配好请求全部失败页面JS报错错误被吞了在onLoad里异步抛错工具不提示使用了不兼容的CSS属性在某些安卓机型上渲染异常内存不足图片太多导致webview崩溃排查白屏的第一步看微信开发者工具的Console面板有没有红字报错。没有报错的话逐步注释页面代码定位问题区域。这个方法虽然土但极其有效。真机白屏还有一个杀手锏关掉“自动预览”用“真机调试”模式能看到真机上的Console日志。6. 项目扩展方向购物平台做完基础版之后其实可扩展的方向很多。我建议按优先级考虑SKU多维规格颜色、尺码、优惠券系统、秒杀活动、会员积分、售后申请、商品评价体系。这些功能在电商场景里都是闭环的加一个功能就能让项目的完整度和亮点上一个台阶。如果做毕业设计我推荐加“优惠券”和“商品评价”因为这俩在答辩时最好讲优惠券涉及库存、有效期、满减规则这些业务逻辑评价涉及图片上传和审核状态都有清晰的技术难点可以展开。7. 个人经验与实操感受最后分享几个最实际的体会。组件库不要贪多平时用原生view写写样式也是一种锻炼。我认识很多人一开始就引入全套uView写起来舒服了但对底层组件的工作原理其实很模糊一旦遇到自定义样式需求就卡壳。建议从简单页面纯手写样式开始UI库只用在复杂组件场景。调试阶段多用console.log少猜。我见过太多人报错不先看控制台而是直接查“xx报错怎么办”其实很多问题看第一行报错信息就能知道答案。console.log调试法虽然原始但在小程序开发里依然是最可靠的定位手段。项目做完之后花一天时间把所有接口和页面过一遍把兼容性问题、状态转换关系整理成文档。这份东西毕业设计答辩时是加分项工作面试时也能证明你有整理和复盘的习惯。如果你还打算继续优化建议从订单模块的并发处理入手这是购物平台最容易出技术深度的地方。做这个项目的过程中我最深的感受是看似普通的购物平台涉及的要点一点不少从跨端框架到微信生态限制从数据状态管理到支付回调联动每一个环节都在逼你“知其然还知其所以然”。把这个项目真正跑通你学到的不仅是小程序开发更是完整的业务系统设计思路。
做毕设或者个人练手项目的时候一说到“购物平台”十个人里有八个都选微信小程序。原因很简单微信有流量、有生态小程序开发门槛又不高做完还能直接用手机扫一扫演示比纯Web页面有说服力多了。但如果真动手去做你会发现从注册AppID、搭项目、写接口到审核上线每一步都有坑。“基于uni-app的在线购物平台”这个题目听起来像烂大街的毕设题目实际上把它做扎实了含金量并不低。这期就把我完整做过的这套uni-app购物小程序的全过程拆开聊。内容覆盖技术选型、目录结构、核心页面、后端接口、数据库设计、支付流程、常见报错不整虚的都是能直接上手的实操方案。无论你是拿它做毕业设计、课程设计还是单纯想学小程序开发这篇文章都能少走不少弯路。1. 项目整体设计与技术选型思路1.1 为什么选uni-app而不是原生小程序选uni-app做跨端购物小程序核心原因就三个一套代码多端复用、Vue语法上手快、插件生态省事。原生微信小程序用的是WXMLWXSSJS那一套虽然也简单但写完之后你会发现同样的业务逻辑换个端就得重写。比如你做完微信小程序想再出一版支付宝小程序、抖音小程序原生写法基本是推倒重来。uni-app基于Vue语法编译时通过条件编译把代码分发到不同平台业务层只需要维护一套这个优势在项目后期特别明显。对于购物类项目来说uni-app还有一个隐藏优势它的API封装粒度更接近业务。比如选择收货地址原生需要调用wx.chooseAddress换到支付宝端要改成my.chooseAddress在uni-app里统一成uni.chooseAddress内部自动做平台转换。这个封装层省掉的不是几行代码而是跨端适配时的排查时间。当然原生小程序也有它的价值包体更小、运行时有更强的平台能力调优空间性能敏感型应用可以考虑。但购物平台这种以业务逻辑为主的场景性能瓶颈在图片、列表、接口响应上跟用的是不是原生关系不大。uni-app的损耗在可接受范围内换取的是开发效率和维护成本的大幅降低。1.2 购物平台的模块边界划分一个完整的在线购物系统从功能模块上可以拆成两个端C端用户小程序和B端管理后台。小程序端面向消费者核心模块包括首页、分类、购物车、订单、个人中心五大Tab再往下拆是商品详情、搜索、下单结算、支付、收货地址、售后等二级页面。管理后台面向运营者负责商品上下架、分类管理、订单处理、库存维护、数据统计。做毕设时很多人会忽略一件事管理后台的复杂度往往比小程序端还高。你可以用uni-app再做一套管理端也可以直接用Vue Element UI做一套Web管理后台甚至为了演示方便做成一个内嵌在小程序里的管理员页面。我的建议是尽量前后端分离、管理端独立部署这样技术难点展示得更充分答辩或汇报时也更有说头。两个端共用同一套后端API通过角色权限做区分。用户在登录时带上身份标识比如role字段后端根据角色决定接口返回的数据量级和操作权限。这样设计的好处是数据模型统一商品、订单、用户这些核心表不需要做双份。1.3 技术栈选型与版本取舍前端框架uni-appVue 3语法HBuilderX 3.x及以上版本直接支持状态管理Vuex项目不大时Pinia也可以但uni-app对Pinia的支持目前还不算特别稳UI组件库uView Plus 或 uni-ui两者二选一即可不要混用后端PHPThinkPHP框架、Node.jsExpress/Koa或 JavaSpring Boot任选一个你熟悉的。PHP和Node在毕设里最常用Spring Boot适合写进简历数据库MySQL 5.7及以上表结构以订单、商品、用户为核心接口风格RESTful API返回JSON数据登录鉴权用JWT Token这里有个切身体会选UI组件库时不要贪多。uView Plus虽然组件全、颜值高但引入方式要注意否则会跟uni-app自带的样式起冲突。我一个朋友就是全量引入uView之后原生button的默认样式被改得乱七八糟排查了半天。建议按需引入或只引入UI组件不要全量导入CSS。2. 前端核心细节与实操要点2.1 项目初始化与三个核心配置文件的职责用HBuilderX创建uni-app项目在“文件 - 新建 - 项目”里选择“uni-app”模板输入项目名称即可。生成目录后必须处理好三个文件这是整个小程序的“地基”。pages.json是页面路由和窗口样式的总配置文件相当于原生小程序的app.json。所有页面都要在pages数组里注册tabBar里配置底部导航。这里有个常被忽略的点tabBar页面必须放在pages数组的前几项而且tabBar.list最多只能配置5个超出会直接编译报错。manifest.json配置应用名称、AppID、组件库版本。微信小程序AppID在微信公众平台注册后获取测试时可以先用测试号。特别注意mp-weixin节点下的appid字段很多人把AppID填到了mp-alipay或其它平台结果运行到微信时还是提示AppID无效。App.vue是整个应用的根组件应用生命周期onLaunch在这里触发适合做全局登录检查、检查更新、初始化全局数据等操作。但要注意App.vue里的onLaunch在冷启动时执行异步请求不要写得太重否则会影响首页首屏渲染速度。2.2 顶部导航栏与iPhone刘海屏适配“微信小程序顶部导航栏高度”这个搜索词的点击量一直不低就是因为自定义导航时不同机型的状态栏高度不一致导致导航栏布局错乱。默认导航栏用原生渲染不需要考虑适配。但很多购物平台为了视觉统一会选择自定义导航栏把pages.json里页面的navigationStyle设为custom然后自己在页面顶部画一个导航条。自定义导航时状态栏高度需要动态获取// utils/system.js export function getStatusBarHeight() { // 注意uni.getSystemInfoSync是同步方法可以安全在onLoad里调用 const systemInfo uni.getSystemInfoSync() return systemInfo.statusBarHeight || 20 } export function getMenuButtonBoundingClientRect() { // 胶囊按钮位置只在微信小程序中有效 // #ifdef MP-WEIXIN const menuButtonInfo uni.getMenuButtonBoundingClientRect() return menuButtonInfo // #endif // 非微信环境给个兜底值 return { top: 20, height: 30 } }拿到状态栏高度和胶囊按钮位置后导航栏高度 状态栏高度 胶囊按钮高度 胶囊按钮上下间距 × 2。这个公式在自定义导航时通用能精确计算出导航栏的实际高度避免内容被刘海遮挡或导航栏偏矮。2.3 请求封装与登录态管理购物平台的每个用户操作基本都要带登录态所以请求封装是第一优先级。我的做法是在utils/request.js里封装一个基于Promise的request函数统一处理baseURL、请求头、Token注入、状态码拦截、错误提示。// utils/request.js const BASE_URL https://你的服务器域名.com export function request({ url, method GET, data {}, needAuth true }) { return new Promise((resolve, reject) { const token uni.getStorageSync(token) const header { Content-Type: application/json } if (needAuth token) header[Authorization] Bearer ${token} uni.request({ url: BASE_URL url, method, data, header, success: (res) { if (res.statusCode 401) { // Token过期或无效清除本地登录态并跳转登录 uni.removeStorageSync(token) uni.removeStorageSync(userInfo) uni.navigateTo({ url: /pages/login/login }) return } if (res.statusCode 200 res.statusCode 300) { resolve(res.data) } else { uni.showToast({ title: res.data.msg || 请求失败, icon: none }) reject(res.data) } }, fail: (err) { uni.showToast({ title: 网络异常, icon: none }) reject(err) } }) }) }登录流程走的是微信登录小程序端调用uni.login拿临时code把code发给后端后端拿着code向微信接口换取openid和session_key再签发自己的JWT Token返回给前端。前端把Token存入Storage后续请求自动带上。这里有一个非常容易踩的坑code只能用一次换完openid就失效所以不能让前端反复提交同一个code。调试时遇到“40029 code无效”报错八成是这里的问题。2.4 商品列表与购物车状态管理购物车是典型的跨页面共享数据场景。首页点“加入购物车”购物车页面要立即显示最新数量和金额中间如果只靠onShow重新拉接口体验会慢半拍而且还要处理并发。用Vuex管理购物车数据是最合理的方案。我在store/modules/cart.js里维护购物车列表、选中状态、总金额三个核心状态const state { cartList: [], // [{ goodsId, goodsName, price, count, checked }] checkedGoods: [], // 选中的商品项 } const getters { cartTotal(state) { return state.cartList.reduce((total, item) total item.count, 0) }, checkedTotalPrice(state) { return state.cartList .filter(item item.checked) .reduce((total, item) total item.price * item.count, 0) } }所有修改购物车的操作通过mutations同步修改比如ADD_TO_CART、TOGGLE_CHECKED、UPDATE_COUNT、DELETE_ITEM。组件内部computed里用mapGetters映射cartTotal和checkedTotalPrice这样不管在哪个页面修改了购物车所有引用的页面都会自动更新。这个方案有一个好处用户从购物车进结算页时不需要再次请求接口直接用内存里的数据就能拼出订单预览速度快、体验好。缺点也很明显如果用户同时在多端操作购物车本地状态会和服务端不一致。解决办法是加购、删购时同步调接口但页面展示以本地Vuex为主以后端返回为准形成“本地优先、后端兜底”的同步策略。2.5 全局弹窗组件封装思路官方uni.showToast确实只支持文本和icon自定义程度低。如果想让弹窗支持图片、按钮、自定义插槽最简单的方案是自己封装一个全局弹窗组件。我之前写过一个轻量的customToast组件核心思路是在components目录里建一个popup-dialog组件组件内部用uni.showModal的样式做基础但内容用slot自定义。再用一个全局的uni.$emit事件机制触发弹窗。template view v-ifvisible classpopup-wrapper view classmask clickonClose/view view classpopup-content slot namecontent/slot view classbtn-group button clickonCancel取消/button button typeprimary clickonConfirm确定/button /view /view /view /template script export default { name: CustomPopup, data() { return { visible: false } }, methods: { open(config) { this.visible true // config里可以传 title, content, confirmText等 }, close() { this.visible false } } } /script封装好了在需要弹窗的页面里引入一次通过uni.$emit(open-popup, {...})即可唤起。这样比每个页面单独写一套弹窗逻辑省事得多样式也统一。需要注意弹窗组件的visible状态要记得在页面卸载时重置否则从A页跳到B页再返回弹窗可能还在。我就是踩过一次这个坑后来在onUnload里补了一个close处理。3. 后端接口设计与数据库实现3.1 数据库核心表结构设计购物平台的数据表设计是整个系统的重心。表结构设计得合理后面写接口、做统计都会很顺畅设计不合理订单和库存对不上、退款状态混乱是你后期debug最痛苦的事情。我的核心表一共7张用户表、商品表、商品分类表、购物车表、订单表、订单商品表、收货地址表。订单表与订单商品表分离是为了支持一个订单包含多个商品多商品合并结算场景如果一张订单只对应一个商品那订单商品表可以直接并入订单表。用户表 user字段名类型说明idint主键自增openidvarchar(64)微信openid唯一索引nicknamevarchar(50)昵称avatarvarchar(255)头像URLphonevarchar(20)手机号选填roletinyint角色0普通用户1管理员create_timedatetime注册时间商品表 goods字段名类型说明idint主键category_idint分类ID关联分类表titlevarchar(100)商品标题subtitlevarchar(200)商品副标题main_imagevarchar(255)主图URLimagestext商品轮播图JSON数组存储pricedecimal(10,2)售价original_pricedecimal(10,2)原价划线价stockint库存salesint销量detailtext富文本或图文详情statustinyint状态0下架1上架create_timedatetime创建时间订单表 order字段名类型说明idint主键order_novarchar(32)订单号唯一索引user_idint用户IDtotal_pricedecimal(10,2)订单总金额pay_pricedecimal(10,2)实付金额pay_typetinyint支付方式1微信支付statustinyint订单状态见下方状态机address_idint收货地址IDtransaction_idvarchar(64)微信支付交易号remarkvarchar(255)用户备注create_timedatetime下单时间pay_timedatetime支付时间ship_timedatetime发货时间finish_timedatetime完成时间订单号生成建议用date(YmdHis) rand(1000,9999)这种格式或者直接用年月日时分秒用户ID后四位保证可读性和唯一性。不要用自增ID直接当订单号会被用户猜到订单规模。3.2 接口清单与RESTful规范接口按模块划分统一返回格式为{ code, msg, data }成功时code为0失败时为错误码。RESTful风格上列表用GET新增用POST更新用PUT/PATCH删除用DELETE。用户模块POST /api/auth/login微信登录参数code返回token和用户信息GET /api/user/info获取用户信息请求头带TokenPUT /api/user/info更新用户资料商品模块GET /api/goods/list商品列表参数keyword、categoryId、page、pageSize、sortByGET /api/goods/detail商品详情参数goodsIdGET /api/category/list分类列表购物车模块GET /api/cart/list获取购物车列表POST /api/cart/add加入购物车参数goodsId、countPUT /api/cart/update修改购物车数量或选中状态DELETE /api/cart/remove删除购物车条目订单模块POST /api/order/create创建订单参数addressId、goodsList、remarkPOST /api/order/pay发起支付参数orderNoGET /api/order/list订单列表参数status0全部1待付款等GET /api/order/detail订单详情参数orderNoPOST /api/order/cancel取消订单POST /api/order/confirm确认收货接口的鉴权策略很简单除登录和商品列表、详情外其他接口都要求请求头携带Authorization: Bearer token。后端在Controller里写一个基础类的checkAuth方法每个需要鉴权的接口先调这个方法减少重复代码。3.3 后端登录接口实现PHP示例用PHP写登录接口思路很直观。拿前端的code调微信官方接口换openid然后查库决定是登录还是自动注册。// Api/AuthController.php public function login(Request $request) { $code $request-post(code); $appid 你的小程序AppID; $secret 你的小程序AppSecret; // 向微信服务器换取 openid $url https://api.weixin.qq.com/sns/jscode2session?appid{$appid}secret{$secret}js_code{$code}grant_typeauthorization_code; $result file_get_contents($url); $result json_decode($result, true); if (isset($result[errcode])) { return json([code 500, msg 登录失败]); } $openid $result[openid]; // 查询用户不存在则自动注册 $user Db::name(user)-where(openid, $openid)-find(); if (!$user) { $userId Db::name(user)-insertGetId([ openid $openid, nickname 微信用户 . mt_rand(10000, 99999), create_time date(Y-m-d H:i:s) ]); } else { $userId $user[id]; } // 生成Token这里用简单的md5拼接生产环境建议用JWT $token md5($openid . time() . mt_rand(1000, 9999)); Db::name(user_token)-insert([ user_id $userId, token $token, expire_time date(Y-m-d H:i:s, time() 7200) ]); return json([code 0, data [token $token, userInfo $user]]); }注意file_get_contents拉远程接口在开发环境没问题但生产环境有的服务器禁用了allow_url_fopen就调用失败。更稳妥的方式是用cURL封装或者用ThinkPHP自带的Http类。另外一个调试技巧微信的jscode2session接口在开发者工具里能正常返回但真机预览时报invalid code很可能是AppID配错了检查manifest.json里是不是填的AppID和后端secret对应的是同一个小程序。3.4 订单状态机设计订单状态是购物平台最容易写乱的模块。我建议把状态定义写在接口文档和维护手册的第一页前后端统一下来。状态值状态含义前端按钮展示用户可执行操作0待付款去支付、取消订单继续支付 / 关闭订单1待发货提醒发货申请退款2待收货查看物流、确认收货确认收货3待评价去评价发表评价4已完成查看详情再次购买5已关闭删除订单删除6退款中查看进度撤销申请这里有个容易漏掉的状态用户付款后、商家发货前订单是“待发货”状态商家发货后、用户确认收货前是“待收货”状态。两者在用户侧看起来都是已付款但后端逻辑不同待发货时用户可申请退款待发货状态商家可发货。我在做第一次版本时把这两个状态合并了导致用户付款后直接看到“确认收货”按钮点下去商家还没发货订单就完成了场面一度很尴尬。后来才把状态细分建模。4. 实操过程从零搭建购物平台的完整流程4.1 HBuilderX创建项目并运行到微信开发者工具首次用HBuilderX开发微信小程序需要先把运行环境配置好关键两步微信开发者工具的安全设置里开启“服务端口”HBuilderX才能自动拉起小程序。打开HBuilderX新建项目选择“uni-app”模板在manifest.json的mp-weixin节点填入微信小程序的AppID菜单栏“运行 - 运行到小程序模拟器 - 微信开发者工具”首次运行会在微信开发者工具中自动打开项目后续代码保存会自动同步编译这个阶段经常遇到的报错是“HBuilderX连接微信开发者工具失败”原因基本是微信开发者工具没有开启服务端口。解决路径微信开发者工具 → 设置 → 安全设置 → 打开“服务端口”。另一个报错是“appid为空”检查manifest.json里的配置是否正确测试阶段可以填测试号AppID但要注意测试号的接口权限有限wx.requestPayment这类支付接口没法完全测试。4.2 首页与商品详情页的实现要点首页是商品的门面一般由“搜索框 轮播图 分类金刚区 商品瀑布流”组成。轮播图和金刚区都是静态配置数据可以从后端接口拉取也可以直接在store里写死看项目需要。商品瀑布流用scroll-view配合触底加载分页每页拉10条或20条性能更好。商品列表的分页是高频考点。后端接口接收page和pageSize返回total、list、hasMore三个字段。前端用onReachBottom触发加载下一页判断hasMore为false时不再请求// pages/home/home.vue data() { return { goodsList: [], page: 1, pageSize: 10, hasMore: true, loading: false } }, methods: { async loadGoods(isRefresh false) { if (this.loading) return this.loading true const res await request({ url: /api/goods/list, data: { page: this.page, pageSize: this.pageSize } }) if (isRefresh) this.goodsList [] this.goodsList this.goodsList.concat(res.data.list) this.hasMore res.data.list.length this.pageSize this.page 1 this.loading false } }, onReachBottom() { if (this.hasMore) this.loadGoods() }商品详情页主要是展示和操作轮播图用swiper组件商品价格、库存、销量是静态渲染参数规格的展示可以先用纯文本列表加购按钮触发Vuex的ADD_TO_CARTmutation同时调后端购物车接口同步。这里有一个非常实用的交互细节加购成功后在按钮位置上弹一个小气泡动画体验提升明显。uni-app用uni.createAnimation就能实现不用引入额外库。4.3 购物车页面的全选、单选、金额计算与删除购物车页面的核心是数据联动单选/全选影响总金额数量增减影响总金额删除影响列表和总金额。这些都在Vuex里维护组件内部只需要调用mutation和getter。全选逻辑// store/modules/cart.js setAllChecked(state, checked) { state.cartList.forEach(item { item.checked checked }) }计算总金额const getters { totalPrice(state) { return state.cartList .filter(item item.checked) .reduce((sum, item) sum item.price * item.count, 0) .toFixed(2) } }删除时要注意和本地缓存的同步。如果购物车数据同时存在本地和Server端删除时先乐观更新本地Vuex再向Server发起删除请求失败时回滚。这种“乐观UI”策略能让界面响应更快但必须在失败时做好提示和回滚否则会出现“删了又出现”的笑话。购物车页面还有一个隐藏需求空状态。数据为空时要展示一个可爱的空车提示和一键去逛逛的按钮。这个状态是很多新手容易忽略的实际上线后用户很常见。4.4 下单与微信支付流程下单的流程是购物车选中商品 → 进入确认订单页 → 选择收货地址 → 填写备注 → 点击提交 → 创建订单 → 发起支付 → 支付成功 → 回到订单列表。微信支付在当前项目里的具体实现后端调用微信支付统一下单接口拿到prepay_id后端根据prepay_id生成支付参数timeStamp、nonceStr、package、signType、paySign返回给前端前端调用uni.requestPayment传入支付参数用户在微信内完成支付微信服务器把支付结果回调到后端配置的回调URL// pages/order/confirm.vue 核心支付代码 const res await request({ url: /api/order/pay, method: POST, data: { orderNo: this.orderNo } }) if (res.code 0) { const payParams res.data uni.requestPayment({ provider: wxpay, timeStamp: payParams.timeStamp, nonceStr: payParams.nonceStr, package: payParams.package, signType: MD5, paySign: payParams.paySign, success: (res2) { uni.showToast({ title: 支付成功, icon: success }) setTimeout(() { uni.redirectTo({ url: /pages/order/list?status1 }) }, 1500) }, fail: (err) { uni.showToast({ title: 支付取消, icon: none }) } }) }支付这块有个大坑个人主体的小程序无法开通微信支付必须是企业主体、个体工商户主体才能申请。如果只是做毕设演示可以用“模拟支付”——前端点支付时直接调一个/api/order/mockPay接口后端把订单状态改成“待发货”。答辩时说明这是演示环境的模拟支付正式环境接入微信支付即可。千万不要在毕设演示时真去用一个没有资质的小程序调支付审核过不了演示也尴尬。4.5 订单列表与个人中心订单列表按状态筛选全部、待付款、待发货、待收货、待评价。每个tab对应一个订单状态值界面用scroll-view做横向tab滚动列表本身用onReachBottom做分页加载。个人中心需要展示用户头像、昵称、订单入口、收货地址入口、售后入口。数据来源有两个本地Storage里的用户信息缓存 后端/api/user/info接口。头像和昵称在微信小程序里获取有改版从wx.getUserProfile改成头像昵称填写能力很多老教程还在用旧API照抄会拿不到数据。实际操作里个人中心的头像可以用button的open-typechooseAvatar实现昵称用input的typenickname实现这是目前微信官方推荐的做法。5. 常见问题与排查技巧实录5.1 request:fail url not in domain list这是新手最容易遇到的报错意思是请求的域名没有在小程序后台配置为合法域名。解决方法是到微信公众平台 → 开发管理 → 开发设置 → 服务器域名里把接口域名配置到request合法域名里。开发阶段有个临时办法在微信开发者工具里勾选“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”这样本地调试可以绕过域名校验。但注意这个选项只对开发者工具生效真机预览时必须配好合法域名否则接口全部失败。另一个容易忽略的点开发阶段用http://localhost或者http://192.168.x.x调试接口换真机预览时发现连不上因为你的手机和电脑不在同一个局域网或者防火墙没放行端口。解决办法是让手机和电脑连同一个WiFi用电脑的局域网IP作为接口地址。5.2 安全区域与底部小黑条适配iPhone从X开始有底部小黑条Home Indicator页面底部如果有“提交订单”“立即支付”这类吸底按钮会被小黑条遮住一部分。解决办法是给吸底按钮容器加上安全区适配.safe-bottom { padding-bottom: constant(safe-area-inset-bottom); /* iOS 11.0 */ padding-bottom: env(safe-area-inset-bottom); /* iOS 11.2 */ }uni-app里更简单的方案是在pages.json的app-plus节点下配置safearea或者在页面上直接用uni.getSystemInfoSync()拿到safeAreaInsets动态计算底部高度。5.3 商品数据量大的列表渲染优化购物平台商品列表动辄几百上千条一次性渲染会卡顿。常规优化手段有3个分页加载控制每次渲染10-20条图片懒加载image组件加lazy-load属性使用uni.createSelectorQuery监听滚动到指定位置时再渲染可视区内容类似虚拟列表分页是首要手段简单有效。图片懒加载是默认必须开的。虚拟列表在数据量超过100条时再考虑毕设级别用分页就够。5.4 原生组件层级遮挡问题微信小程序里canvas、video、map这类原生组件层级最高会覆盖普通view组件。购物平台里如果商品详情页用了video底部的加购栏会被视频盖住。旧方案的解决办法是用cover-view包裹底部按钮或者把视频封装进一个容器里设置同层渲染属性。新版本微信基础库已经默认同层渲染但遇到层级问题时要第一时间想到是原生组件在捣鬼。5.5 Token过期与登录态丢失Token的过期策略一般是2小时或7天。过期后请求会返回401。前端的处理方式是清掉本地Token和用户信息跳登录页同时给用户一个toast提示“登录已过期请重新登录”。如果用户正在填写购物车跳走之后数据会丢。更人性化的做法是弹出一个Modal提示登录过期给用户两个按钮“重新登录”和“取消”取消则停留在当前页面重新登录成功后回到原页面。这个功能的实现不复杂但很加分答辩时可以提一下。5.6 真机调试时白屏白屏是最让人头大的问题。我遇到过的原因按概率排序接口域名没配好请求全部失败页面JS报错错误被吞了在onLoad里异步抛错工具不提示使用了不兼容的CSS属性在某些安卓机型上渲染异常内存不足图片太多导致webview崩溃排查白屏的第一步看微信开发者工具的Console面板有没有红字报错。没有报错的话逐步注释页面代码定位问题区域。这个方法虽然土但极其有效。真机白屏还有一个杀手锏关掉“自动预览”用“真机调试”模式能看到真机上的Console日志。6. 项目扩展方向购物平台做完基础版之后其实可扩展的方向很多。我建议按优先级考虑SKU多维规格颜色、尺码、优惠券系统、秒杀活动、会员积分、售后申请、商品评价体系。这些功能在电商场景里都是闭环的加一个功能就能让项目的完整度和亮点上一个台阶。如果做毕业设计我推荐加“优惠券”和“商品评价”因为这俩在答辩时最好讲优惠券涉及库存、有效期、满减规则这些业务逻辑评价涉及图片上传和审核状态都有清晰的技术难点可以展开。7. 个人经验与实操感受最后分享几个最实际的体会。组件库不要贪多平时用原生view写写样式也是一种锻炼。我认识很多人一开始就引入全套uView写起来舒服了但对底层组件的工作原理其实很模糊一旦遇到自定义样式需求就卡壳。建议从简单页面纯手写样式开始UI库只用在复杂组件场景。调试阶段多用console.log少猜。我见过太多人报错不先看控制台而是直接查“xx报错怎么办”其实很多问题看第一行报错信息就能知道答案。console.log调试法虽然原始但在小程序开发里依然是最可靠的定位手段。项目做完之后花一天时间把所有接口和页面过一遍把兼容性问题、状态转换关系整理成文档。这份东西毕业设计答辩时是加分项工作面试时也能证明你有整理和复盘的习惯。如果你还打算继续优化建议从订单模块的并发处理入手这是购物平台最容易出技术深度的地方。做这个项目的过程中我最深的感受是看似普通的购物平台涉及的要点一点不少从跨端框架到微信生态限制从数据状态管理到支付回调联动每一个环节都在逼你“知其然还知其所以然”。把这个项目真正跑通你学到的不仅是小程序开发更是完整的业务系统设计思路。
