十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

基于uniapp的宠物寄养微信小程序开发实践与踩坑总结

基于uniapp的宠物寄养微信小程序开发实践与踩坑总结 最近接了个宠物寄养托管的小程序项目需求很典型宠物主人出远门的时候需要找附近靠谱的寄养门店或家庭寄养师门店则要管理寄养订单、记录每天的喂养和遛狗情况。整个项目用 uniapp vue 开发成微信小程序从需求梳理到上线折腾了一个多月。今天把这套系统的设计思路、核心实现和踩坑记录整理出来给准备做同类型项目的朋友一份可以照着抄的参考。这套系统解决的核心痛点很直接宠物寄养市场里主人最怕的就是“把宠物送出去之后完全失联”门店最烦的则是“订单靠手写、排期靠脑子、反馈靠微信聊天”。所以小程序端一开始就不是简单搞个展示页而是围绕“预订—接单—照料—反馈—评价”这条完整链路设计。如果你是学生做毕业设计或者中小团队接外包单子又或者想在本地做宠物服务的小程序创业这套思路都能直接复用。1. 这个宠物寄养项目到底要做什么1.1 寄养场景下的核心角色与业务闭环宠物寄养和普通商品电商有个很大的区别它卖的是“一段时间的照料服务”不是标品。这意味着系统里必须同时服务两类角色而且两类角色的诉求差异很大。宠物主人C端用户关心的是附近有哪些寄养门店、门店环境怎么样、价格多少、有没有空位、我家宠物送过去之后每天吃什么、精神状态好不好、能不能随时看到照片和视频。寄养门店B端商家关心的是订单别排重了、每只宠物有什么忌口和习惯、每天该喂什么粮、该几点遛、寄养结束后怎么结算、怎么让主人愿意给好评。所以在功能设计上我没有按传统的“用户端管理后台”两层去做而是拆成了三个端口小程序用户端、小程序商家端同一套代码里做角色切换、运营管理后台Web端方便总览所有订单和门店数据。三个端口共用同一套接口服务数据结构从一开始就按“门店-宠物-订单-日志”这四个核心实体建模。1.2 技术栈选型uniapp vue 解决什么问题如果只做微信小程序用原生小程序语法完全够。但这个项目的甲方当时已经有明确预期后续可能要上支付宝小程序甚至做成 App。如果原生写一套微信小程序后面换端就得重写。所以技术选型直接锁定了 uniapp vue。用 uniapp 的好处字面上是“一套代码多端运行”但实际开发中体会更深的是另一件事它的生命周期和 API 设计对 vue 开发者非常友好。你写页面还是 vue 单文件组件那套模板、脚本、样式分离逻辑层还是用 vuex/pinia 管理状态只是把v-if里的点击跳转从this.$router.push换成了uni.navigateTo把 axios 换成了uni.request的封装。学习成本很低基本是“vue 会了 uniapp 就会一半”。再一个实用的理由是生态。HBuilderX 直接内置了微信小程序打包、App 云打包manifest.json 里配置好微信小程序的 AppID 就能一键发行。对于没有 iOS 证书、又不想折腾 Android 打包环境的小团队来说这个省下来的时间非常可观。后面我会专门讲打包细节。1.3 功能清单拆解从预约到评价的全链路这套系统的功能模块我按“用户端—商家端—公共能力”三块来拆。用户端核心功能有这几个首页寄养门店列表、轮播banner、附近门店推荐、服务分类入口门店详情环境照片、服务项目、价格、档期日历、用户评价宠物档案宠物照片、品种、年龄、体重、疫苗记录、忌口与习惯备注下单流程选择门店、选择开始/结束日期、选择宠物、填写备注、支付定金或全款寄养动态实时查看寄养日志图文、喂养记录、遛狗记录个人中心订单列表、宠物档案管理、收藏、优惠券、售后商家端核心功能工作台今日待接单、进行中订单、即将到店提醒订单管理接单/拒单、改价、确认入住、确认离店寄养日志录入按日期填写喂养记录、拍照上传、状态标记门店设置服务项目、价格、档期、环境照片、公告公共能力包括微信登录、手机号授权、消息订阅推送、支付/退款回调、图片上传与压缩、地图定位与门店距离计算。这套功能列表看着多但真正难的不是某个页面而是“订单状态机”和“档期冲突检测”这两个后端逻辑。前端小程序要做好的是让用户在每一步都清楚当前订单在什么状态以及把日志反馈的体验做得足够顺滑。2. 从零搭建 uniapp 工程2.1 开发环境准备HBuilderX、微信开发者工具、Node这个项目用的是 HBuilderX 作为主 IDE原因很简单uniapp 官方对 HBuilderX 的集成最完整新建项目、运行、打包、云打包、manifest 可视化配置都是开箱即用的。相比用 CLI 方式创建 uniapp 工程HBuilderX 可视化运行到微信开发者工具的点击流程更直接对团队里经验没那么足的同学更友好。环境准备这几样缺一不可HBuilderX 最新稳定版。注意下载正式版Alpha 版有时候会有插件兼容问题微信开发者工具并在设置里开启“服务端口”否则 HBuilderX 无法自动打开调试Node.js 14 以上版本虽然 HBuilderX 内置了运行环境但安装依赖、跑一些辅助脚本时会用到微信小程序已注册的 AppID。没有的话可以用测试号但测试号拿不到手机号授权和订阅消息的完整能力这些都是基本功但我在这个项目里遇到的一个小坑是HBuilderX 运行到微信开发者工具时如果微信工具没有开启服务端口会一直卡在“正在启动”的状态。所以建议先把开发者工具打开并在安全设置里把服务端口打开再让 HBuilderX 去拉起成功率会高很多。2.2 创建项目与 manifest/pages 配置HBuilderX 新建项目时选“默认模板”即可然后改造整个目录。创建完之后最先要改的是 manifest.json这里配置的是小程序的 AppID、项目名称、权限声明。manifest.json 里有几个重点配置项贴一下我实际用的内容{ name: 宠物寄养托管, appid: __UNI__XXXXXXX, vueVersion: 3, mp-weixin: { appid: wx你的小程序AppID, setting: { urlCheck: false, es6: true, postcss: true, minified: true }, usingComponents: true, permission: { scope.userLocation: { desc: 用于查找附近的寄养门店 } }, requiredPrivateInfos: [getLocation, chooseLocation] } }注意requiredPrivateInfos一定要配置否则真机上调用uni.getLocation和uni.chooseLocation会直接报错。我做的时候先漏了chooseLocation结果门店地址选择功能在开发者工具一切正常真机一点就崩后来查官方文档才发现 2023 年之后这类隐私接口必须在这里显式声明。这个坑非常典型后面踩坑章节我会再强调。pages.json 是路由和页面配置的核心。首页和 tabBar 页面要提前规划好我实际项目里 tabBar 配了三个首页、订单列表、我的。寄养相关的子页面都走uni.navigateTo跳转不占 tabBar。{ pages: [ { path: pages/index/index, style: { navigationBarTitleText: 宠物寄养 } }, { path: pages/hotel/detail, style: { navigationBarTitleText: 门店详情 } } ], tabBar: { color: #999999, selectedColor: #3c7cff, list: [ { pagePath: pages/index/index, text: 首页 }, { pagePath: pages/order/list, text: 订单 }, { pagePath: pages/user/index, text: 我的 } ] } }有一点想提醒微信小程序的页面顶部导航栏高度不是固定的不同机型上胶囊按钮位置不一样。如果你的页面要自定义导航栏建议用uni.getSystemInfoSync()里的statusBarHeight和menuButton信息做动态计算不要写死高度。这个项目里我用的还是默认导航栏省了一堆适配工作量但如果你设计稿要求沉浸式导航这个计算逻辑是绕不开的。2.3 工程目录规划与全局请求封装工程目录一开始就规划好后期维护会轻松很多。我习惯这样组织├── pages/ # 页面 │ ├── index/ # 首页 │ ├── hotel/ # 门店 │ ├── pet/ # 宠物档案 │ ├── order/ # 订单 │ └── user/ # 我的 ├── components/ # 公共组件 ├── store/ # pinia 状态管理 ├── static/ # 静态资源 ├── utils/ # 工具函数 ├── api/ # 接口请求模块 ├── App.vue ├── main.js ├── manifest.json └── pages.json全局请求封装这块我单独提一下因为很多新手项目都是每页写一遍uni.request到后面改个 base URL 都想哭。我是抽了一个utils/request.js统一处理 baseURL、请求头、token 注入、超时和错误提示。const BASE_URL https://api.example.com export function request(options) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, timeout: 10000, header: { Content-Type: application/json, Authorization: uni.getStorageSync(token) || }, success: (res) { if (res.statusCode 200 res.statusCode 300) { resolve(res.data) } else if (res.statusCode 401) { uni.navigateTo({ url: /pages/user/login }) reject(res) } else { uni.showToast({ title: res.data.message || 请求错误, icon: none }) reject(res) } }, fail: (err) { uni.showToast({ title: 网络异常请稍后重试, icon: none }) reject(err) } }) }) }token 失效时跳转登录页这个逻辑一定要放在封装层不要在业务页面里反复写。另外每个接口模块都单独建文件比如api/hotel.js、api/order.js、api/pet.js这样页面里引用非常清晰。// api/order.js import { request } from ../utils/request export const getOrderList (params) request({ url: /order/list, method: GET, data: params }) export const createOrder (data) request({ url: /order/create, method: POST, data })3. 核心模块的逐个落地3.1 首页服务展示与寄养门店列表首页是这个项目的门面也是用户第一次进入小程序后决定“要不要留下”的关键页面。我在布局上用了几块内容顶部搜索框、轮播banner、快捷入口寄养/遛狗/洗澡/美容、附近门店推荐列表。门店列表要支持按距离或评分排序距离这就要使用uni.getLocation获取经纬度传给后端计算距离。这个过程中需要注意拿到定位后最好存一次缓存不要让每次进入首页都弹授权框。因为微信对隐私授权的弹窗频率有限制频繁弹容易让用户反感还可能导致账号被平台侧标记。门店卡片我用了列表而不是 swiper因为门店数量多时 swiper 竖向滑动体验并不好。列表项展示门店封面、名称、评分、距离、服务标签“可接猫”“可接狗”“24小时监控”、当前是否有空位。这些字段后端一次返回前端不要为了一个距离字段再做二次请求。分类快捷入口我用了一个 grid 布局四个图标分别是“宠物寄养”“上门喂养”“宠物美容”“宠物托运”。看起来只是入口但我没有做死跳转而是给后端传分类参数这样以后新增分类不需要发版。3.2 宠物档案照片、疫苗、生活习性的管理宠物档案是寄养场景里的基础数据。寄养门店在接单时必须知道这只宠物的基本情况否则不敢随便接。所以这个模块不能做成简单的“名字照片”一定要覆盖寄养需要的信息。我的表单字段设计是宠物照片最多3张、昵称、品种、性别、是否绝育、出生日期、体重、疫苗是否齐全、性格标签活泼/胆小/护食/粘人、饮食习惯备注比如“只吃皇家奶糕一天两顿”、健康问题备注比如“心脏不好不能剧烈运动”。照片上传用的是uni.chooseImageuni.uploadFile这里有一个很实用的细节用户选择的图片先用 canvas 压缩到宽 1080 以内再上传避免原图过大导致上传慢。小程序端uni.chooseImage返回的临时文件路径可以直接给uni.compressImage做压缩。uni.chooseImage({ count: 3, success: (res) { const tempFilePath res.tempFilePaths[0] uni.compressImage({ src: tempFilePath, quality: 80, success: (compressRes) { uni.uploadFile({ url: BASE_URL /pet/upload, filePath: compressRes.tempFilePath, name: file, success: (uploadRes) { // 拿到图片 URL拼接宠物档案数据 } }) } }) } })这个压缩策略很重要我后面踩坑章节会放一个真实案例有个门店一口气传了 6 张猫舍照片每张 7MB结果上传了快 30 秒用户直接放弃了。压缩到 1080 宽和 80% 质量之后单张能压到 200KB 左右速度完全可接受。疫苗记录我简化处理了没有做“打了几针疫苗”的复杂逻辑只做“是否已接种狂犬疫苗 最近一次接种日期 疫苗本照片”。理由很简单寄养门店主要确认的是狂犬疫苗有没有打这是合规底线其他的品种疫苗信息价值不大。3.3 预订下单与订单状态流转下单是整个系统里最容易出错的环节。首先用户选中门店后要确认寄养时间段然后选宠物再填写需求备注最后支付。这个流程在交互上不能跳步但在状态控制上要非常严谨。订单状态我建议这样流转待支付、待商家确认支付成功未接单、已确认商家已接单、寄养中入住后、已完成离店后、已取消、已退款。前后端都要维护这个状态前端通过枚举常量统一定义避免魔法值。const ORDER_STATUS { UNPAID: 0, // 待支付 PENDING: 1, // 待商家确认 CONFIRMED: 2, // 已确认待入住 CARING: 3, // 寄养中 FINISHED: 4, // 已完成 CANCELED: 5, // 已取消 REFUNDED: 6 // 已退款 }日期选择我用了uni-datetime-picker组件mode 为 date开始日期和结束日期分别选。注意结束日期至少要比开始日期晚一天这个校验要在前端提前拦截不能等后端返回错误再提示。另外入住当天和离店当天是否算费用这个业务逻辑要跟商家提前约定好我项目里定的是“按自然日计算入住当天不算离店当天算”也就是 3 号入住 5 号离店等价于 2 天费用。支付这块小程序端通过uni.requestPayment拉起微信支付后端需要预先生成支付参数。uni.requestPayment({ provider: wxpay, timeStamp: payData.timeStamp, nonceStr: payData.nonceStr, package: payData.package, signType: MD5, paySign: payData.paySign, success: () { // 支付成功跳转到订单详情 }, fail: (err) { // 支付失败或取消 } })订单列表页要区分用户角色。普通用户看到的是“我的订单”寄养商家看到的是“门店订单”。我用的方法是在 store 里保存userInfo.role订单列表接口根据角色返回不同数据。但页面不要复用同一个因为操作按钮不同——用户端是“取消订单”“申请退款”“联系商家”商家端是“接单”“确认入住”“确认离店”。分开两个页面反而更清晰。3.4 商家端接单、录入寄养日志商家端和用户端在同一个小程序里通过角色切换进入。登录后如果当前用户绑定的角色是商家tabBar 或者个人中心会出现“商家工作台”入口。这个实现对本地开发来说很简单用 pinia 存储角色页面里v-if判断。商家工作台页面的布局是顶部统计卡片今日待接单、进行中订单、本月营收下面是今日任务列表。今日任务不是按订单展开而是按宠物展开——这样更符合门店的工作习惯早上起来先看今天有哪些宠物需要喂食、哪些需要遛、哪些需要喂药。寄养日志录入是整个商家端最核心的功能。日志的字段设计为日期、宠物ID、喂养情况吃了什么粮、吃了多少、遛狗情况几次、多长时间、精神状态活跃/正常/一般、备注、照片。前端录入后调接口保存用户端寄养动态页就能实时看到。这个功能看似简单但决定了整个产品的信任感。我特意在日志录入页面加了时间默认值——默认是当天当前时间避免商家补录时搞混日期。照片上传同样走压缩上传支持最多 9 张。商家端还有一个重要功能档期管理。门店需要在日历上标记哪天可以接单、哪天不可接。不可接的单日在下单页选择日期时应该直接禁选。前端日历用的uni-calendar组件自定义标记不可选日期后端接口返回未来 30 天的可接状态。3.5 用户端寄养动态与评价闭环寄养动态我设计成一个时间流页面类似朋友圈按日期倒序展示宠物每天的日志。进入这个页面时先看到最新的“今日喂养日志”往下滑动能看到前几天的。每一条日志包含图文、时间、精神状态标签。这个页面对用户来说就是“监控感”来源。我会把门店上传的每一张照片做全屏预览也支持一键保存到相册。这里注意不要直接用uni.previewImage的默认行为先判一下图片 URL 是否有防盗链微信小程序里图片域名一定要配置在 downloadFile 合法域名里否则预览和保存都会失败。寄养结束之后是评价环节。用户在“已完成”订单里可以写评价、打星整体卫生、服务态度、宠物照护三个维度、上传追加图片。评价成功后商家端门店详情页的评分会更新。评分计算建议后端做加权平均不要直接加三个维度除以三——因为用户对“卫生”和“态度”的容忍度不同我给卫生 40% 权重态度 30%照护 30%这个权重可以根据运营数据再调。评价发出去之后加入口方便店主回复。回复功能虽然简单但能明显提升商家和用户之间的互动感也能让其他用户在下单前看到门店响应速度。4. 我在这个项目里踩过的坑4.1 微信登录与静默授权的细节微信小程序登录的常规流程是uni.login拿到 code拿 code 去后端换 openid 和自定义登录态 token。这个流程本身不复杂但有个容易忽略的点uni.login获取到的 code 有效期只有 5 分钟而且只能用一次。如果后端换 token 失败前端不要自动重试要跳转到登录失败提示页让用户手动重新触发。手机号授权这块现在微信政策改过之后uni.getPhoneNumber的调用需要在按钮的 open-type 里声明不能再一进入页面就弹。我是把手机号绑定做成一个小弹窗用户点击“微信手机号一键绑定”按钮才触发授权拿到加密数据后传给后端解密。后端解密需要提前在微信公众平台申请开通“手机号快速验证组件”权限没有权限就继续用短信验证码兜底。4.2 地图定位与门店选点的一个坑前面提过requiredPrivateInfos的坑这里展开讲一下具体现象在开发者工具里uni.chooseLocation一切正常但真机预览时点击“选择门店位置”按钮页面直接闪退控制台报错信息里有一个getLocation:fail:api scope is not declared in the private protocol。这就是没有在 manifest.json 的mp-weixin配置里声明chooseLocation权限导致的。另外uni.getLocation在小程序里返回的经纬度是 gcj02 坐标而后台如果用的是高德或者腾讯地图坐标体系基本一致不用转换但如果用的是百度地图就涉及坐标转换。我后端用的 LBS 服务是腾讯位置服务小程序端传经纬度过去可以直接反解析出地址省了一步坐标转换。所以建议后端在选型时也注意坐标体系别混用。4.3 图片上传量一多就卡怎么处理这个项目上线后商家反馈最多的问题就是“传照片太慢”。一开始门店录入寄养日志时每次都要选 9 张原图上传很多用户手机拍的图都很大一张 5MB、6MB 很常见上传排队 等待后端返回 URL一套流程下来要 40 多秒。解决方案分两步。第一步是前端压缩uni.compressImage把单张图片压缩到宽 1080、质量 80%实测单张从 5MB 降到 200~300KB。第二步是改并行上传原来代码是 forEach 里串行上传改成Promise.all或自定义并发 3 个并行上传速度提升非常明显。const uploadTasks images.map((filePath) { return new Promise((resolve, reject) { uni.uploadFile({ url: BASE_URL /upload, filePath: filePath, name: file, success: (res) resolve(JSON.parse(res.data)), fail: reject }) }) }) const results await Promise.all(uploadTasks)但要注意并行上传不能无限并发微信小程序对同域名并发数有限制通常 10 个以内。我试过 9 张图同时传有大概一半会报超时错误改成并发 3 之后稳定了很多。4.4 常见问题速查表我把这个项目里遇到的其他高频问题整理成一张表方便你排查时对照。现象可能原因解决方案HBuilderX 运行到微信开发者工具没反应微信开发者工具服务端口未开启打开微信开发者工具设置 - 安全设置 - 开启服务端口定位接口在真机上报错manifest.json 缺少 requiredPrivateInfos 声明在 mp-weixin 下添加 getLocation / chooseLocation上传图片到一半失败并发数过高或图片过大前端压缩宽至1080并发限制在3个左右uni.requestPayment报 invalid request支付参数缺少 paySign 或签名错误后端统一下单后返回参数前端原样传给 requestPayment微信开发者工具中白屏且 console 无报错vue3 编译缓存问题HBuilderX 菜单-运行-清缓存重新编译自定义导航栏在不同手机偏移使用了固定高度用uni.getMenuButtonBoundingClientRect动态计算导航栏高度vue 页面在微信小程序里显示空白样式 scoped 中使用了*选择器微信小程序 WXSS 不支持部分通配选择器用类选择器替代真机调试无法触发订阅消息订阅消息每次触发需用户点击授权不能静默订阅必须由点击行为触发uni.requestSubscribeMessage另外有一个很隐蔽的问题vue 项目在 H5 端好好的打包成微信小程序后页面布局错乱这种大概率是小程序渲染和 DOM 的差异导致的。微信小程序里部分 CSS 属性不支持最典型的是position: fixed在滚动画布内的表现、flex的某些简写写法。解决方法是尽量少用vh/vw单位改用rpx并把弹性布局简化。我项目里一个门店详情页底部固定在底部的“立即预订”按钮就吃过position: fixed的亏后来改成position: sticky才正常。4.5 manifest 配置与多端打包的注意事项如果你是第一次用 uniapp 打包微信小程序这里有几个容易忽略的配置点。第一mp-weixin里必须填真实的 AppID测试号能在开发工具里看但真机预览、分享、支付都用不了。第二微信小程序后台要在“开发设置”里把 request 合法域名配置成你的 HTTPS 接口域名。开发阶段可以在开发者工具里关闭域名校验但体验版和正式版必须配好域名否则所有请求都会失败。第三如果要使用微信支付需要在微信商户平台开通 AppID 绑定并把小程序 AppID 关联到商户号。HBuilderX 云打包 App 的时候注意 uni-app 的云打包对个人开发者账号有一些权限限制iOS 打包需要开发者证书和描述文件Android 打包需要生成签名证书。如果只是做微信小程序完全不需要考虑这两个跑在 HBuilderX 里一键发行到微信开发者工具即可。5. 打包发布与上线经验5.1 小程序提审前一定要检查的几件事提审被拒是每个开发者都要经历的磨炼这个项目我前后被拒了三次整理了几个高频雷区。第一隐私协议必须完整。现在微信对用户隐私非常严格小程序里如果调用了位置、相册、摄像头等隐私接口必须在“小程序后台-设置-服务内容声明”里明确填写用途同时在小程序内提供一个可访问的隐私协议页面。我的做法是“我的”页面底部加了一个“隐私协议”入口里面写清楚收集了哪些信息、用于什么目的。第二虚拟支付问题。微信小程序里如果卖的是虚拟物品或者服务尤其是“在线咨询”“在线课程”这类纯线上服务非常容易触碰虚拟支付限制轻则类目审核不通过重则封禁支付能力。宠物寄养是线下实体服务不涉及虚拟支付审核一般没问题。如果你在这个系统里想做“宠物在线问诊”要特别注意可能需要换其他方案比如微信小程序内跳转公众号咨询。第三类目选择。宠物寄养服务在小程序类目里属于“生活服务-宠物服务”提交代码时类目要匹配否则会提醒“服务类目与小程序功能不符合”。第四订阅消息的模板设置。寄养动态提醒要用订阅消息这个必须在微信公众平台申请对应模板审核通过后才能调用uni.requestSubscribeMessage。模板标题和关键词要提前规划好比如“寄养开始提醒”“寄养日志更新”“订单支付成功”。如果临时发现没有合适的模板补申请周期会比较长。5.2 这套代码还能往哪扩展做完了微信小程序这套 uniapp 代码其实已经同时具备了 H5 和 App 的编译能力。我后续在项目里的规划是这几个方向。第一H5 端的扩展。uniapp 编译成 H5 后可以嵌入微信公众平台公众号菜单这样用户除了小程序外还能通过公众号进入同套系统。H5 端要注意一个点微信内打开的 H5 获取用户头像昵称的接口已经调整现在要用微信开放标签wx-open-launch-weapp或者使用wx.config里的openTagList配置来唤起小程序。我试过在公众号文章里挂 H5 页面用户点击后可以直接拉起小程序并携带参数跳到指定门店详情页这个跳转方案对于拉新很有价值。第二App 端的差异化。如果将同一套代码打包成 App可以做小程序端做不了的事比如nfc读取宠物芯片信息或者用uni-native-plugin接入智能宠物项圈设备。热词里有人问 uniapp 集成 NFC 读取卡片其实就是把设备端的 SDK 封装成 uniapp 原生插件通过plus.android.importClass或uni.requireNativePlugin调用。这个扩展方向很适合高端宠物寄养服务。第三商家端独立化。当前商家端是嵌在小程序里的如果合作门店多了可以考虑做一套独立的商家版小程序或者把商家工作台迁移到 Web 后台。这个调整基于数据现状决策当门店数量超过 50 家、日均订单超过 200 单时嵌入式商家端会越来越难管理独立商户后台是必然趋势。5.3 自定义分享与拉新裂变最后聊聊分享渠道。微信小程序天然的社交属性让“老客拉新客”变得很重要。这里涉及 uniapp 里的分享接口实现。小程序分享有两种一种是通过按钮open-typeshare触发另一种是右上角菜单的转发。uniapp 里实现页面分享要在每个需要分享的页面里写onShareAppMessage生命周期onShareAppMessage() { return { title: 帮你在这家店寄养过宠物体验不错, path: /pages/hotel/detail?id${this.hotelId}, imageUrl: this.hotelCover } }若希望分享出去的海报更好看可以生成一张包含门店和二维码的海报图用uni.canvasToTempFilePath把 canvas 绘制的内容导出成图片再引导用户保存到相册。我用这个方式做了一个简单的分享海报转化率比纯链接分享高不少。一个要注意点是分享出去的页面路径不能带 token。因为 token 存本地好友打开分享页面时小程序是一个全新的启动上下文本地存储里没有 token。所以分享页面要么是公开数据要么好友打开后先跳登录页再带参跳回。我这里是门店详情本身就是公开数据所以可以直接分享。一开始接触这种全栈项目的人容易把精力全放在前端界面上结果后端的订单状态机和数据表没设计好返工成本极高。我的经验是先把核心实体的字段、订单状态机、各端接口的 JSON 结构确认好再开始写页面。前端的每个页面都围绕接口数据结构来写后面接真实接口时只是换 URL不用改页面逻辑。这套宠物寄养托管系统做下来最大的心得是“信任感”才是这个业务的核心。用户在页面上看得越清楚、商家反馈越及时订单转化率和复购率就越高。所以代码里真正值得花时间的不是华丽动画而是日志上传的流畅度、订单状态的清晰表达、消息通知的及时触达。如果你正在做类似的项目建议先把这三个地方打磨到顺手再去加花活儿。最后分享一个小经验uniapp 项目一定记得定期用 HBuilderX 的“重新编译”清理缓存尤其是从 vue2 迁移到 vue3 之后编译器偶尔会留下旧结构的缓存文件导致页面渲染异常。遇到排查不出来的白屏问题先试这个操作往往比看半天代码更高效。
返回列表