1. 项目概述与核心需求拆解宠物寄养托管系统听着好像就是一个普通的预约类小程序真正上手做的时候才发现它比一般的电商或者内容类小程序复杂多了。我最初接到这个需求时对方给的需求文档只有三页用户登录、选宠物店下单、查看订单。看起来很简单对吧但实际做下来整个项目从前端页面到后端交互、从微信授权到支付回调涉及到的技术点能写满半本面试题集。先说清楚这个项目是什么。它是一个跑在微信小程序里的宠物寄养服务预约平台用户通过小程序浏览附近的寄养商家、查看宠物托管套餐、预约寄养时间、在线支付费用商家端再通过同一个小程序或配套的独立端接单和管理寄养记录。技术栈选的是 uni-app Vue一套代码同时输出微信小程序、H5 和 App这也是现在很多创业团队和个人开发者选型时的标准答案。为什么选 uni-app 而不是直接用微信原生小程序开发这是第一个需要想清楚的问题。如果你的项目只打算投放在微信生态里原生小程序确实在性能上有一点优势但代价是团队只能围着微信转。uni-app 基于 Vue 语法一套代码可以发到微信小程序、支付宝小程序、抖音小程序、H5 和 App 端对于做本地生活类项目来说多端覆盖的诱惑力太大了。后期如果业务扩展不需要做 App至少 H5 版本也能用来做微信外的分享引流。另外要提到的是宠物寄养这个赛道有它独特的运营逻辑。寄养服务不是标准化商品它的核心是“信任”——主人把宠物托付给一个陌生的店家最担心的是宠物吃得好不好、住得舒不舒服、会不会生病。所以这个小程序里订单的展示逻辑、宠物档案的完善程度、寄养过程的图片视频反馈这些细节比支付流程还重要。我在设计数据库时特意加了“寄养日志”这一块每一笔订单可以关联多条图文记录相当于给宠物主人提供“实时监控”一样的体验这个功能在后来的使用反馈里成了口碑最高的点。还有一个必须提前考虑的人宠物主和商家到底谁是小程序的主要用户我最后采用的做法是双角色登录同一个微信号在登录时选择身份后端返回不同的角色码前端根据角色码渲染不同的首页和功能入口。用户端是标准的下单流程商家端则是订单管理、寄养日志录入、宠物房态管理这些后台功能。如果一开始就直接做两套独立小程序开发和维护成本都会翻倍合并成一个项目用条件编译和权限控制来区分是性价比最高的方案。2. 技术选型与项目架构设计2.1 为什么是 uni-app Vue而不是其他组合选型这块我比较有发言权因为在这套方案之前我用原生小程序做过两个项目也用 React Native 碰过钉子。原生小程序的问题不在于写不了而在于迭代太慢。一个页面写完想发到 H5 端看看效果得全部重写业务逻辑还容易写飘。RN 则是搞不定小程序的生态微信支付、分享、地图导航这些能力还是得绕回到小程序容器里。uni-app 最顺手的点是它保留了 Vue 的响应式开发体验页面开发、组件复用、状态管理的思维和 Web 开发完全一致团队里做过 Vue 的人基本能做到无缝上手。而且它底层的编译做到了条件编译让同一套代码根据不同的运行平台输出不同的代码片段——这个特性在开发宠物寄养系统时经常用到比如 App 端调用地图导航和微信小程序端调用 wx.openLocation 就是完全不同的写法和 API用条件编译可以优雅地处理掉这层差异。Vue 版本我选的是 Vue 2。虽然 Vue 3 已经发布很久了组合式 API 的代码组织方式确实更清晰但 uni-app 对 Vue 3 的生态支持在当初还有不少坑很多第三方组件库的兼容性都没跟上。如果你现在才开始新项目可以优先尝试 uni-app 的 Vue 3 版本但如果是接手老项目或者依赖比较多的项目老老实实用 Vue 2 反而更省心。2.2 项目目录结构与分层设计项目结构是决定后续维护效率的第一道关卡。我没有用 uni-app 默认生成的模板直接开工而是按照“页面、组件、API、工具、状态”几个维度做了重新划分src/ ├── api/ // 所有接口请求统一封装按业务模块拆文件 │ ├── user.js // 用户登录、授权、信息修改 │ ├── order.js // 订单创建、支付、取消、查询 │ ├── store.js // 商家门店列表、详情、评价 │ └── pet.js // 宠物档案、寄养日志 ├── components/ // 全局公共组件 │ ├── pet-card.vue // 宠物卡片组件 │ ├── order-status.vue // 订单状态标签组件 │ └── empty-state.vue // 空数据占位组件 ├── pages/ │ ├── user/ │ ├── store/ │ ├── order/ │ └── my/ ├── store/ // Vuex 状态管理 │ ├── index.js │ ├── modules/user.js │ └── modules/order.js ├── utils/ // 工具函数 │ ├── request.js // uni.request 封装 │ ├── auth.js // token 存取与校验 │ ├── upload.js // 图片上传封装 │ └── format.js // 时间金额格式化 ├── static/ // 静态资源 └── manifest.json // uni-app 应用配置很多初学者容易犯的错误是把接口请求直接写在页面的 onLoad 里页面一多就到处都是请求逻辑改一个接口地址能翻遍整个项目。我在这个项目里用 api 层的思路做了统一收敛页面里只调用对应模块的函数所有请求的入参出参都在 api 层维护后端接口改了只动一个文件。这样做还有一个附加收益接口的调用次数和错误率可以集中在 request.js 里做统计排查问题的时候非常方便。2.3 状态管理的取舍宠物寄养系统的状态管理没有复杂到需要一个重型状态库但也不能完全裸奔。我主要用 Vuex 存了三类数据用户登录态token、用户信息、角色、订单筛选条件列表页的状态 tag、分页参数、寄养日志的编辑草稿。为什么要把订单筛选条件放进 Vuex因为用户从首页进入订单列表筛选了“进行中”的订单点进去看详情再返回时如果状态丢了就得重新筛选这种体验很割裂。用 Vuex 存一份保证切换页面时列表状态不丢失。要注意的是Vuex 的数据是存在内存里的小程序被杀掉再启动就清空了。所以我做了持久化处理把 token 和用户信息同步写入 storageApp.vue 的 onLaunch 里优先读 Vuex如果发现 Vuex 空了再从 storage 恢复一次。这个方案简单有效不需要额外引插件。实时性要求高的寄养日志推送我走的是 WebSocket 通道不经过 Vuex直接通过事件分发更新到对应页面避免共享状态被无关页面反复触发更新。2.4 manifest.json 与微信小程序配置要点manifest.json 是 uni-app 项目的配置文件微信小程序相关的配置也基本集中在这里。我第一次提交审核时因为没配好隐私声明直接被驳回了。现在小程序审核对用户隐私的管控越来越严格尤其是涉及定位、相册、摄像头这些敏感权限的必须在 manifest.json 里声明用途同时要在小程序后台的“用户隐私保护指引”里同步填写。具体到宠物寄养系统需要用到的微信权限包括获取用户头像昵称不一定强制授权现在微信改了规则可以用头像昵称填写能力替代选择相册图片用户上传宠物照片、身份证照片时使用使用定位查找附近的寄养店家地图查看店家具体位置和导航manifest.json 里微信小程序端的配置项有几个容易踩坑的permission字段必须写清楚 scope.userLocation 的用途描述文案不能写得太笼统我写的是“用于查找附近的宠物寄养门店”一次通过审核。requiredPrivateInfos字段填的是隐私接口列表如果你调用了 wx.getLocation这里就必须加上getLocation否则在实际调用时会报错。3. 数据库设计与后端接口规划3.1 核心数据表结构宠物寄养系统的后端我用了 Node.js MySQL 搭建Redis 做缓存。前期规划表结构花了大概两天时间比实际写代码的时间还长但这部分想清楚了对后期开发效率影响巨大。核心表有这么几张用户表、门店表、宠物档案表、寄养套餐表、订单表、寄养日志表、评价表。订单表是整张逻辑的枢纽字段设计上我吃了不少亏说几个关键的CREATE TABLE order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, user_id bigint(20) NOT NULL COMMENT 下单用户ID, store_id bigint(20) NOT NULL COMMENT 门店ID, pet_id bigint(20) NOT NULL COMMENT 宠物档案ID, package_id bigint(20) NOT NULL COMMENT 套餐ID, start_time datetime NOT NULL COMMENT 寄养开始时间, end_time datetime NOT NULL COMMENT 寄养结束时间, amount decimal(10,2) NOT NULL COMMENT 订单金额, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 状态0待支付 1待接单 2寄养中 3待取回 4已完成 5已取消, pay_time datetime DEFAULT NULL COMMENT 支付时间, remark varchar(255) DEFAULT NULL COMMENT 用户备注, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_store_id (store_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单状态真的不能只设计成“待支付/已支付/已完成”三个状态。宠物寄养的真实业务里主人下单后要经过店家确认有没有空位、接到宠物后开始服务、服务结束后主人确认取回中间还有可能用户主动取消或者店家爆满拒绝。我最后用了 6 个状态待支付、待商家接单、寄养中、待取回、已完成、已取消对应的操作流转会在后面的业务逻辑部分详细说。宠物档案表也要单独说。很多宠物主不止养一只宠物寄养服务是按宠物个体来算的所以订单必须关联到具体的宠物而不是笼统地关联用户。宠物档案里除了昵称、品种、年龄、性别这些基础信息我还加了“是否绝育”“疫苗接种情况”“性格标签”这几个字段它们会直接显示在商家端的接单面板上帮助店家判断是否能接待。3.2 接口设计规范与请求封装后端接口我统一走 RESTful 风格前缀是/api/v1。为什么加版本号因为小程序端发布审核有周期线上版本还在跑旧接口新版本可能已经要联调新接口了没有版本控制根本没法并行开发。所有接口返回统一格式{ code: 0, message: success, data: {} }code 为 0 表示成功非 0 表示业务异常HTTP 状态码只表示网络层状态。这个约定在前后端联调时特别有效前端拦截器只需要判断 code 就能决定是走正常流程还是弹错误提示不需要关心 HTTP 状态码的各种分支。前端的请求封装是另一个不能省的工作。uni.request 的 API 能力是够用的但直接裸用会很痛苦——每个请求都要带 token、都要处理 loading、都要错误提示。我在 utils/request.js 里封装了一个统一的请求方法// utils/request.js const BASE_URL https://api.example.com/api/v1 export function request(options) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { Content-Type: application/json, Authorization: uni.getStorageSync(token) || }, success: (res) { if (res.statusCode 401) { // token 过期跳转登录页 uni.removeStorageSync(token) uni.navigateTo({ url: /pages/user/login }) reject(res) return } if (res.data.code 0) { resolve(res.data.data) } else { // 统一弹出错误提示 uni.showToast({ title: res.data.message, icon: none }) reject(res.data) } }, fail: (err) { uni.showToast({ title: 网络异常请稍后重试, icon: none }) reject(err) } }) }) }这里有几个容易被忽略的细节uni.getStorageSync(token)每次请求都读一次 storage性能上确实有一点损耗但换来的是 token 在失效后能立刻感知不用重启小程序。请求方法返回 Promise 是为了让页面层可以用 async/await 写业务逻辑代码会干净很多。还有错误提示统一在拦截器里处理页面里就不再重复写uni.showToast了。3.3 登录鉴权与多角色管理微信小程序的登录流程可以说是每个新手都会被绕晕的地方。最核心的问题是为什么不能直接用wx.login返回的 code 去后端换用户信息因为 code 换到的是 openid 和 session_keyopenid 是用户在某个小程序下的唯一标识但它是不能直接暴露到业务后端做身份凭证的否则可能有越权风险。正确的流程是前端拿到 code 发给后端后端调用微信接口换 openid生成一个自定义的 token 返回给前端。这个 token 由后端自己控制有效期比 session_key 的过期机制更可控。宠物寄养系统里多了一种复杂度同一个用户既可以是寄养主人也可以是商家管理员。我的处理方案是用户表里加一个role字段登录时弹窗让用户选择“我是宠物主人”或“我是商家”选择后调登录接口后端校验该微信号是否能以对应角色登录商家需要后管理员预先录入手机号。返回的 token 里我用 JWT 编码了 userId 和 role后端接口通过AuthRequired注解校验角色权限。JWT 在这里比传统的 session 方案好在无状态、易扩展后续如果系统要接入管理后台同一套 token 校验逻辑可以直接复用。要注意的是小程序端的 token 过期后用户需要重新走微信登录流程所以我设置了 token 的有效期为 7 天并且加了“自动续期”机制当接口返回 401 时前端自动调用刷新 token 的接口用户完全无感。4. 核心功能模块设计与实现4.1 用户登录与授权用户登录是每个小程序的第一步也是审核时最容易出问题的地方。现在微信对 getUserProfile 的管控很严不建议再弹窗强制用户授权头像昵称而是用微信提供的“头像昵称填写能力”用户在个人中心点击头像区域微信会弹出系统自带的设置界面让用户选择头像和填写昵称前端拿到后直接传给后端保存。但登录还是需要 wx.login 的具体步骤// 微信登录 uni.login({ provider: weixin, success: async (loginRes) { // loginRes.code 是临时凭证5 分钟内有效 const data await request({ url: /auth/login, method: POST, data: { code: loginRes.code, role: this.role } }) uni.setStorageSync(token, data.token) uni.setStorageSync(userInfo, data.userInfo) } })后端拿到 code 后调用微信的jscode2session接口拿到 openid 和 session_key再查数据库判断用户是否存在不存在就创建一条新记录最后签发 token 返回。这里有个实操细节别忘了把 session_key 存在后端后面如果要做“手机号快速验证”或者“微信运动数据同步”都还需要用到它。授权这一块我用了“按需申请”的策略页面级权限在地理位置和相册这两块。首页加载时就弹窗要地理位置会让用户很反感改成用户主动点击“找附近门店”时才调用uni.getLocation这时候再申请权限转化率会高很多。4.2 首页设计门店列表与定位距离计算首页是宠物寄养系统的门面我采用的是“顶部搜索栏 定位信息 门店卡片列表”的布局。定位是这里最关键的功能因为寄养服务有强烈的地域属性用户要找的一定是离自己近、方便接送的门店。用uni.getLocation拿到用户经纬度后传给后端接口后端用 Haversine 公式计算门店与用户之间的距离按距离排序返回。计算公式不算复杂但在 SQL 里直接写会吃掉不少性能我改用 Redis GEO 做邻近门店查询。写入门店经纬度后GEORADIUS命令一行就能拿到指定半径内的所有门店 ID速度是毫秒级的。门店卡片上要展示的信息包括门店封面、名称、评分、距离、门头照、几个关键服务标签如“免费接宠”“24小时监控”“宠物零食赠送”。这里还想强调一个细节寄养服务的用户决策链路比较长卡片上最好有一个“查看环境”的入口点进去是一个图册页。我们后台上传了门店的照片前端用 swiper 轮播展示。这个功能在试运营阶段就发现用户点击率特别高比套餐内容点击率还高——果然主人都是颜值控。4.3 宠物档案管理宠物档案模块是容易被忽略但特别体现产品心的地方。我在做需求分析时发现寄养店家有很强烈的信息需求这只狗狗会不会咬人、有没有过敏史、平时吃什么牌子的狗粮、睡觉有什么习惯。这些信息如果每次寄养都让主人重新输入用户会烦如果完全不收商家接单后还得私下沟通效率低。所以我把宠物档案设计成“基础信息 生活习惯 健康信息”三块结构。基础信息是必填的昵称、品种、年龄、性别、是否绝育生活习性和健康信息选填但填写完整度会有一个进度条展示在用户端的宠物列表页上。寄养下单时用户可以一键将宠物档案的完整信息同步到订单里商家端看到的就是一份整理好的宠物资料卡接单效率大幅提升。上传宠物照片时我用了 uni-app 的uni.chooseImage需要把图片上传到云存储或后端然后拿到 URL 存数据库。这里有个性能优化点图片在本地选择时是几 MB 的原图直接上传既慢又费流量。我加了一步压缩处理用uni.compressImage把图片压缩到 400KB 以内再上传用户上传速度和后端存储压力都能得到明显优化。实测下来一个 5MB 的图片能压到 300KB 左右清晰度损失肉眼几乎看不出来。4.4 寄养套餐与下单流程寄养套餐的定价策略完全依赖于业务方技术上的重点是套餐结构的设计。一种套餐是简单的一口价如小型犬 58 元/天但现实情况更复杂不同体型的狗狗价格不同、寄养超过 5 天有折扣、节假日有浮动价格、加购遛狗服务要额外收费。我最后把套餐设计成“基础价格 计价规则”的模式{ name: 小型犬标准寄养, basePrice: 58, unit: day, rules: [ { condition: days 7, discount: 0.9 }, { condition: days 30, discount: 0.8 } ], include: [基础喂养, 每日遛狗, 视频反馈], extraServices: [ { name: 专业洗护, price: 38 }, { name: 加餐鲜食, price: 15 } ] }下单页面的核心是日期选择和价格计算。日期我用的是uni-datetime-picker组件但这里遇到过一个性能问题在 iOS 端uni-datetime-picker放在scroll-view里滚动时会因为渲染机制特殊导致选择器弹层闪烁需要在真机上反复验证。价格计算规则在前端实时算用户改日期就重新算一遍提交订单时后端再算一遍两边对得上才允许创建订单防止前端被篡改。4.5 订单状态机与商家接单订单状态流转是整个系统里最容易写乱的业务逻辑所以我画了一个特别清晰的状态机并写死在代码里待支付用户创建订单后 15 分钟内未支付自动取消待商家接单支付成功后进入待接单队列商家端可以接受或拒绝寄养中商家确认接收宠物后状态变更为寄养中这个状态会一直持续到寄养结束时间待取回寄养时间到期后状态自动变为待取回等待主人到店已完成主人确认取回订单结束已取消用户主动取消或商家拒绝接单状态变更不能直接让前端随意调接口修改我在后端加了操作权限校验每一步操作都对应一个独立接口POST /order/{id}/accept商家接单、POST /order/{id}/reject商家拒单、POST /order/{id}/checkout主人确认取回。商家端是我单独设计的一套页面结构在同一个 uni-app 项目里通过角色判断渲染不同的 tabBar。商家首页展示的是待接单队列和寄养中的宠物列表每个寄养中的宠物卡片上都有一个“添加日志”按钮点击后可以上传文字和图片这些日志会自动推送给对应的主人端。4.6 支付流程与回调处理微信支付在小程序端的流程概括起来是三步前端把订单信息发给后端后端调用微信支付统一下单 API拿到payment参数前端用uni.requestPayment唤起微信支付界面用户支付完成后微信服务器向后端配置的回调地址发送支付结果通知一个经常被忽略的点是uni.requestPayment里的参数名和微信小程序原生 API 的参数名是不同的。我在对接时认真对比了文档timeStamp注意大写 S、nonceStr、package值是 prepay_idxxx、signType、paySign一个都不能少大小写也不能错否则会报invalid sign。这里的坑我之后会专门整理一节。支付回调的后端处理也有要求幂等性。微信服务器可能会因为网络原因多次回调同一个订单后端必须做去重用订单号加支付流水号做唯一索引重复回调直接返回成功。回调返回的报文格式也要按要求组装不然微信会认为回调失败反复重试。5. 真机调试、抓包与打包上线5.1 HBuilderX 配置与模拟器调试开发环境我用的 HBuilderX它是 uni-app 官方 IDE集成了运行、调试、打包到各个平台的功能。在写代码的时候可以直接开微信开发者工具的模拟器修改代码后热更新到模拟器里。但模拟器能验证的问题有限尤其是涉及微信 API 的部分比如uni.getLocation返回的坐标系在真机和模拟器上可能就不一样。所以我养成了一个习惯每完成一个页面就用 HBuilderX 里的“运行到手机或模拟器”在微信开发者工具里扫码真机预览跑一遍关键功能。多付出的只是扫码那几秒钟但发现的问题都是真问题。5.2 真机调试与 Charles 抓包排查微信小程序的网络请求默认是加密的想用 Charles 或 Fiddler 抓包需要做一些准备工作。我的做法是在微信开发者工具里把“不校验合法域名”勾上然后设置代理到 Charles手机上也要安装 Charles 的 CA 证书并开启信任这样就能看到小程序发出的 HTTPS 请求内容。这个能力在线上问题排查时太重要了。有次用户反馈支付成功后订单状态没变我拿到了用户手机抓的日志发现请求后端接口时返回了 504。进一步排查发现是回调函数里查到门店信息时Redis 连接池耗尽导致超时整个链路就卡住了。如果只能看前端日志这个问题的定位周期会翻倍。5.3 uniapp 打包发布到微信平台的完整流程uni-app 项目做完打包前必须先处理几件事。第一件是在 manifest.json 里填写小程序的 AppID这个是微信公众平台分配的和开发者工具里的一致。第二件是把接口地址从测试环境切换成生产环境这个我建议做成配置文件用process.env.NODE_ENV区分开发、测试、生产环境打包时自动选择。HBuilderX 里点击“发行 - 小程序-微信”编译完成后会在dist/dev/mp-weixin目录下生成微信小程序代码。用微信开发者工具导入这个目录先在开发者工具里跑一遍确认没问题后再点“上传”然后在微信公众平台提交审核。审核周期一般是 1-3 天第一次做建议提前预留时间。ios 安卓 App 的打包流程是另一套方案uni-app 云打包或本地离线打包这个项目初期只做微信端以后要上 App 再另外说。这里只提醒一句App 打包需要准备签名证书安卓的签名文件一旦丢了后续更新就没法替换一定要妥善留存。5.4 上线前检查清单上线前我习惯再过一遍清单照下面这个走网络请求全部走 HTTPS且域名已经在小程序后台配置为合法域名用户隐私协议和用户授权弹窗流程完整敏感权限申请都有对应的业务场景触发支付流程在真机上跑通至少一遍确认回调成功、订单状态变更正确订单金额在小数点后两位以内没有浮点运算精度问题分享功能可用分享出来的页面能正常打开并跳转到位空数据页面和异常页面有兜底不会出现长时间白屏6. 常见问题与避坑指南6.1 微信定位权限与坐标系真机调试时用uni.getLocation在地图里展示位置发现位置偏移很严重。原因在于微信返回的是 GCJ-02 坐标系火星坐标系而如果地图 API 默认用的 WGS-84 或者后端存储的经纬度是其他坐标系就会偏出好几公里。解决办法是在后端统一做坐标系转换或者直接用type: gcj02参数让uni.getLocation返回火星坐标保持全链路一致。6.2 uni-datetime-picker 在 scroll-view 里的闪烁问题iOS 端微信小程序的渲染机制比较特殊uni-datetime-picker放在scroll-view里滚动时会出现弹层闪烁甚至无法弹出的问题。我排查了很久最后发现是组件在滚动过程中不断触发重绘导致的。常见处理方案是给scroll-view加上enhanced属性和show-scrollbarfalse或者把日期选择器移到页面层固定定位避免它和滚动事件互相干扰。这个坑在 Android 端很难测出来一定要用 iOS 真机多试几遍。6.3 支付签名错误微信支付报invalid sign是最常见的报错之一。大概率是参数拼接顺序错了或大小写问题。微信支付签名算法要求按参数名 ASCII 码从小到大排序再拼接 key 后做 MD5 或 HMAC-SHA256 加密。我排查这类问题的通用流程是把前端传给uni.requestPayment的参数打印出来和后端生成签名时用的参数比对逐一核对字段名大小写、值是否含空格、时间戳格式。6.4 图片上传失败与压缩策略图片上传的坑主要在大小限制上。微信小程序wx.uploadFile的上传大小限制是 10MB但用户相册里随手拍的照片经常超过这个限制。我的做法是选择图片后用uni.compressImage先压缩再走上传同时在uni.uploadFile的 complete 回调里清理临时文件路径防止路径泄漏到其他页面。6.5 审核被拒的常见原因小程序审核被拒在宠物寄养项目里最常见的几条原因是需要用户授权手机号却没完成微信认证个人主体不支持类目选择与内容不符涉及宠物服务的要选“生活服务-宠物”类目需要提供相应资质隐私弹窗文案不清页面存在测试数据要确保演示账号能登录且数据是真实的。每次提交前都对照微信小程序运营规范逐条自检能省掉来回提审的时间成本。7. 项目复盘费用、周期与扩展空间整个项目从需求梳理到上线我花了大约三周时间。前期数据库设计 2 天前端页面和接口联调 10 天支付对接和真机调试 3 天审核整改花了 2 天。如果是不熟悉 uni-app 的团队做周期至少翻倍。这里给准备接这类项目的人一个建议不要把工期排太满前后端联调阶段出现的问题往往比想象中多。费用方面如果完全是外包开发按当前行情大概在几万到十几万不等取决于商家端功能的复杂度和是否需要做 App 端。如果是自己维护主要成本就是服务器和备案费用轻量应用服务器一年几百元就够撑起初期的小规模运营。关于扩展空间现在这套架构已经在为后续功能留好了接口。宠物主的使用数据沉淀下来后可以做智能推荐根据犬种性格推荐匹配的寄养门店商家端可以加摄像头接入主人直接在小程序里看宠物在店里的实时状态还有“寄养日记”功能根据每天的日志自动生成宠物寄养期间的成长记录可以分享到朋友圈。这些功能的技术底座都不需要推翻重来在现有页面和接口上做增量开发就能实现。最后分享一个实际运营中得来的小经验宠物寄养系统上线后最容易让用户流失的环节不是支付也不是登录而是寄养期间“没有消息”。我们每天在固定时间上传宠物状态和照片主人收到了推送后面复购率高了许多。技术把流程串通了剩下的就要靠运营去填满那些让用户安心的细节了。
宠物寄养小程序开发实战：uni-app+Vue跨平台架构设计与上线
1. 项目概述与核心需求拆解宠物寄养托管系统听着好像就是一个普通的预约类小程序真正上手做的时候才发现它比一般的电商或者内容类小程序复杂多了。我最初接到这个需求时对方给的需求文档只有三页用户登录、选宠物店下单、查看订单。看起来很简单对吧但实际做下来整个项目从前端页面到后端交互、从微信授权到支付回调涉及到的技术点能写满半本面试题集。先说清楚这个项目是什么。它是一个跑在微信小程序里的宠物寄养服务预约平台用户通过小程序浏览附近的寄养商家、查看宠物托管套餐、预约寄养时间、在线支付费用商家端再通过同一个小程序或配套的独立端接单和管理寄养记录。技术栈选的是 uni-app Vue一套代码同时输出微信小程序、H5 和 App这也是现在很多创业团队和个人开发者选型时的标准答案。为什么选 uni-app 而不是直接用微信原生小程序开发这是第一个需要想清楚的问题。如果你的项目只打算投放在微信生态里原生小程序确实在性能上有一点优势但代价是团队只能围着微信转。uni-app 基于 Vue 语法一套代码可以发到微信小程序、支付宝小程序、抖音小程序、H5 和 App 端对于做本地生活类项目来说多端覆盖的诱惑力太大了。后期如果业务扩展不需要做 App至少 H5 版本也能用来做微信外的分享引流。另外要提到的是宠物寄养这个赛道有它独特的运营逻辑。寄养服务不是标准化商品它的核心是“信任”——主人把宠物托付给一个陌生的店家最担心的是宠物吃得好不好、住得舒不舒服、会不会生病。所以这个小程序里订单的展示逻辑、宠物档案的完善程度、寄养过程的图片视频反馈这些细节比支付流程还重要。我在设计数据库时特意加了“寄养日志”这一块每一笔订单可以关联多条图文记录相当于给宠物主人提供“实时监控”一样的体验这个功能在后来的使用反馈里成了口碑最高的点。还有一个必须提前考虑的人宠物主和商家到底谁是小程序的主要用户我最后采用的做法是双角色登录同一个微信号在登录时选择身份后端返回不同的角色码前端根据角色码渲染不同的首页和功能入口。用户端是标准的下单流程商家端则是订单管理、寄养日志录入、宠物房态管理这些后台功能。如果一开始就直接做两套独立小程序开发和维护成本都会翻倍合并成一个项目用条件编译和权限控制来区分是性价比最高的方案。2. 技术选型与项目架构设计2.1 为什么是 uni-app Vue而不是其他组合选型这块我比较有发言权因为在这套方案之前我用原生小程序做过两个项目也用 React Native 碰过钉子。原生小程序的问题不在于写不了而在于迭代太慢。一个页面写完想发到 H5 端看看效果得全部重写业务逻辑还容易写飘。RN 则是搞不定小程序的生态微信支付、分享、地图导航这些能力还是得绕回到小程序容器里。uni-app 最顺手的点是它保留了 Vue 的响应式开发体验页面开发、组件复用、状态管理的思维和 Web 开发完全一致团队里做过 Vue 的人基本能做到无缝上手。而且它底层的编译做到了条件编译让同一套代码根据不同的运行平台输出不同的代码片段——这个特性在开发宠物寄养系统时经常用到比如 App 端调用地图导航和微信小程序端调用 wx.openLocation 就是完全不同的写法和 API用条件编译可以优雅地处理掉这层差异。Vue 版本我选的是 Vue 2。虽然 Vue 3 已经发布很久了组合式 API 的代码组织方式确实更清晰但 uni-app 对 Vue 3 的生态支持在当初还有不少坑很多第三方组件库的兼容性都没跟上。如果你现在才开始新项目可以优先尝试 uni-app 的 Vue 3 版本但如果是接手老项目或者依赖比较多的项目老老实实用 Vue 2 反而更省心。2.2 项目目录结构与分层设计项目结构是决定后续维护效率的第一道关卡。我没有用 uni-app 默认生成的模板直接开工而是按照“页面、组件、API、工具、状态”几个维度做了重新划分src/ ├── api/ // 所有接口请求统一封装按业务模块拆文件 │ ├── user.js // 用户登录、授权、信息修改 │ ├── order.js // 订单创建、支付、取消、查询 │ ├── store.js // 商家门店列表、详情、评价 │ └── pet.js // 宠物档案、寄养日志 ├── components/ // 全局公共组件 │ ├── pet-card.vue // 宠物卡片组件 │ ├── order-status.vue // 订单状态标签组件 │ └── empty-state.vue // 空数据占位组件 ├── pages/ │ ├── user/ │ ├── store/ │ ├── order/ │ └── my/ ├── store/ // Vuex 状态管理 │ ├── index.js │ ├── modules/user.js │ └── modules/order.js ├── utils/ // 工具函数 │ ├── request.js // uni.request 封装 │ ├── auth.js // token 存取与校验 │ ├── upload.js // 图片上传封装 │ └── format.js // 时间金额格式化 ├── static/ // 静态资源 └── manifest.json // uni-app 应用配置很多初学者容易犯的错误是把接口请求直接写在页面的 onLoad 里页面一多就到处都是请求逻辑改一个接口地址能翻遍整个项目。我在这个项目里用 api 层的思路做了统一收敛页面里只调用对应模块的函数所有请求的入参出参都在 api 层维护后端接口改了只动一个文件。这样做还有一个附加收益接口的调用次数和错误率可以集中在 request.js 里做统计排查问题的时候非常方便。2.3 状态管理的取舍宠物寄养系统的状态管理没有复杂到需要一个重型状态库但也不能完全裸奔。我主要用 Vuex 存了三类数据用户登录态token、用户信息、角色、订单筛选条件列表页的状态 tag、分页参数、寄养日志的编辑草稿。为什么要把订单筛选条件放进 Vuex因为用户从首页进入订单列表筛选了“进行中”的订单点进去看详情再返回时如果状态丢了就得重新筛选这种体验很割裂。用 Vuex 存一份保证切换页面时列表状态不丢失。要注意的是Vuex 的数据是存在内存里的小程序被杀掉再启动就清空了。所以我做了持久化处理把 token 和用户信息同步写入 storageApp.vue 的 onLaunch 里优先读 Vuex如果发现 Vuex 空了再从 storage 恢复一次。这个方案简单有效不需要额外引插件。实时性要求高的寄养日志推送我走的是 WebSocket 通道不经过 Vuex直接通过事件分发更新到对应页面避免共享状态被无关页面反复触发更新。2.4 manifest.json 与微信小程序配置要点manifest.json 是 uni-app 项目的配置文件微信小程序相关的配置也基本集中在这里。我第一次提交审核时因为没配好隐私声明直接被驳回了。现在小程序审核对用户隐私的管控越来越严格尤其是涉及定位、相册、摄像头这些敏感权限的必须在 manifest.json 里声明用途同时要在小程序后台的“用户隐私保护指引”里同步填写。具体到宠物寄养系统需要用到的微信权限包括获取用户头像昵称不一定强制授权现在微信改了规则可以用头像昵称填写能力替代选择相册图片用户上传宠物照片、身份证照片时使用使用定位查找附近的寄养店家地图查看店家具体位置和导航manifest.json 里微信小程序端的配置项有几个容易踩坑的permission字段必须写清楚 scope.userLocation 的用途描述文案不能写得太笼统我写的是“用于查找附近的宠物寄养门店”一次通过审核。requiredPrivateInfos字段填的是隐私接口列表如果你调用了 wx.getLocation这里就必须加上getLocation否则在实际调用时会报错。3. 数据库设计与后端接口规划3.1 核心数据表结构宠物寄养系统的后端我用了 Node.js MySQL 搭建Redis 做缓存。前期规划表结构花了大概两天时间比实际写代码的时间还长但这部分想清楚了对后期开发效率影响巨大。核心表有这么几张用户表、门店表、宠物档案表、寄养套餐表、订单表、寄养日志表、评价表。订单表是整张逻辑的枢纽字段设计上我吃了不少亏说几个关键的CREATE TABLE order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, user_id bigint(20) NOT NULL COMMENT 下单用户ID, store_id bigint(20) NOT NULL COMMENT 门店ID, pet_id bigint(20) NOT NULL COMMENT 宠物档案ID, package_id bigint(20) NOT NULL COMMENT 套餐ID, start_time datetime NOT NULL COMMENT 寄养开始时间, end_time datetime NOT NULL COMMENT 寄养结束时间, amount decimal(10,2) NOT NULL COMMENT 订单金额, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 状态0待支付 1待接单 2寄养中 3待取回 4已完成 5已取消, pay_time datetime DEFAULT NULL COMMENT 支付时间, remark varchar(255) DEFAULT NULL COMMENT 用户备注, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_store_id (store_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单状态真的不能只设计成“待支付/已支付/已完成”三个状态。宠物寄养的真实业务里主人下单后要经过店家确认有没有空位、接到宠物后开始服务、服务结束后主人确认取回中间还有可能用户主动取消或者店家爆满拒绝。我最后用了 6 个状态待支付、待商家接单、寄养中、待取回、已完成、已取消对应的操作流转会在后面的业务逻辑部分详细说。宠物档案表也要单独说。很多宠物主不止养一只宠物寄养服务是按宠物个体来算的所以订单必须关联到具体的宠物而不是笼统地关联用户。宠物档案里除了昵称、品种、年龄、性别这些基础信息我还加了“是否绝育”“疫苗接种情况”“性格标签”这几个字段它们会直接显示在商家端的接单面板上帮助店家判断是否能接待。3.2 接口设计规范与请求封装后端接口我统一走 RESTful 风格前缀是/api/v1。为什么加版本号因为小程序端发布审核有周期线上版本还在跑旧接口新版本可能已经要联调新接口了没有版本控制根本没法并行开发。所有接口返回统一格式{ code: 0, message: success, data: {} }code 为 0 表示成功非 0 表示业务异常HTTP 状态码只表示网络层状态。这个约定在前后端联调时特别有效前端拦截器只需要判断 code 就能决定是走正常流程还是弹错误提示不需要关心 HTTP 状态码的各种分支。前端的请求封装是另一个不能省的工作。uni.request 的 API 能力是够用的但直接裸用会很痛苦——每个请求都要带 token、都要处理 loading、都要错误提示。我在 utils/request.js 里封装了一个统一的请求方法// utils/request.js const BASE_URL https://api.example.com/api/v1 export function request(options) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { Content-Type: application/json, Authorization: uni.getStorageSync(token) || }, success: (res) { if (res.statusCode 401) { // token 过期跳转登录页 uni.removeStorageSync(token) uni.navigateTo({ url: /pages/user/login }) reject(res) return } if (res.data.code 0) { resolve(res.data.data) } else { // 统一弹出错误提示 uni.showToast({ title: res.data.message, icon: none }) reject(res.data) } }, fail: (err) { uni.showToast({ title: 网络异常请稍后重试, icon: none }) reject(err) } }) }) }这里有几个容易被忽略的细节uni.getStorageSync(token)每次请求都读一次 storage性能上确实有一点损耗但换来的是 token 在失效后能立刻感知不用重启小程序。请求方法返回 Promise 是为了让页面层可以用 async/await 写业务逻辑代码会干净很多。还有错误提示统一在拦截器里处理页面里就不再重复写uni.showToast了。3.3 登录鉴权与多角色管理微信小程序的登录流程可以说是每个新手都会被绕晕的地方。最核心的问题是为什么不能直接用wx.login返回的 code 去后端换用户信息因为 code 换到的是 openid 和 session_keyopenid 是用户在某个小程序下的唯一标识但它是不能直接暴露到业务后端做身份凭证的否则可能有越权风险。正确的流程是前端拿到 code 发给后端后端调用微信接口换 openid生成一个自定义的 token 返回给前端。这个 token 由后端自己控制有效期比 session_key 的过期机制更可控。宠物寄养系统里多了一种复杂度同一个用户既可以是寄养主人也可以是商家管理员。我的处理方案是用户表里加一个role字段登录时弹窗让用户选择“我是宠物主人”或“我是商家”选择后调登录接口后端校验该微信号是否能以对应角色登录商家需要后管理员预先录入手机号。返回的 token 里我用 JWT 编码了 userId 和 role后端接口通过AuthRequired注解校验角色权限。JWT 在这里比传统的 session 方案好在无状态、易扩展后续如果系统要接入管理后台同一套 token 校验逻辑可以直接复用。要注意的是小程序端的 token 过期后用户需要重新走微信登录流程所以我设置了 token 的有效期为 7 天并且加了“自动续期”机制当接口返回 401 时前端自动调用刷新 token 的接口用户完全无感。4. 核心功能模块设计与实现4.1 用户登录与授权用户登录是每个小程序的第一步也是审核时最容易出问题的地方。现在微信对 getUserProfile 的管控很严不建议再弹窗强制用户授权头像昵称而是用微信提供的“头像昵称填写能力”用户在个人中心点击头像区域微信会弹出系统自带的设置界面让用户选择头像和填写昵称前端拿到后直接传给后端保存。但登录还是需要 wx.login 的具体步骤// 微信登录 uni.login({ provider: weixin, success: async (loginRes) { // loginRes.code 是临时凭证5 分钟内有效 const data await request({ url: /auth/login, method: POST, data: { code: loginRes.code, role: this.role } }) uni.setStorageSync(token, data.token) uni.setStorageSync(userInfo, data.userInfo) } })后端拿到 code 后调用微信的jscode2session接口拿到 openid 和 session_key再查数据库判断用户是否存在不存在就创建一条新记录最后签发 token 返回。这里有个实操细节别忘了把 session_key 存在后端后面如果要做“手机号快速验证”或者“微信运动数据同步”都还需要用到它。授权这一块我用了“按需申请”的策略页面级权限在地理位置和相册这两块。首页加载时就弹窗要地理位置会让用户很反感改成用户主动点击“找附近门店”时才调用uni.getLocation这时候再申请权限转化率会高很多。4.2 首页设计门店列表与定位距离计算首页是宠物寄养系统的门面我采用的是“顶部搜索栏 定位信息 门店卡片列表”的布局。定位是这里最关键的功能因为寄养服务有强烈的地域属性用户要找的一定是离自己近、方便接送的门店。用uni.getLocation拿到用户经纬度后传给后端接口后端用 Haversine 公式计算门店与用户之间的距离按距离排序返回。计算公式不算复杂但在 SQL 里直接写会吃掉不少性能我改用 Redis GEO 做邻近门店查询。写入门店经纬度后GEORADIUS命令一行就能拿到指定半径内的所有门店 ID速度是毫秒级的。门店卡片上要展示的信息包括门店封面、名称、评分、距离、门头照、几个关键服务标签如“免费接宠”“24小时监控”“宠物零食赠送”。这里还想强调一个细节寄养服务的用户决策链路比较长卡片上最好有一个“查看环境”的入口点进去是一个图册页。我们后台上传了门店的照片前端用 swiper 轮播展示。这个功能在试运营阶段就发现用户点击率特别高比套餐内容点击率还高——果然主人都是颜值控。4.3 宠物档案管理宠物档案模块是容易被忽略但特别体现产品心的地方。我在做需求分析时发现寄养店家有很强烈的信息需求这只狗狗会不会咬人、有没有过敏史、平时吃什么牌子的狗粮、睡觉有什么习惯。这些信息如果每次寄养都让主人重新输入用户会烦如果完全不收商家接单后还得私下沟通效率低。所以我把宠物档案设计成“基础信息 生活习惯 健康信息”三块结构。基础信息是必填的昵称、品种、年龄、性别、是否绝育生活习性和健康信息选填但填写完整度会有一个进度条展示在用户端的宠物列表页上。寄养下单时用户可以一键将宠物档案的完整信息同步到订单里商家端看到的就是一份整理好的宠物资料卡接单效率大幅提升。上传宠物照片时我用了 uni-app 的uni.chooseImage需要把图片上传到云存储或后端然后拿到 URL 存数据库。这里有个性能优化点图片在本地选择时是几 MB 的原图直接上传既慢又费流量。我加了一步压缩处理用uni.compressImage把图片压缩到 400KB 以内再上传用户上传速度和后端存储压力都能得到明显优化。实测下来一个 5MB 的图片能压到 300KB 左右清晰度损失肉眼几乎看不出来。4.4 寄养套餐与下单流程寄养套餐的定价策略完全依赖于业务方技术上的重点是套餐结构的设计。一种套餐是简单的一口价如小型犬 58 元/天但现实情况更复杂不同体型的狗狗价格不同、寄养超过 5 天有折扣、节假日有浮动价格、加购遛狗服务要额外收费。我最后把套餐设计成“基础价格 计价规则”的模式{ name: 小型犬标准寄养, basePrice: 58, unit: day, rules: [ { condition: days 7, discount: 0.9 }, { condition: days 30, discount: 0.8 } ], include: [基础喂养, 每日遛狗, 视频反馈], extraServices: [ { name: 专业洗护, price: 38 }, { name: 加餐鲜食, price: 15 } ] }下单页面的核心是日期选择和价格计算。日期我用的是uni-datetime-picker组件但这里遇到过一个性能问题在 iOS 端uni-datetime-picker放在scroll-view里滚动时会因为渲染机制特殊导致选择器弹层闪烁需要在真机上反复验证。价格计算规则在前端实时算用户改日期就重新算一遍提交订单时后端再算一遍两边对得上才允许创建订单防止前端被篡改。4.5 订单状态机与商家接单订单状态流转是整个系统里最容易写乱的业务逻辑所以我画了一个特别清晰的状态机并写死在代码里待支付用户创建订单后 15 分钟内未支付自动取消待商家接单支付成功后进入待接单队列商家端可以接受或拒绝寄养中商家确认接收宠物后状态变更为寄养中这个状态会一直持续到寄养结束时间待取回寄养时间到期后状态自动变为待取回等待主人到店已完成主人确认取回订单结束已取消用户主动取消或商家拒绝接单状态变更不能直接让前端随意调接口修改我在后端加了操作权限校验每一步操作都对应一个独立接口POST /order/{id}/accept商家接单、POST /order/{id}/reject商家拒单、POST /order/{id}/checkout主人确认取回。商家端是我单独设计的一套页面结构在同一个 uni-app 项目里通过角色判断渲染不同的 tabBar。商家首页展示的是待接单队列和寄养中的宠物列表每个寄养中的宠物卡片上都有一个“添加日志”按钮点击后可以上传文字和图片这些日志会自动推送给对应的主人端。4.6 支付流程与回调处理微信支付在小程序端的流程概括起来是三步前端把订单信息发给后端后端调用微信支付统一下单 API拿到payment参数前端用uni.requestPayment唤起微信支付界面用户支付完成后微信服务器向后端配置的回调地址发送支付结果通知一个经常被忽略的点是uni.requestPayment里的参数名和微信小程序原生 API 的参数名是不同的。我在对接时认真对比了文档timeStamp注意大写 S、nonceStr、package值是 prepay_idxxx、signType、paySign一个都不能少大小写也不能错否则会报invalid sign。这里的坑我之后会专门整理一节。支付回调的后端处理也有要求幂等性。微信服务器可能会因为网络原因多次回调同一个订单后端必须做去重用订单号加支付流水号做唯一索引重复回调直接返回成功。回调返回的报文格式也要按要求组装不然微信会认为回调失败反复重试。5. 真机调试、抓包与打包上线5.1 HBuilderX 配置与模拟器调试开发环境我用的 HBuilderX它是 uni-app 官方 IDE集成了运行、调试、打包到各个平台的功能。在写代码的时候可以直接开微信开发者工具的模拟器修改代码后热更新到模拟器里。但模拟器能验证的问题有限尤其是涉及微信 API 的部分比如uni.getLocation返回的坐标系在真机和模拟器上可能就不一样。所以我养成了一个习惯每完成一个页面就用 HBuilderX 里的“运行到手机或模拟器”在微信开发者工具里扫码真机预览跑一遍关键功能。多付出的只是扫码那几秒钟但发现的问题都是真问题。5.2 真机调试与 Charles 抓包排查微信小程序的网络请求默认是加密的想用 Charles 或 Fiddler 抓包需要做一些准备工作。我的做法是在微信开发者工具里把“不校验合法域名”勾上然后设置代理到 Charles手机上也要安装 Charles 的 CA 证书并开启信任这样就能看到小程序发出的 HTTPS 请求内容。这个能力在线上问题排查时太重要了。有次用户反馈支付成功后订单状态没变我拿到了用户手机抓的日志发现请求后端接口时返回了 504。进一步排查发现是回调函数里查到门店信息时Redis 连接池耗尽导致超时整个链路就卡住了。如果只能看前端日志这个问题的定位周期会翻倍。5.3 uniapp 打包发布到微信平台的完整流程uni-app 项目做完打包前必须先处理几件事。第一件是在 manifest.json 里填写小程序的 AppID这个是微信公众平台分配的和开发者工具里的一致。第二件是把接口地址从测试环境切换成生产环境这个我建议做成配置文件用process.env.NODE_ENV区分开发、测试、生产环境打包时自动选择。HBuilderX 里点击“发行 - 小程序-微信”编译完成后会在dist/dev/mp-weixin目录下生成微信小程序代码。用微信开发者工具导入这个目录先在开发者工具里跑一遍确认没问题后再点“上传”然后在微信公众平台提交审核。审核周期一般是 1-3 天第一次做建议提前预留时间。ios 安卓 App 的打包流程是另一套方案uni-app 云打包或本地离线打包这个项目初期只做微信端以后要上 App 再另外说。这里只提醒一句App 打包需要准备签名证书安卓的签名文件一旦丢了后续更新就没法替换一定要妥善留存。5.4 上线前检查清单上线前我习惯再过一遍清单照下面这个走网络请求全部走 HTTPS且域名已经在小程序后台配置为合法域名用户隐私协议和用户授权弹窗流程完整敏感权限申请都有对应的业务场景触发支付流程在真机上跑通至少一遍确认回调成功、订单状态变更正确订单金额在小数点后两位以内没有浮点运算精度问题分享功能可用分享出来的页面能正常打开并跳转到位空数据页面和异常页面有兜底不会出现长时间白屏6. 常见问题与避坑指南6.1 微信定位权限与坐标系真机调试时用uni.getLocation在地图里展示位置发现位置偏移很严重。原因在于微信返回的是 GCJ-02 坐标系火星坐标系而如果地图 API 默认用的 WGS-84 或者后端存储的经纬度是其他坐标系就会偏出好几公里。解决办法是在后端统一做坐标系转换或者直接用type: gcj02参数让uni.getLocation返回火星坐标保持全链路一致。6.2 uni-datetime-picker 在 scroll-view 里的闪烁问题iOS 端微信小程序的渲染机制比较特殊uni-datetime-picker放在scroll-view里滚动时会出现弹层闪烁甚至无法弹出的问题。我排查了很久最后发现是组件在滚动过程中不断触发重绘导致的。常见处理方案是给scroll-view加上enhanced属性和show-scrollbarfalse或者把日期选择器移到页面层固定定位避免它和滚动事件互相干扰。这个坑在 Android 端很难测出来一定要用 iOS 真机多试几遍。6.3 支付签名错误微信支付报invalid sign是最常见的报错之一。大概率是参数拼接顺序错了或大小写问题。微信支付签名算法要求按参数名 ASCII 码从小到大排序再拼接 key 后做 MD5 或 HMAC-SHA256 加密。我排查这类问题的通用流程是把前端传给uni.requestPayment的参数打印出来和后端生成签名时用的参数比对逐一核对字段名大小写、值是否含空格、时间戳格式。6.4 图片上传失败与压缩策略图片上传的坑主要在大小限制上。微信小程序wx.uploadFile的上传大小限制是 10MB但用户相册里随手拍的照片经常超过这个限制。我的做法是选择图片后用uni.compressImage先压缩再走上传同时在uni.uploadFile的 complete 回调里清理临时文件路径防止路径泄漏到其他页面。6.5 审核被拒的常见原因小程序审核被拒在宠物寄养项目里最常见的几条原因是需要用户授权手机号却没完成微信认证个人主体不支持类目选择与内容不符涉及宠物服务的要选“生活服务-宠物”类目需要提供相应资质隐私弹窗文案不清页面存在测试数据要确保演示账号能登录且数据是真实的。每次提交前都对照微信小程序运营规范逐条自检能省掉来回提审的时间成本。7. 项目复盘费用、周期与扩展空间整个项目从需求梳理到上线我花了大约三周时间。前期数据库设计 2 天前端页面和接口联调 10 天支付对接和真机调试 3 天审核整改花了 2 天。如果是不熟悉 uni-app 的团队做周期至少翻倍。这里给准备接这类项目的人一个建议不要把工期排太满前后端联调阶段出现的问题往往比想象中多。费用方面如果完全是外包开发按当前行情大概在几万到十几万不等取决于商家端功能的复杂度和是否需要做 App 端。如果是自己维护主要成本就是服务器和备案费用轻量应用服务器一年几百元就够撑起初期的小规模运营。关于扩展空间现在这套架构已经在为后续功能留好了接口。宠物主的使用数据沉淀下来后可以做智能推荐根据犬种性格推荐匹配的寄养门店商家端可以加摄像头接入主人直接在小程序里看宠物在店里的实时状态还有“寄养日记”功能根据每天的日志自动生成宠物寄养期间的成长记录可以分享到朋友圈。这些功能的技术底座都不需要推翻重来在现有页面和接口上做增量开发就能实现。最后分享一个实际运营中得来的小经验宠物寄养系统上线后最容易让用户流失的环节不是支付也不是登录而是寄养期间“没有消息”。我们每天在固定时间上传宠物状态和照片主人收到了推送后面复购率高了许多。技术把流程串通了剩下的就要靠运营去填满那些让用户安心的细节了。