多商家美食商城开发实战：Spring Boot+uniapp+Android分享系统全解析-代码聚汇网

1. 先把这个“多商家美食分享”项目拆清楚

如果你在学校周边做过餐饮外卖相关的系统，应该能感受到这类项目和普通单店点餐小程序有很大不同。单店只需要管一个菜单、一个收银流，但校园周边美食商城天然是"多商家入驻"的形态：食堂档口、奶茶店、炸鸡店、水果捞店，各自独立经营，却又要在同一个小程序里被用户浏览、下单、收藏和分享。标题里的"分享系统"也很有讲究，它不是简单的转发功能，而是带邀请奖励机制的用户拉新链路。

我在实际做这类项目时，第一步不是写代码，而是先把角色的权限边界梳理清楚。一个校园美食商城至少包含三种角色：普通学生用户、入驻商家、平台管理员。用户能看店、点餐、领券、邀请好友；商家能上架商品、修改库存、处理订单；管理员负责审核商家、上架店铺、查看平台级数据。如果后端数据结构一开始没把"数据归属"想清楚，做到后面一定会被各种越权查询折磨到崩溃。

1.1 系统里实际上存在几种角色，权限怎么分

从真实需求出发，三端角色对应三套完全不同的接口权限。用户端走小程序的登录态，商家端需要独立的商家后台（通常做成管理端网页或子包内的商家工作台），平台管理员则需要一个总控后台。

实际的权限字段我建议直接塞在用户表里，用 role 区分，不搞复杂的RBAC权限框架。校园项目的用户量级其实不大，用Spring Security甚至有点重，一个拦截器加一个 @RequireRole 注解就够用。用户表里加 merchantId 字段，商家的所有商品、订单查询都强制带上这个ID，这是最简单也最不容易出多租户数据混乱的方案。

1.2 为什么前端选uniapp，后端选springboot

先说uniapp。这个项目的前端载体是小程序，但同时要考虑后续发Android端应用商店包（标题里专门提到了Android）。uniapp最核心的价值是一套代码同时输出微信小程序、H5和Android App，这意味着下拉刷新、分享、支付这些逻辑可以尽量只写一遍。

后端选Spring Boot的理由更直接：校园周边的小程序业务本质上是标准的CRUD加订单状态流转，Spring Boot的生态太成熟了——MyBatis-Plus做持久层、Redis做缓存和验证码存储、Sa-Token或JWT做登录态，每块都有大量现成方案。而且团队招人容易，排错资料也多。对于这种中小型业务系统，稳定性和可维护性远大于炫技。

1.3 功能架构总览：先列页面再看表

做这类项目，我习惯先列全所有页面和接口，形成一张功能脑图，再开始建表。页面侧大致是：首页（店铺列表与推荐位）、店铺主页（商品分类与详情）、下单确认页、订单列表与详情页、个人中心、邀请分享页、商家工作台（商品管理、订单管理、营业统计）。接口侧则以资源为中心划分：/api/user、/api/store、/api/product、/api/order、/api/share，每个Controller只做自己资源边界的编排，不越俎代庖。

这部分工作做完，整个项目的工程量基本就有数了。本文后面的内容，全部围绕这套体系展开，从后端数据权限到前端路由与分享链路，再到Android打包上架和真机兼容性问题。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 后端设计：多商家数据隔离与稳定的版本选型

多商家系统的设计核心是"防串店"。用户在小程序里切换店铺下单很顺滑，但数据落库时，每一笔订单必须能清晰地归属到某个商家，每一件商品也必须只能被所属商家修改。后端如果从表结构阶段没做好这种隔离，后续所有权限控制都是补丁，越补越乱。

2.1 先从建表说起：数据归属是命根子

我以简化后的核心表格来说明，具体字段可以按需扩展，但归属关系的主线不能乱：

