简介：这是一份面向微信小程序初学者与进阶开发者的仿美团外卖实战源码项目，聚焦于餐饮类O2O业务场景的完整功能实现，涵盖首页推荐、餐厅浏览、菜品详情、购物车管理、地址维护、订单提交、支付模拟、评价反馈及退款申请等核心流程。资源共91个文件，包含19个JS逻辑文件（如app.js、index.js、submitOrder.js）、17个JSON配置文件（含页面路由与窗口设置）、17个WXSS样式文件、16个WXML结构文件及18个PNG图像资源，整体包体仅953KB，轻量易读。已有778人学习下载，适合通过真实业务模块理解小程序生命周期、页面通信、API调用（如腾讯地图SDK qqmap-wx-jssdk.min.js）、utils工具复用机制及pages目录下多页面协同设计。项目结构规范，页面命名语义清晰（如orderDetail、applyRefund、allEvaluate），配套README.md说明文档，是掌握小程序工程化开发与外卖类应用架构的优质学习样本。 说一个我最近接手的项目。一个朋友发来一个压缩包，名字叫“仿美团外卖微信小程序.rar”，让我帮忙看看能不能跑起来，能不能直接改造成商业项目。打开一看，是个典型的仿美团外卖原生微信小程序项目，代码量不少但结构乱，网上能搜到的版本都大同小异。但这并不妨碍它成为学习微信小程序开发的好素材，尤其是你想做外卖、点餐、同城生活服务这类小程序时，这个项目的价值密度相当高。

我花了大概一周时间把这个项目从“能看”改到了“能跑、能改、能上线”，期间踩了不少坑，也把它内部很多新手容易卡住的点给理清了。这篇文章就直接围绕这个项目来写，讲一下它的整体设计思路、核心模块实现、后端对接方案，以及我整理出的常见问题排查手册。想拿类似项目练手或做课程设计的同学，这篇文章应该能帮你少走不少弯路。

1. 拿到一个仿美团外卖小程序，先看什么

打开压缩包之前，先别急着往微信开发者工具里拖。先看看目录结构，心里有个底，再决定怎么处理。

1.1 项目目录结构拆解

我解压之后大概扫了一眼目录，典型的原生小程序结构，没有用uni-app或者Taro这类跨端框架，这对新手来说其实是好事，因为原生小程序写出来的代码，运行逻辑和坑都是微信官方那一套，学习价值更高。

project/
├── app.js                  // 全局逻辑，初始化、获取用户信息
├── app.json                // 全局配置，页面路由、tabBar、window
├── app.wxss                // 全局样式
├── project.config.json     // 项目配置，appid、编译设置
├── sitemap.json            // 搜索收录配置
├── utils/
│   ├── api.js              // 封装网络请求
│   ├── util.js             // 公共方法（格式化时间等）
│   └── config.js           // 全局配置（接口地址、密钥）
├── images/                 // 静态图片资源
├── components/             // 自定义组件
│   ├── goods-card/         // 商品卡片
│   └── tab-bar/            // 自定义tabBar（部分版本有）
├── pages/
│   ├── index/              // 首页，入驻商家列表
│   ├── order/              // 订单列表
│   ├── cart/               // 购物车（可能是半屏弹窗形式）
│   ├── user/               // 个人中心
│   ├── category/           // 侧边分类商品页（模仿美团左右联动）
│   ├── search/             // 搜索页
│   └── detail/             // 商家详情页

这里有个小细节：大部分从网上下载的仿美团项目， project.config.json 里用的 appid 是 touristappid ，也就是游客模式。你导入项目后第一件事应该是换成自己的测试号或者注册一个企业主体的小程序 appid，否则很多接口和云开发功能都跑不起来。

1.2 哪些页面能复用，哪些要重写