数据表	核心字段	说明
`user`	id, role, merchant_id, openid, nickname, avatar	role区分用户/商家/管理员，merchant_id只在商家角色有值
`store`	id, merchant_id, name, logo, banner, notice	一商家最多可开一个店铺（或可扩展为多个）
`category`	id, store_id, name, sort	菜品分类，必须挂在store下
`product`	id, store_id, category_id, name, price, stock, image	商品必须归属店铺
`order`	id, order_no, user_id, store_id, amount, status	订单冗余store_id，方便商家按店铺拉取
`order_item`	id, order_id, product_name, price, quantity	下单时快照商品信息，防止商家改价影响历史订单
`share_record`	id, inviter_id, invitee_id, status	分享关系绑定

一个最常见的坑是：product 表里只写了 category_id，没写 store_id。这样做的问题在于，商家修改商品时，需要先通过分类去反查店铺，一旦分类被误删或者调整，商品的归属链就断了。最稳妥的做法是每条核心业务数据都冗余商家ID或店铺ID。冗余虽然打破了三范式，但在这个场景下是为了查询效率和数据安全。

order_item 里保存商品名称、价格快照也非常关键。校园促销活动频繁，商家改价或者下架商品是常事，如果订单明细去关联实时商品表，用户历史订单显示的价格和菜品名就会变。你肯定不希望用户在查看一周前的订单时发现"黄焖鸡米饭"变成了"黄焖鸡米饭（大份）"。

2.2 Token认证与接口权限拦截怎么做

小程序端的登录采用微信登录，流程是：前端调用 uni.login 拿到临时 code，传给后端，后端用 code 换取 openid，再生成自定义 token 返回给前端。登录态的保持比较简单，token 存在前端 storage 里，每次请求 header 里带 Authorization: Bearer token。

商家端和管理员端不用走微信登录，而是账号密码登录。这里要特别注意密码的存储，必须用 BCrypt 加密。很多初学者直接明文存密码，这类项目一旦数据库泄露，所有商家账号都遭殃，而且校园项目真的会有学生去尝试抓包或者拖库。

权限拦截我用的是拦截器加自定义注解。核心逻辑是：拦截器从 token 中解析出 userId，去 Redis 里拿用户信息，检查角色；商家接口必须校验 merchantId 是否匹配。在具体的业务 query 里，禁止出现类似 SELECT * FROM order WHERE store_id = ? 让前端传 store_id 的做法，而是应该从当前登录用户的 token 中取 merchantId。这样才能保证一个商家不能通过改参数查另一个商家的订单。

2.3 Spring Boot 版本怎么选，别一上来就追新

不少同学来问我，项目刚启动就用 Spring Boot 3.4 或者 3.5，结果遇到一堆问题。对于校园周边美食商城这个场景，我非常建议使用 Spring Boot 2.7.x 系列，而不是 3.x。原因很简单：

第一，Spring Boot 3.x 强制要求 JDK 17，而很多学校机房、老服务器甚至部署环境用的还是 JDK 8。如果你自己本地是 JDK 17 没问题，但团队协作时成员环境不一致，光统一 JDK 就要花不少时间。

第二，很多第三方库的兼容性问题会白白消耗时间。比如 MyBatis-Plus 早期版本对 Spring Boot 3 支持不完善，Flowable 工作流引擎在 Spring Boot 3 下需要额外适配。如果项目里只想用 flowable 做个简单的商家审核流程，Spring Boot 2.7 搭配 flowable 6.x 的案例资料一搜一大把，"填坑"成本最低。

第三，从需求匹配度看，这个项目根本用不上 Spring Boot 3 的新特性。Spring Boot 2.7 本来就是长期维护版本，稳定且成熟，市面上绝大多数教程也都是针对 2.x 的，遇到问题搜解决方案比冷门版本容易太多。

这背后是技术人员最容易犯的一个错："版本焦虑"。总感觉不用最新版就掉队了，但实际项目里，能用最低成本实现稳定功能的版本，才是好版本。

2.4 分享系统接口设计：参数怎么带，字段怎么落