网上流传的这版仿美团外卖项目，页面覆盖度其实挺高的。首页（定位、搜索框、金刚区、商家列表）、点餐页（左侧分类、右侧菜品列表）、购物车（商品增减、清空、结算）、订单页（状态切换、订单卡片）、个人中心（头像、菜单列表）都有。

但有几个地方基本都要重写：

• 地图与定位模块 ：美团外卖的首页顶部会展示当前定位，商家列表也按配送范围过滤。网上的版本很多直接用 wx.getLocation + 腾讯地图逆地址解析，但如果你没有申请腾讯地图 key，这块就白屏。
• 支付模块 ：很多网上的“仿美团”都是静态页面模拟，点了“结算”就跳转到“支付成功”模拟页。真正要跑通微信支付，需要商户号、企业主体、支付证书，个人开发者做不了。
• 登录模块 ：很多版本用的是 wx.getUserProfile 来拿用户头像昵称，但这个接口从基础库2.27.1版本开始已经调整为需要用户主动点击行为触发，且返回的昵称是“微信用户”类似形式，不能直接用来做数据库存用户身份，需要走后端 openid 体系。

所以，如果你只是拿来练习前端布局和交互，这个项目够用；如果你想做成真正能用的外卖点餐小程序，后端部分基本要从零搭。

2. 功能模块背后的技术点拆解

仿美团外卖看似简单，就是一个列表页+一个商品页，但里面的技术点其实不少。我拆开讲几个最核心的，这些都是面试和实际开发中经常考的东西。

2.1 首页商家列表的数据模型设计

商家列表不是简单的一个数组渲染就完了。你看看美团的商家卡片，里面有店铺名、评分、月售、起送价、配送费、配送时间、距离、优惠活动，这些字段背后对应一套完整的数据模型。

典型的数据结构类似这样：

{
  "id": 1001,
  "name": "川味坊",
  "logo": "https://...",
  "score": 4.8,
  "monthly_sales": 1200,
  "min_price": 20,
  "delivery_fee": 3,
  "delivery_time": "30分钟",
  "distance": "1.2km",
  "promotions": [
    {"type": "满减", "desc": "满30减5"},
    {"type": "新客立减", "desc": "首单立减8元"}
  ]
}

在真正从后端接口拉数据时，尽量把 score 这类数值用 number 类型返回，不要把 "4.8" 变成字符串返回。因为小程序端做排序、过滤的时候，字符串转成数字容易出bug，尤其如果你从云开发数据库直接拿数据，字段类型不对结果就是排序完全乱掉。

另外还要注意一点，如果要从后端接口按距离排序、按销量筛选，很多网上的项目直接把全部商家数据拉到本地再filter。数据量小还行，真实场景商家可能有上万个，这种做法直接卡死页面。应该是后端分页 + 条件查询。

2.2 左右联动分类点餐页的实现思路

仿美团外卖项目里最值得学习的就是点餐页的左右联动。左边是分类列表，右边是对应分类下的商品，滚动右边列表时左边分类自动高亮，点击左边分类时右边滚动到对应区域。

这个功能的难点不在UI，而在滚动关联处理。网上很多版本用的是简单的 scroll-view ，左边和右边各一个 scroll-view ，然后监听左边的 click 事件，用 wx.pageScrollTo 或者 scroll-view 的 scroll-into-view 来跳转。这在小数据量下可行，但真实场景会有一个问题：右边列表不只是当前分类下面的几个商品，而是所有分类的商品都铺在一个长列表上，每个分类前面加一个标题栏。用小程序的 scroll-view 滚动时拿不到“当前滚动到了哪个分类”的准确位置。

这里我建议的处理方案：

• 右边不走 scroll-view ，而是直接用页面级滚动 onPageScroll ，拿到 scrollTop 之后跟每个分类标题的偏移量做对比，判断当前分类索引。
• 左边点击时，记录目标分类标题的 offsetTop ，然后 wx.pageScrollTo({ scrollTop: targetOffsetTop }) 。
• 每个分类标题的 offsetTop 在渲染完成后用 wx.createSelectorQuery() 一次性获取并缓存。