分享系统在后端要拆成两个接口：一个是"生成分享信息"接口，另一个是"处理分享回调"接口。

生成分享时，用户点击“邀请好友”按钮，前端调后端接口，后端返回一个带 inviterId 的分享链接或小程序码。注意，inviterId 不能直接放在路径上，因为小程序码的 scene 参数只能支持 32 个可见字符，而且有限制。常见做法是：将 inviterId + 随机串 加密或混淆后放进 scene，或者在后端生成一个短码 shareCode，把 shareCode 和 inviterId 的映射存起来。这样路径参数短，也无法被轻易篡改成别人的邀请码。

处理回调时，新用户通过分享链接打开小程序，落地页读取到分享码，调后端接口上报（userAgent 里带上 openid 或临时登录态）。后端此时不着急绑定关系，而是等新用户完成注册或首次下单后，再通过 share_record 异步结算给邀请人发奖励。延迟绑定可以有效规避“先点进来但没注册，奖励发给谁”的边界问题。

3. 前端uniapp：工程目录、路由参数与跨端适配

前端是用户直接接触的部分，做得顺不顺手，决定了开发和后续维护的体感。我的经验是：先把工程目录结构定好，统一约定页面跳转、请求方式、状态管理，否则几十个页面铺开之后会非常混乱。

3.1 标准目录与微信小程序分包设计

uniapp 的工程结构里，pages 目录是主包，建议只放核心页面：首页、店铺主页、订单详情和个人中心。像商家工作台、邀请活动页这类低频页面，全部放 subPackages 分包里。主包体积控制在 1MB 以内，否则微信开发者工具会一直报主包体积超限警告。

有同学会觉得分包没意义——反正代码能跑就行。但微信小程序平台对主包大小有硬性限制（2MB 以内，超过无法上传），而且冷启动时主包越大，加载速度越慢。校园用户用的手机网络环境未必稳定，一个动辄 1.5MB 的主包，首屏加载白屏时间可能长到用户直接退出。

分包还有一个隐藏作用：分享落地页如果放在分包，配置分享路径时也要写分包路径。有热搜词专门问"明文scheme拉起此小程序配置分包路径不行"，这就是典型的分享路径和分包路径没理清楚。

3.2 全局登录态管理：storage 与会话失效处理

小程序端登录态管理，最朴素也最可靠的方式是：uni.login 拿 code，换取到后端返回的 token 后存进 uni.setStorageSync('token', res.token)，然后在请求拦截器里统一处理：

javascript复制// request.js 封装的核心逻辑
const request = (url, method = 'GET', data = {}) => {
  const token = uni.getStorageSync('token')
  return new Promise((resolve, reject) => {
    uni.request({
      url: BASE_URL + url,
      method,
      data,
      header: {
        'Content-Type': 'application/json',
        'Authorization': token ? `Bearer ${token}` : ''
      },
      success: (res) => {
        if (res.data.code === 401) {
          uni.removeStorageSync('token')
          uni.navigateTo({ url: '/pages/login/index' })
          return
        }
        resolve(res.data)
      },
      fail: reject
    })
  })
}

这里有一个必须处理的细节：token 过期时，后端返回 401，前端要清掉本地 token，并跳转登录。但小程序里有个常见问题——用户正在填订单信息，突然 token 过期被强制跳登录，回来之后填的表单全丢了。实际项目中建议做静默刷新：token 有效期设置短一点（2小时），通过 refresh_token 在请求返回 401 时自动换新。如果加了这个逻辑，用户体验会比强制跳登录好非常多。

登录后的用户信息不要全存本地，nickname、avatar 这些可以考虑只在本地存一份缓存，展示时直接用。每次冷启动用 token 调一次 /api/user/info 更新缓存，防止用户资料在后台被改之后，前端一直显示旧信息。

3.3 路由参数的获取与丢失问题

很多人刚接触 uniapp 跳转页面，都这样取参数：

javascript复制// 接受页面 onLoad
onLoad(options) {
  console.log(options.id)
}