给你一个核心参考实现：

// 获取所有分类标题的offsetTop
getCategoryOffset() {
  const query = wx.createSelectorQuery()
  const tasks = this.data.categories.map((item, index) => {
    return new Promise((resolve) => {
      query.select(`#cat-${index}`).boundingClientRect((rect) => {
        resolve(rect.top - this.data.statusBarOffset) // 减去导航栏/状态栏高度
      }).exec()
    })
  })
  Promise.all(tasks).then((offsets) => {
    this.setData({ categoryOffsets: offsets })
  })
}

// 页面滚动时判断当前分类
onPageScroll(e) {
  const scrollTop = e.scrollTop
  const offsets = this.data.categoryOffsets
  let current = 0
  for (let i = 0; i < offsets.length; i++) {
    if (scrollTop >= offsets[i] - 20) {
      current = i
    }
  }
  this.setData({ activeCategory: current })
}

这里有几个隐藏坑要注意：

• boundingClientRect 拿到的 top 是相对视口的，不是相对页面的，所以必须加上当前滚动值才能算页面偏移。
• 模拟器上 scrollTop 和真机上 scrollTop 的取值会有差异，尤其是有自定义导航栏的时候，顶部高度会有偏移，建议真机调试时多试几个位置。
• 左侧分类高亮的样式，不要用setData更新整个列表的 activeCategory 后再select当前项，直接在数据里对比渲染 class 即可。

2.3 购物车的状态管理与数据流

购物车是仿美团外卖项目里状态最复杂的一个模块。它不是一个独立页面，而是悬浮在商品列表页底部的半屏弹窗，同时还要暴露出商品总数量、总价格、购物车列表等状态。

这些项目普遍的问题是把购物车数据直接放在页面 data 里，然后切换页面就丢。正确做法是把购物车提升到全局状态，可以考虑随项目引入 mobx-miniprogram 或者用微信官方的“全局数据”能力。

我改造这个项目时用了最简单的全局状态方案，在 app.js 里定义全局 globalData.cart ：

// app.js
globalData: {
  cart: [],
  cartCount: 0,
  cartTotalPrice: 0
}

// 页面里直接拿到全局购物车
const app = getApp()

updateCart(goods) {
  const cart = app.globalData.cart
  const index = cart.findIndex(item => item.id === goods.id)
  if (index > -1) {
    if (goods.count === 0) {
      cart.splice(index, 1)
    } else {
      cart[index].count = goods.count
    }
  } else {
    cart.push(goods)
  }
  app.globalData.cartCount = cart.reduce((sum, item) => sum + item.count, 0)
  app.globalData.cartTotalPrice = cart.reduce((sum, item) => sum + item.price * item.count, 0)
  this.setData({
    cartCount: app.globalData.cartCount,
    cartTotalPrice: app.globalData.cartTotalPrice
  })
}

这种方式对简单项目够用。但你要注意一点：如果有多个页面同时操作购物车，比如商品列表页和商品详情页都加入了商品，回到列表页时 onShow 里需要重新从 globalData 同步购物车数据，否则UI不同步。这是新手最容易忽略的地方。

如果是更复杂的项目，建议直接上 MobX，把购物车做成可观察对象，任何页面操作自动更新。我在后续的几个商业项目里都是用 MobX 管购物车，体验好很多。

3. 后端对接与数据交互的最佳实践

很多下载下来的仿美团项目，前端页面很漂亮，但根本没有后端接口，数据全是写死在JS里的。如果只是做前端练习没问题，但如果要跑通整个点餐流程，后端这块必须自己接。

3.1 request请求封装的细节考量

网上的项目基本都会在 utils/api.js 里封装一个 request 方法，但大多数封装得过于简陋，就一个 wx.request 包了一层。真实场景下，至少要处理这些情况：请求拦截、响应拦截、token过期自动跳转登录、错误提示统一处理、loading管理、请求超时。