看起来没问题，但项目跑起来后会发现一系列隐蔽问题：

问题一：参数需要编码。 如果参数里带中文、特殊字符（比如商品名"炸鸡+可乐套餐"），直接拼接在 URL 上，某些手机上会出现乱码或者截断。必须用 encodeURIComponent 编码传递：

javascript复制uni.navigateTo({
  url: `/pages/store/index?name=${encodeURIComponent(storeName)}`
})

问题二：onLoad 只在页面首次加载触发。 小程序页面实例是复用的，如果用户从 A 页跳到 B 页，再返回 A 页，A 页的 onLoad 不会再触发。如果 A 页的展示内容依赖路由参数（比如从不同入口进来展示不同店铺），应该把参数读取放在 onShow 里，或者维护一个页面栈的参数缓存。热搜里专门问"uniapp中获取路由的参数"，很大概率就是遇到了这种场景。

问题三：分享链接的路由参数更复杂。 分享出去的落地页路径如果是 /pages/store/index?shareCode=xxx&storeId=2，微信体系里会经过一层 scene 解码。小程序码的 scene 参数需要 decodeURIComponent 一次才能拿到真实值，不处理的话 shareCode 是一串编码后的乱码。我在代码里写了个工具函数专门解析：

javascript复制export function getShareParams(options) {
  if (!options || !options.scene) return null
  const scene = decodeURIComponent(options.scene)
  const params = {}
  scene.split('&').forEach(item => {
    const [key, value] = item.split('=')
    params[key] = value
  })
  return params
}

路由参数这块，开发时多花半小时，后期会省出几天排查问题的时间。

3.4 不同平台的接口地址切换

uniapp 最容易被忽略的一个坑是：平台不同，请求地址不同。真机预览时，Android 手机不能通过 localhost 访问你电脑上的后端，要填电脑的局域网 IP；微信开发者工具里又要用不同的域名；上线后还要替换成 HTTPS 正式域名。

我在项目里习惯维护一个 config.js：

javascript复制// config.js
const ENV = {
  development: 'http://192.168.31.123:8080',  // 局域网后端地址，调试用
  production: 'https://api.example.com'        // 正式环境
}

// #ifdef MP-WEIXIN
export const BASE_URL = ENV.development
// #endif

// #ifdef APP-PLUS
export const BASE_URL = ENV.production
// #endif

同时，微信小程序上线要求所有请求域名必须在公众平台配置合法域名，且必须是 HTTPS。开发阶段可以在开发者工具里勾选“不校验合法域名”，但上线前一定要换成正式的 HTTPS 地址。很多新人在上线时才发现这个限制，被迫改配置重新发版，完全可以在开发初期就规避。

另外建议所有接口走同一个网关前缀，例如 /api。后期如果要做接口鉴权、限流或者日志埋点，在网关层统一处理比在每个接口里都加一遍省事太多。

4. 分享推广模块的完整链路：拉新、绑定与转化

“校园周边美食商城分享系统”中的“分享”二字，绝对不是页面右上角默认的 onShareAppMessage 那么简单，背后是一整套邀请关系识别、用户绑定、奖励派发的逻辑。这章把全链路拆开讲透。

4.1 分享要解决的核心问题：怎么知道是谁带来的用户

假设一个场景：学生 A 把奶茶店的小程序分享给同学 B，B 打开小程序并下单了一杯奶茶。你作为平台方，需要判断：B 是 A 拉来的新用户吗？A 能获得奖励吗？

要回答这个问题，核心是建立一种“传播令牌”机制。小程序里能携带信息的核心载体有三个：普通链接路径参数、小程序码 scene 参数、以及分享卡片（如果做高级功能，还能带自定义参数）。最简单实用的方案是：所有分享出去的页面，都在路径后面加上 inviterId 或 shareCode。