我改造后的封装核心部分：

// utils/request.js
const request = (url, method = 'GET', data = {}) => {
  return new Promise((resolve, reject) => {
    wx.showLoading({ title: '加载中' })
    wx.request({
      url: `${BASE_URL}${url}`,
      method,
      data,
      timeout: 10000,
      header: {
        'Content-Type': 'application/json',
        'Authorization': `Bearer ${getToken()}`
      },
      success: (res) => {
        if (res.statusCode === 200) {
          // 业务码判断
          if (res.data.code === 0) {
            resolve(res.data.data)
          } else if (res.data.code === 401) {
            // token过期，重新登录
            handleUnauthorized()
            reject(res.data)
          } else {
            wx.showToast({ title: res.data.msg || '请求出错', icon: 'none' })
            reject(res.data)
          }
        } else {
          wx.showToast({ title: `服务器异常(${res.statusCode})`, icon: 'none' })
          reject(res)
        }
      },
      fail: (err) => {
        wx.showToast({ title: '网络异常，请检查网络', icon: 'none' })
        reject(err)
      },
      complete: () => {
        wx.hideLoading()
      }
    })
  })
}

module.exports = { request, get: (url, data) => request(url, 'GET', data), post: (url, data) => request(url, 'POST', data) }

注意几个容易出问题的地方：

• timeout 属性是基础库 2.10.0 之后才支持的，如果项目要兼容老版本，还需要在 app.json 里配置 networkTimeout 。
• wx.request 的 url 必须是合法域名，且必须配置在微信公众平台后台的 request 合法域名里，开发调试可以勾选“不校验合法域名”，但上线前一定要配好。
• 非 https 的接口在正式环境会被微信直接拦截，这就涉及热词里提到的“非443端口”问题。微信官方明确要求生产环境必须 https 且默认 443 端口，如果后端只用了 8080 端口或者用了 http ，真机调试直接请求失败。本地开发想绕过，只能在开发者工具里勾选不校验域名，并且真机预览时需要打开“调试模式”。

3.2 用云开发还是自建后端

这个项目要跑通数据交互，有两个方向：微信云开发，或者自建后端+传统API。

微信云开发 适合个人项目和学习项目，优势是：

• 不需要自己买服务器、域名、备案。
• 数据库直接小程序端读写，天然免鉴权（可以配置权限）。
• 自带云函数，可以处理支付回调、定时任务等后端逻辑。

劣势是：

• 云开发数据库是非关系型数据库（类似 MongoDB），不适合复杂事务。
• 如果后续要把小程序能力迁移到 App 端，云开发的架构不通用。

自建后端 适合要长期运营的项目，用 Node.js、Java、Go 都行，数据库用 MySQL，走传统 RESTful API。但你要处理域名备案、HTTPS证书、服务器运维等问题。

热词里有个“微信小程序云开发流程”，我多说一句云开发的上手路径。在 app.js 里配置好 wx.cloud.init({ env: 'your-env-id' }) 之后，你可以在开发者工具左侧栏看到“云开发”入口，里面能创建集合（相当于数据库表）、上传云函数。前端用 wx.cloud.database() 就能操作数据库，查询语法类似 MongoDB。

但注意，云开发数据库的权限设置非常关键。默认权限下，用户只能读写自己创建的数据，如果你想做一个所有用户都能查看到商家列表的“公开读”场景，需要在集合权限里改成“所有用户可读，仅创建者可写”或自定义安全规则。

3.3 图片存储方案：前端直传还是后端转发

热词里有个“微信小程序 前端能直接上传文件到r2吗”，这个显然是最近大家被对象存储折腾得比较多的一个问题。这里我把图片处理的几种方案讲清楚。

外卖项目里商家肯定要传菜品图片、店铺图片，这就涉及文件上传。