但直接明文拼接 inviterId 有个风险：B 可以篡改链接里的 inviterId，把邀请人换成自己。所以我在项目中采用"shareCode"方案，后端生成两条短码派给用户，数据库记录 shareCode -> inviterId 映射，过期时间 7 天。用户拿到短码后，即使修改短码，也只是映射到一个不存在的邀请人，无法薅羊毛。

4.2 后端生成带参数小程序码与分享海报

实现流程如下：

前端点击“邀请好友”，调 POST /api/share/create，后端记录分享行为（谁分享了哪个店铺），返回 shareCode 和一条带参数的页面路径。
前端把这个路径传给 uni.getShareInfo 或后端生成小程序码的接口。如果只用微信小程序，推荐后端调用微信官方接口 getwxacodeunlimit，传 scene=shareCode，得到的小程序码图片直接下发前端展示。
海报背景图可以由后端把小程序码贴到一张海报底图上，生成一张完整分享图片。这里建议用 java.awt 的 BufferedImage 在后端合并图片，避免前端 canvas 绘制在不同机型上出现尺寸偏移问题。

后端生成海报的好处是：前端代码简单，且端上表现完全一致。缺点是多一次网络请求。对于校园场景，更在意的是分享海报在朋友圈、聊天里是否清爽、是否带店铺招牌和优惠信息，所以后端合并海报的投入很划算。

4.3 onShareAppMessage 被全局方法覆盖：分享函数怎么写才不崩

uniap 项目里，如果要自定义分享标题、图片、路径，最常见的坑是 onShareAppMessage 被覆盖。很多人在每个页面的 methods 里都写一个 onShareAppMessage，一旦某个页面忘了写，分享出去的默认卡片就是没有参数路径的，导致邀请链路直接断掉。

我采用的方案是维护一个全局的分享方法，在 App.vue 的 onLaunch 或者页面的 mounted 里统一设置：

javascript复制// 全局分享设置，尽量在每个页面都拉起默认分享行为
export function setShare(shareParams) {
  // #ifdef MP-WEIXIN
  uni.showShareMenu({
    menus: ['shareAppMessage', 'shareTimeline'],
    success: () => {}
  })
  // #endif
}

但 onShareAppMessage 的返回值需要每个页面单独编写。为了不被覆盖，我的做法是封装一个 shareMixin：

javascript复制// shareMixin.js
export default {
  onShareAppMessage() {
    const shareCode = this.shareCode || uni.getStorageSync('myShareCode')
    return {
      title: this.shareTitle || '校园美食福利',
      path: `/pages/store/index?shareCode=${shareCode}&storeId=${this.storeId}`
    }
  }
}

然后每个需要分享功能的页面 mixins: [shareMixin]，页面自身的分享函数不再定义，只维护 data 里的分享参数。这样无论从哪个页面点右上角分享，都能带上正确的推广参数，不会再出现“用户分享了，但邀请人根本没被记录”的窘境。

需要特别注意，小程序分享无法直接读取被分享者的点击参数到 App 内部。你只能依靠路径参数。所以落地页在 onLoad 时，一定要第一时间解析参数并上报给后端，不要等用户注册完成才上报。

4.4 邀请奖励与状态机的落地时序

奖励逻辑我建议设成简单的状态机：待生效 -> 已生效 -> 已作废。

新用户 B 通过 A 的分享码打开小程序时，前端上报 shareRecord，此时记录为待生效。如果 B 完成注册（或完成首单），后端结算服务把这条记录改为已生效，给 A 发放积分或优惠券；如果 7 天内 B 没有完成转化，这条记录就自动作废。

实际开发时，最好把这段逻辑做成异步任务。比如用户支付订单后，支付回调成功了，先更新订单状态，再发送一条 MQ 消息给积分服务。校园项目量级不需要引入太重的消息队列，可以用 Spring 的 @Async 或 Redis 延迟队列实现。直接在支付回调里同步发奖励不是不行，但一旦奖励接口里调用了外部接口或者短信服务，把支付成功主流程拖慢了，用户端体验会很糟糕。