方案一： wx.uploadFile 直接传到自己的后端，由后端转发到对象存储。这个方案多了一次转发，效率低，而且后端要处理文件流，代码复杂度高。

方案二：小程序端先用 wx.uploadFile 传到微信云存储，再用云函数处理。这个方案好处是不用自己买对象存储，但只能用于微信生态内。

方案三：小程序端直接获取云存储/对象存储的临时上传凭证，然后前端直传。这个方案最高效。比如阿里云 OSS 的 STS 临时授权、腾讯云 COS 的临时密钥，前端拿到 credentials 后直接 PUT 文件到存储桶。

至于 r2 ，Cloudflare R2 是可以直接存图片的，但它给的是一个 S3 兼容接口。小程序端直传 R2 理论上可行，需要你先从自己的服务端签一个预签名 URL，然后用 wx.uploadFile 或者 wx.request 的 PUT 方法上传。实际操作中很多开发者遇到跨域和签名格式问题，我的建议是：既然在小程序里混，优先用微信云存储或者腾讯云 COS，R2 还是留给 Web 端用更省心。

4. 项目改造过程中的高频问题与排查记录

这一节我把实际操作中调试这些仿美团项目时遇到的问题集中过一遍。这些问题在热词里也反复出现——因为它们是微信小程序开发里极具普适性的坑。

4.1 tab切换白屏问题

热词里有一条“原生微信小程序tab页面切换会白屏一瞬间”。这个问题在仿美团项目里尤其明显，因为首页要加载的数据量大，路由切换频繁。

白屏的原因通常是：切换 tab 时旧页面被卸载，新页面首次渲染需要时间，如果新页面有大量同步的 setData 或者在 onLoad 里跑了耗时同步逻辑，首帧渲染会卡顿。

解决思路：

• 优化 onLoad 和 onShow 里的事情，不要同步请求所有数据，先渲染骨架屏，再异步加载实际内容。
• 首屏数据只请求核心模块，其他模块用并发或延迟加载。
• 检查是否有多个 setData 连续调用，尽量合并成一次。
• 如果白屏严重，可以使用 wx.startPullDownRefresh 和 preloadPage 预加载策略。微信官方提供了 wx.preloadPage 能力，可以在空闲时预先加载页面，减少切换白屏感。

具体到美团外卖首页，我在改造时的做法是：首页先渲染定位、搜索框、金刚区这几块静态或轻量数据，商家列表用 骨架屏 占位，等数据返回后再填充。切换 tab 时不要全部重新加载，用 onShow 判断数据是否需要刷新，比如购物车数量变了才更新，其他数据不重新拉接口。

4.2 atob函数用不了的问题

热词里“微信小程序 base64解码 atob函数用不了”也是高频问题。原因很简单：小程序运行环境不是浏览器，没有自带 atob / btoa 这两个 Web API。

解决办法是引入 base-64 这个 npm 包，或者自己写一个简单的解码函数。引入 npm 包要记得：小程序里必须用 npm init 初始化项目后再 npm install ，然后开发者工具里点“工具 -> 构建 npm”，之后才能 require 。

如果你只是需要解码一小段 base64，可以自己写：

// 极简base64解码（处理标准base64字符串）
function base64Decode(str) {
  const chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'
  let output = ''
  str = str.replace(/=+$/, '')
  for (let i = 0; i < str.length; i += 4) {
    const n = (chars.indexOf(str[i]) << 18) | (chars.indexOf(str[i+1]) << 12) | (chars.indexOf(str[i+2]) << 6) | chars.indexOf(str[i+3])
    output += String.fromCharCode((n >>> 16) & 255, (n >>> 8) & 255, n & 255)
  }
  return decodeURIComponent(escape(output))
}

注意：上面的实现没有处理 UTF-8 字符问题，如果是中文 base64，最好直接用 decodeURIComponent 那一套，或者直接用 npm 库。另外，小程序基础库高版本其实有 wx.arrayBufferToBase64 和 wx.base64ToArrayBuffer ，这两个是官方提供的，处理二进制数据比字符串 base64 更可靠。