5. Android打包与上架：从uniapp工程到应用市场

前面讲的都是代码层面的东西，但做了这么多，项目最终要变成能装在 Android 手机上的 App，这条路其实有不少隐藏关卡，尤其当你第一次把 uniapp 工程打成 App 包时。

5.1 manifest.json 配置：别漏权限，也别滥用权限

uni 的 Android 打包，最经常出问题的地方就是 manifest.json 里的模块权限配置。访问摄像头、定位、相册这些能力，如果你在代码里用了 uni.chooseImage 但没有在 manifest 里勾选对应的模块，云打包后功能就会静默失败。

核心建议是：只声明真实用到的权限。校园美食项目一般需要：

网络访问（默认）
定位权限（首页推荐附近店铺）
存储权限（保存分享海报到相册）
相机权限（如果要做拍照评价）

但不要勾选短信、通讯录、通话记录这些明显无关的权限。应用市场上架审核时，权限说明必须和隐私政策一一对应，多一个权限就多一份被拒的风险。

另外，manifest.json 里的 appid 和 android 包名要提前定好。包名一旦上了市场，以后就不能改了，建议用自己的域名倒序写，例如 com.yourname.campusfood。

5.2 证书生成、签名与混淆

uniapp 云打包时需要用 Android 证书。创建证书很容易，命令行一行 keytool -genkey -alias campusfood -keyalg RSA -validity 20000 -keystore campusfood.keystore 就能生成，但要记住几个细节：

证书密钥库密码和应用签名密码要妥善保存，丢了基本无法换证书升级。
签名算法建议选 SHA256 以上，部分 Android 7.0 以上设备已强制要求。
uniapp 云打包时要正确填证书别名和密码，否则打出来的包会无法安装。

混淆这块，uniapp 离线打包时默认有自己的混淆规则，但云打包通常不会开启严格混淆，因为 uniapp 的 JS 逻辑已经经过 js 混淆处理。如果你用原生插件，才需要关注 Android 端的混淆规则问题，否则不用过度担心。

5.3 Android 文件路径权限与内容提供者的大小坑

运行时从 content:// 或者 file:// 读取图片，在 Android 7.0 之后发生了很大变化。直接用绝对路径访问文件经常遇到权限拒绝，尤其在 Android 11 之后，应用默认只能访问自己专属目录和公共媒体目录，访问其他应用的 data 目录或者直接用外部存储路径，会直接抛 FileNotFoundException 或 SecurityException。

在 uniapp 中，最典型的场景是：用户在 App 里选图片上传头像，这是通过系统文件选择器，系统会返回一个 content:// 开头的 URI。如果你拿到这个 URI 之后，尝试按“字符串拆分出文件路径再去 new File()”，在 Android 11 上基本会失败。正确姿势是使用 uniapp 的 plus.io API 或其他文件解析能力，把 content URI 解析成应用可读的资源，不要自己手工拼路径。

另外，Android 11 禁止某些应用上网 这个话题，通常不是系统限制，而是应用没有声明网络权限，或者开发版禁用了网络。遇到这类问题，先检查 manifest 有没有 INTERNET 权限，再看是不是开了省电模式或流量限制。

5.4 上架安卓应用市场的详细流程与材料

做校园项目，常见的上架渠道是华为、小米、OPPO、vivo 应用商店，以及腾讯应用宝。每家市场对资质要求大同小异，但有一些共用材料要提前准备：

材料	说明
软件著作权证书	首次上架几乎必须，要提前1-2个月申请
隐私政策	必须在 App 内可访问，且与申请的权限一一对应
应用图标与截图	分辨率按要求提供，截图要真实对应界面内容
测试账号	如果 App 某些功能需要登录，必须提供可用的测试账号