4.3 顶部导航栏高度适配问题

热词里“微信小程序顶部导航栏高度”这个量出现频率非常高。仿美团项目里，首页和点餐页通常用自定义导航栏，这就涉及状态栏高度、导航栏高度的计算。

微信官方推荐的是用胶囊按钮位置反推导航栏高度。核心思路：

const menuButton = wx.getMenuButtonBoundingClientRect()
const systemInfo = wx.getSystemInfoSync()
const statusBarHeight = systemInfo.statusBarHeight || 20
const navBarHeight = (menuButton.top - statusBarHeight) * 2 + menuButton.height

这里的原理是：胶囊按钮上下居中于导航栏，所以导航栏高度约等于“胶囊按钮距顶距离”减去“状态栏高度”的两倍，再加上胶囊按钮自身高度。

很多项目写死状态栏高度为20，这一步在iPhone X以后就会偏。正确做法一定是运行时计算，不能写死。

我改造时把这段逻辑放到 utils/nav.js 里，在 app.js 的 onLaunch 时计算一次，存到 globalData ，每个页面直接读取。这样不重复计算，也统一了导航栏高度。

4.4 地图组件选择：天地图能不能用

热词里反复出现“微信小程序可以使用天地图画地图组件吗”“微信小程序使用天地图”。我这里给一个明确结论：微信小程序的 map 组件不支持直接加载天地图瓦片， map 组件底层用的是腾讯地图。你要用天地图的数据，只能通过 web-view 组件加载天地图 Web API 页面，或者把天地图的瓦片 URL 拼到 map 组件的自定义图层上，但这个自定义图层功能也有限制，而且实操体验不佳。

做外卖项目时，地图的核心用途是展示用户定位和商家距离。我的建议是直接用腾讯地图小程序SDK，官方支持好、逆地址解析准确、文档齐全。申请 key 的时候注意域名设置，腾讯位置服务控制台里要配置小程序 appid 的授权。

4.5 rpx与1rem的换算问题

热词里“微信小程序 1rem”说明很多人还在试图把 rem 这套方案套到小程序里。小程序官方推荐的适配单位是 rpx（responsive pixel），设计稿宽度 750rpx 对应屏幕宽度。1rpx = 屏幕宽度/750 px。

但有时候看别人的项目，里面会有 rem 这个单位，这是用 postcss 或者运行时动态计算把 px 转成 rem。小程序里直接写 rem 会有问题：不同设备的根字体大小不同，换算不准确。

我的建议是：所有尺寸一律用 rpx，不要混用 rem。字体大小可以在 app.wxss 里定义一些变量化的类，比如 .text-sm { font-size: 24rpx; } ，后面要改直接改一个地方。

如果你确实需要动态计算尺寸，可以用 wx.getSystemInfoSync().windowWidth 来做比例计算，这样比 rem 靠谱得多。

4.6 微信支付的限制

热词里“微信小程序虚拟支付”说明很多人踩过这个坑。仿美团外卖项目里涉及真实支付，但如果你做的是个人主体小程序，虚拟支付功能基本是禁用的。即使是企业主体，开通微信支付也需要认证、签约、审核。

更关键的一点是：外卖场景里用户购买的是实体的餐饮服务，这属于线下服务类，走的是微信支付的服务商模式，普通小程序商户号很难直接覆盖这种业务流程。实际开发外卖项目时，后端需要对接微信支付的下单、回调、退款接口，而且支付回调的验签逻辑必须放在后端，不能放在前端，否则会被轻易伪造。

对于练习项目，我的建议是：支付环节先用模拟支付代替，点击结算后直接进入“支付成功”页面，同时在后端生成一条模拟订单。等到真正上线接支付时，再替换成正式微信支付流程。