隐私政策是审核中很高频的拒绝理由。你的 App 首次启动必须有弹窗，在用户同意之前，不能收集设备信息、不能启动初始化 SDK。如果你用了 uni 统计、地图 SDK、推送 SDK，这些基本都属于隐私采集行为，需要明确列出用途。有热搜词专门问“uniapp ios app当用户不同意隐私政策及用户协议时退出app的代码如何实现”，这种问题在 Android 审核中同样会出现。最佳方案是做一个启动拦截页，不同意就直接 plus.runtime.quit()，不让用户进入任何其他页面。

应用市场上架审核还需要注意：如果你接入了第三方统计或推送服务，需要提供相关 SDK 的隐私政策说明，否则可能被判定为“违规收集个人信息”。审核周期一般在 3-7 天，但如果是第一次上架，反复被驳回再修改的情况很常见，至少要预留两周。

6. 真实项目中躲不过去的兼容性坑

这一节写几个我实际项目中踩过、且热搜词里频繁出现的兼容性问题，每一个都不是致命错误，但都极其消耗时间。希望在你看完这篇文章后，能少在这类问题上熬夜。

6.1 手机软键盘遮挡输入框

用户在小程序里填写收货地址或备注时，Android 手机上软键盘弹起后，经常把输入框和当前聚焦的区域挡住，用户完全看不见自己在输入什么。

原因在于，部分 Android 机型的 windowSoftInputMode 是 adjustResize，但 uniapp 里的页面是 webview 渲染，软键盘弹出时页面视口高度没有正确压缩，导致被遮挡。处理办法有以下几层：

第一，在 pages.json 里找到对应的页面，设置 app-plus 的软键盘模式：

json复制{
  "app-plus": {
    "softinputMode": "adjustResize"
  }
}

第二，如果仍然遮挡，考虑用 uni.pageScrollTo 在输入框聚焦时手动滚动到可视区域。不要自己写监听键盘高度的 JS 逻辑，不同机型返回的高度值差异很大，维护成本极高。

还有一个小技巧：把页面的核心操作按钮（比如“提交订单”）改成吸底布局（fixed 定位到底部），这样即使键盘顶起内容，按钮依然可见，用户下单流程不容易被中断。

6.2 下拉刷新与页面滚动冲突

校园美食商城首页通常会做下拉刷新手势，但同时首页内容又很长、需要上下滚动。如果处理不当，会出现两种情况：一是下拉刷新触发太灵敏，用户正常往下滚动时误触刷新；二是页面滚动条已经到顶但下拉刷新拉不动。

这个问题的核心不是代码写错了，而是对小程序页面滚动机制理解不到位。uniapp 下拉刷新推荐使用 enablePullDownRefresh，它会由小程序框架原生处理，几乎不存在和 scroll-view 的冲突。但如果你自己用了 <scroll-view> 并开启了 refresher-enabled，就要小心了。

我的建议是：首页这种整页刷新场景，直接用 pages.json 里配 enablePullDownRefresh，不要额外包一层 scroll-view。而店铺分类这种局部滚动列表，才用 scroll-view 的 refesher。不能在同一个页面上既启用页面级下拉刷新，又在局部包一个带刷新能力的 scroll-view，两个手势同时存在，用户体验一定会混乱。

6.3 renderjs 播放录制的 mp4 没有画面

如果你在 uniapp 的 App 端用 <video> 播放用户使用手机录制后上传的 mp4，有时会出现“有声音无画面”或“黑屏但进度条在走”的情况。原因是部分 Android 手机录制的视频编码格式不是 H.264，而是 H.265（HEVC），或者视频封装里的旋转角度信息不被解码器正确识别。

我在项目中遇到这个问题后，查了一圈发现根因大多在两处：一是用户的视频是竖屏录制，带 rotation 元数据，某些解码器不识别旋转信息就黑屏；二是视频编码格式不是广谱支持的 H.264 Baseline/Main 档。

对应解决方案，在服务端（项目是 Spring Boot）用 Java 调用 FFmpeg 做统一转码：

bash复制ffmpeg -i input.mp4 -vcodec h264 -preset fast -crf 28 -vf "scale='min(720,iw)':-2" output.mp4

这段命令把视频统一转成 H.264 编码，宽度限制为不超过 720，保证绝大多数 Android 和 iOS 设备都能正常播放。不要在前端直接处理视频转码，uniapp 前端视频处理能力很有限，涉及到性能与电池，更应该在服务端做。

对于 render.js 的热点问题，我的建议是尽量少用 renderjs 做视频播放。如果页面需要类似抖音的全屏滑视频列表，优先用原生的 swiper 包 video，或者在后端做一次转码，以避免各种机型上的解码兼容问题。

6.4 隐私政策弹窗与不同意退出逻辑

很多第一次上架的开发者，疑惑为什么不加隐私弹窗可以在开发者工具里跑得好好的，一上架就被拒。这是因为应用市场审核会一条条核对隐私政策声明与实际权限调用行为。

个人强烈建议：隐私弹窗逻辑不要依赖第三方 SDK 去实现，自己在 App.vue 的 onLaunch 里做一道控制。

第一步，首次启动时弹窗提示“欢迎使用，请阅读并同意用户协议与隐私政策”，底部两个按钮：同意并继续、不同意并退出。

第二步，用户点击“同意”后，再调用 uni.login、初始化地图和统计 SDK。有些 SDK 在初始化时就会默默采集设备信息，如果不进行“先同意再初始化”的控制，审核时极容易被判定违规。

第三步，用户点“不同意”，直接退出进程。代码实现如下：

javascript复制// 在应用启动的入口文件里判断
if (!uni.getStorageSync('hasAgreePrivacy')) {
  uni.showModal({
    title: '提示',
    content: '需要您同意隐私政策后才能继续使用',
    confirmText: '同意',
    cancelText: '不同意',
    success: (res) => {
      if (res.confirm) {
        uni.setStorageSync('hasAgreePrivacy', true)
        // 继续初始化登录等逻辑
      } else {
        // #ifdef APP-PLUS
        plus.runtime.quit()
        // #endif
        // #ifdef MP-WEIXIN
        uni.exitMiniProgram()
        // #endif
      }
    }
  })
}

一个小坑是：部分安卓手机上 plus.runtime.quit() 退出后，App 的进程并没有被杀干净，再次点开应用图标后直接恢复了之前的页面栈。这种情况可以在首页的 onShow 里再次检查用户是否已同意，如果前后不一致则强制回弹到启动页重新选择。上架的坑基本都是这个流程里补出来的。

7. 这类项目真正难的不是技术，而是系统思维

把每个部分的开发经验都拆解完后，再回头总结这个项目，我认为它真正难的并不是某个单一技术栈的运用，而是全局的系统思维：从用户刷到分享链接打开小程序，到注册、选店、下单、支付，再到商家接单、平台统计收益，这是一个完整闭环。任何一环缺失或体验不畅，都会导致整个链条中断。

我在开发此类项目中最大的体会是：先把业务边界定死，再设计数据库和接口，最后才是界面绘制。如果你一开始直接上手画页面，边写边想表结构，大概率会陷入反复重构的泥潭。建议拿到需求后，花至少半天时间画一张完整的角色-功能-页面-接口-数据库的表格，确认每一层之间的对应关系，然后再进入编码阶段。

另外，多商家系统一定不要被“看起来简单的 demo”欺骗。单店商城你可能用一个订单表就够了，但多商家模式下，订单、商品、收益、分享关系的归属权必须从一开始就设计清晰。数据归属的隔离做不好，后期每一次新增功能都是在雷区上行走。

如果这篇文章只保留一个建议，我希望你记住：做项目时，不要迷信最新版本，也不要痴迷高端架构，而是根据业务需求，选择最成熟、资料最全、团队最容易维护的方案。uniapp 加 Spring Boot 的组合确实是校园级应用的“黄金搭档”，关键在于你怎么把这个组合用稳、用好。

多商家美食商城开发实战：Spring Boot+uniapp+Android分享系统全解析