5. 从仿制项目到可上线小程序的扩展路径

前面说了这么多，最后聊聊这个项目的扩展方向。如果只是把“仿美团外卖”这个demo跑起来，价值有限；真正的价值在于你能把它演化成一个自己真正的项目。

5.1 增加真实用户体系

网上的版本登录基本是摆设。你改造的第一步应该是把登录做成完整链路： wx.login 拿到 code，传给后端，后端调用微信的 code2Session 接口换取 openid，然后生成你自己业务系统的 token，前端每次请求带上 token，后端校验 token 后才返回数据。

这里有热词问到“微信小程序 app.js”——app.js 里你会放启动逻辑。但注意，登录逻辑不建议放 onLaunch 里同步阻塞，因为 wx.login 是异步的，如果页面先渲染了又去拿登录状态，会出现“未登录”闪烁。更好的做法是在 app.js 里把 loginReadyPromise 存成全局 Promise，每个页面的 onLoad await 这个 Promise 再初始化数据。

5.2 添加“分包异步化”优化加载

热词里“微信小程序 分包异步化 在其它分包中的插”说明大家已经开始关注分包这个优化点了。外卖项目的主包体积很容易膨胀，因为首页图片、点餐页、购物车组件可能都在主包里。主包超过 2MB 之后无法发布，这时候就要做分包。

分包的逻辑是：按页面功能划分，比如订单、个人中心、搜索、详情都单独成为一个分包。访问到对应页面时再下载对应包。

“分包异步化”是微信新提供的能力，允许主包里的组件在使用时，异步加载其他分包里的组件。比如商品详情页里有一个“商家评价”的组件，存放于 packageComment 分包中，主包页面里可以直接用占位标签，然后触发异步加载组件。

配置方式是在 app.json 里：

{
  "subpackages": [
    { "root": "packageOrder", "name": "order", "pages": ["pages/list/list", "pages/detail/detail"] },
    { "root": "packageUser", "name": "user", "pages": ["pages/profile/profile"] }
  ],
  "preloadRule": {
    "pages/index/index": {
      "network": "all",
      "packages": ["packageOrder"]
    }
  }
}

分包异步化组件加载的写法是：

<comment-component placeholder="加载中"></comment-component>

组件里需要用 options: { addGlobalClass: true } 确保样式隔离不干扰。

5.3 用uni-app重写多端版本

热词里“uniapp做微信小程序在手机上预览没问题，但是在微信开发者上是白片”很典型。uni-app 写的项目如果没打包好，确实容易出现开发者工具白屏。这个问题通常是因为编译模式配置错了，或者基础库版本太低。我建议真机预览没问题的时候，开发工具的“本地设置”里检查一下“调试基础库”是否够新，还有“是否将JS编译成ES5”（老手机必须开）、“是否使用“运行”而不是“发行”模式调试。

如果你打算同时做微信小程序和抖音小程序、支付宝小程序，用 uni-app 重写是有价值的。但如果你只做微信小程序，原生就够，而且原生调试起来反而更快，uni-app 的封装层会掩盖很多底层问题，不利于你理解小程序运行机制。

5.4 逐步补全商家端能力

真实的点餐系统不止是用户点餐一个 C 端，还得有商家端（接单、出餐、库存管理）、骑手端（配送）和管理后台。你可以先把商家端做成小程序，和 C 端共用同一套云开发数据库，商家门店ID做隔离。这部分扩展之后，项目价值就完全不一样了，从“仿美团”变成了“自己的一套点餐系统”。

我在做类似项目时体会很深：新手阶段不要太纠结于代码技巧，先把整个链路打通，从“用户打开小程序 -> 浏览商家 -> 加购物车 -> 下单 -> 商家收到新订单”这个闭环走通，你对小程序开发的认知会上一个台阶。之后的工作都是在这个基础上加量、加性能优化而已。

本文还有配套的精品资源，点击获取