美妆护肤小程序商城搭建：资质审核、路线选择与避坑指南

实际做美妆护肤类小程序商城，并不是注册一个小程序再挑一套模板就能上架的。美妆护肤品和普通日用品不同，它涉及品牌授权、类目资质、成分信息展示、过期日期管理和售后规则，任何一个环节没理顺，后面提审都会被打回。很多小白第一次做商城，错误地以为“只要把商品图片传上去就能卖货”，真正开始操作后才意识到，还要面对营业执照、支付商户号、服务器域名、物流模板和内容审核这些连锁问题。

这篇文章专门为零基础开发者和管理者梳理一条能走通的美妆护肤小程序商城搭建路径。会先解释微信小程序的平台规则和资质要求，再比较“SaaS 模板建站、微信云开发、自研部署”三条路线，随后用微信小程序原生语法加云开发模式，带出商品列表、商品详情、购物车和订单确认这套最小可运行骨架。最后会补充提审前检查项和常见报错的排查方法。即便完全没写过代码，只要按顺序操作，也能判断自己当前最需要补哪一块。

1. 先理清微信小程序做美妆商城的三条路线和底层规则

1.1 微信小程序商城并不是“手机网页”，而是寄居在微信里的应用

微信小程序本质上是一个运行在微信客户端内部的轻量应用，由微信提供运行环境。用户不需要去应用商店下载安装，扫码或在微信搜索框输入小程序名称就能打开。它和普通 H5 网店最大的区别在于：微信小程序拥有相对独立的组件体系，页面结构用 WXML、样式用 WXSS、交互逻辑用 JavaScript 编写，并且通过微信公众平台统一发布和审核。

对做过网页开发的人，可以把小程序理解成“一套语法不同于 HTML 的前端项目”。对完全没接触过程的零基础用户，则可以直接把它理解成一个有固定后台管理入口、有商城类目约束、有发布审核机制的微信内应用。微信给每个已注册的小程序分配一个唯一的 AppID，后续所有真机预览、代码上传和版本发布都以这个 AppID 为身份标识。

1.2 美妆护肤类目的资质比普通服装、日用百货更严格

在微信公众平台中，小程序商城通常对应“商家自营”类目。如果标题或商品内容涉及美妆、护肤、彩妆、香水、美容工具等，微信审核时会要求提交相应的行业资质。常见要求包括：

资质文件	适用场景
营业执照	所有电商类小程序的基本要求，经营范围需包含相关零售业务
品牌授权书或采购链路证明	销售品牌美妆护肤品时必须提供，否则容易涉及侵权投诉
化妆品经营相关证明	面膜、精华、口红、防晒等产品可能需要符合平台对化妆品经营的要求
特殊化妆品批准文号	防晒、美白、染发、烫发等特殊用途化妆品，需要取得相关批准文号
食品经营许可或跨境进口资质	如果涉及口服美容液、跨境保税仓发货的护肤品，需要额外准备

实际项目里，经常遇到三类问题：第一类，个人主体注册的小程序，在美妆护肤类目下几乎没有完整经营权限；第二类，企业营业执照经营范围不含“化妆品零售”“卫生用品批发”等字样，导致类目审核不通过；第三类，使用了品牌方的 LOGO、详情页图片，但没有上传品牌授权链路，被商标所有人投诉下架。

我的建议是：在动手搭建界面之前，先把主体信息和资质材料准备好。用企业主体还是个体工商户主体，直接决定后面能否开通微信支付商户号，也决定能否通过美妆类目审核。

1.3 零基础获取商城的速度排位：SaaS 模板、云开发、自研前后端

搭建方式直接决定后续的维护成本和功能上限。零基础用户容易听到“源代码”“一键部署”之类的词，但不同方案对应的技术门槛差异很大。

第一种是 SaaS 商城平台。类似有赞、微盟等第三方产品，或者各类“小程序商城建站平台”。用户只需在平台后台选择化妆品商城模板、上传商品数据、绑定自己的小程序账号，平台会帮助托管服务器、生成页面。这种方式上线最快，通常 1 天到 3 天就能搞定一个可用版本，缺点是每年要支付平台服务费，部分营销功能按模块收费，自定义程度有限。

第二种是微信云开发。它本质上是微信官方提供的 Serverless 能力，开发者不需要自己购买云服务器、不用配置域名备案，直接在微信开发者工具里开通云开发环境，就能使用云数据库、云存储、云函数。页面仍然用小程序原生 WXML/WXSS/JS 开发，但登录、商品数据读写、图片上传、订单生成都由云开发承担。对于想掌控代码、又不想维护 Linux 服务器的小白，这是性价比很高的路线。

第三种是自研前后端。前端使用小程序原生或 uni-app，后端自建服务器，数据库用 MySQL 或 PostgreSQL，还要处理 HTTPS 证书、域名备案、服务器安全组、支付回调服务器等。这种方式在商品 SKU 复杂、ERP 对接、多端覆盖场景下更灵活，但对零基础用户壁垒很高。

后续正文中的代码示例以“微信原生小程序 + 微信云开发”为准。这样既不需要额外购买服务器，也能让新手在微信开发者工具中 30 分钟内创建出商城骨架。SaaS 方案主要用于快速上线，云开发和原生代码方案用于理解小程序商城的技术结构和二次开发，两种方式并不冲突。

2. 注册小程序、获取 AppID 并准备商家支付资格

2.1 注册主体选择：个人主体不能完整经营美妆电商

打开微信公众平台官网，点击“立即注册”，选择“小程序”类型。注册过程中需要提供邮箱、密码，并选择主体类型。主体类型包含个人、个体工商户、企业、政府、媒体等不同类型，选择不同主体会影响开放能力。

个人主体注册最大的问题是权限受限。个人小程序不能开通微信支付，部分类目完全无法选择，即使强行上线，也容易在“虚拟支付”或“电商带货”规则上被拦截。美妆护肤品交易必然涉及在线付款，因此没有例外，都应当选择“个体工商户”或“企业”主体。注册企业主体前，需要准备好营业执照、法人信息、对公账户或法人银行卡验证资料。

2.2 类目选择和小程序名称命名建议

注册完成后，进入“小程序管理后台 -> 设置 -> 基本设置”，可以修改小程序名称、头像、简介。名称建议优先体现品牌和品类关键词，例如“XX美妆馆”“XX护肤优选”。名称过于宽泛，比如只叫“全球购”，审核时可能要求改名或补充商标证明。

在“小程序管理后台 -> 设置 -> 服务类目”中选择类目。电商场景通常选择“商家自营 -> 美妆/个护”等类目。不同类目对应不同资质上传入口，以微信公众平台实时要求为准。不要在未取得相关资质的情况下选择医疗美容、药品等高风险类目，这会造成审核驳回，严重情况下还会触发账号处罚。

2.3 注册完成后要立即在开发者工具里绑定 AppID

小程序后台注册完成后，在“开发 -> 开发管理 -> 开发设置”中能找到 AppID。AppID 是一个以 wx 开头的 18 位字符串，后续微信开发者工具创建项目、上传代码、调用云开发都需要它。

如果完全采用 SaaS 模板，注册小程序后需要在小程序后台“设置 -> 第三方设置”中完成授权绑定，让模板平台代替你执行代码上传和版本发布。这里要注意，把小程序管理权限授权给第三方，意味着第三方平台可以读取你后端的商品和订单数据，因此在选择 SaaS 服务时，除了比价，还要关注数据导出能力和服务商背景。

2.4 微信支付商户号与电商发货能力

所有正规的线上收款，都建议使用微信支付商户号。申请入口在微信支付商户平台，使用营业执照提交资料，完成账户验证后，可以在商户平台创建“AppID 关联”，把小程序 AppID 和商户号绑定。生成支付需要的商户号 mch_id，以及 API 密钥。

这里对零基础读者解释一个常见误区：小程序商城和微信支付不是同一个概念。小程序商城负责展示商品、管理购物车、生成订单；微信支付负责执行“用户一付款，钱进入商户号”的动作。两者通过后端生成预支付交易单、前端拉起支付组件的方式关联起来。如果直接在前端把金额写死，只调用支付接口，是无法完成真实交易的，因为微信支付要求下单请求必须由商家服务器端使用商户号签名发起。

实践中，如果暂时没有商户号，可以在云开发控制台先完成商品展示和购买流程的前端测试，把支付环节留到后续接入。一定要等支付商户号审核通过以后再大规模推广，否则用户能下单、能看订单，一付款就报错，会造成极差的体验。

3. 微信开发者工具安装与云开发环境初始化

3.1 下载开发者工具并创建项目

微信开发者工具是编写、调试和上传小程序的主要 IDE。在微信开放文档中可以根据操作系统下载稳定版。安装完成后，使用小程序管理员微信扫码登录工具。工具首页选择“小程序项目”，项目名称可填“美妆商城演示”，目录选一个容易记忆的文件夹，在“AppID”处填入第 2 节获取到的 AppID。

创建项目时，若选择“不使用模板”，会生成一个只含 app.js、app.json、app.wxss、index.js、index.wxml、index.wxss 等文件的空项目。这类文件是理解小程序结构的最佳起点，不必一开始就拉取复杂模板。

一个小程序项目的目录通常包括：

miniprogram/ ├─ app.js 小程序逻辑入口 ├─ app.json 全局配置，页面路由、窗口标题、tabBar ├─ app.wxss 全局样式 ├─ pages/ 各个页面目录 │ ├─ index/ 首页 │ ├─ category/ 分类页 │ ├─ detail/ 商品详情页 │ ├─ cart/ 购物车页 │ └─ order/ 订单确认和列表页 ├─ components/ 通用组件 └─ images/ 静态图片 cloudfunctions/ ├─ login/ 登录云函数 ├─ goods/ 商品查询云函数 └─ order/ 订单创建云函数

这个目录结构不是微信强制要求唯一的写法，但推荐从一开始就分区管理。小程序每个页面都由.js、.wxml、.wxss、.json四个同名文件构成，文件缺失会导致页面无法编译。

3.2 开通云开发环境并创建第一个集合

在开发者工具顶部工具栏点击“云开发”按钮，系统会提示开通云开发。开通时可以选择按量付费或包月套餐。学习阶段可以先选免费额度试用；真实上线以后，一个包含商品图片、订单、用户访问的小程序商城，计费开销通常并不高，但仍要设置好告警和成本上限，避免恶意刷接口导致费用飙升。

开通云环境后，在“云开发控制台 -> 数据库”中创建一个集合。集合可以理解成数据库里的“表”。建议创建以下集合：

集合名称	用途
goods	保存商品标题、描述、价格、库存、封面图、分类、成分或功效字段
category	保存护肤、彩妆、香水等分类名称和排序
cart	保存购物车数据，或使用本地缓存替代
user	保存用户昵称、头像、手机号、会员等级
order	保存订单主表，字段包含下单用户、商品快照、金额、状态、收货地址
order_item	保存订单明细，每个商品一行
banner	首页轮播图配置

在开发初期，可以先用“手动添加记录”的方式往 goods 集合里录入两三条商品数据，模拟真实商品。商品数据不要只学教程里的“hello world”字段，建议直接设计成后面能用起来的结构。

3.3 商品表结构设计示例

美妆护肤品的商品数据和普通图书、服饰略有区别。一款“精华液”可能存在 30ml、50ml、100ml 三个规格，或者“正装 + 替换装”的组合规格。同一款产品，也可能有“清爽型”“滋润型”之分。因此商品表需要一个字段专门存规格组合。

在云开发数据库中，新增一个 goods 集合，并手动添加一个记录，字段示例：

{ "_id": "g_001", "title": "玻尿酸保湿精华液", "subtitle": "适合干性、中性肌肤", "categoryId": "c_skincare", "cover": "cloud://cloud1-xxx.636c-cloud1-xxx/cover.jpg", "images": [ "cloud://cloud1-xxx.636c-cloud1-xxx/01.jpg", "cloud://cloud1-xxx.636c-cloud1-xxx/02.jpg" ], "price": 199, "originalPrice": 259, "stock": 500, "skuList": [ { "spec": "30ml", "price": 199, "stock": 200 }, { "spec": "50ml", "price": 299, "stock": 200 }, { "spec": "100ml", "price": 499, "stock": 100 } ], "saleCount": 1200, "tags": ["保湿", "玻尿酸", "无酒精"], "productionDate": "2025-03-01", "shelfLife": "3年", "status": "on", "createdAt": "2025-01-01 10:00:00" }

字段设计说明：

• cover和images优先后续使用云存储的 cloud:// 地址，不使用微信头像等受限域名。
• price字段在数据库中建议使用“分”为单位存储整数，比如 199 表示 19.9 元。避免直接使用浮点数计算金额，减少支付金额误差。
• skuList里保存商品规格，商品详情页点击不同规格时，价格和库存都要切换。
• productionDate和shelfLife是护肤品相对重要的信息。日期字段建议统一为YYYY-MM-DD字符串，便于前端直接展示。
• status字段用于上下架控制。status 为 off 的商品即使商品 id 被分享，也应在请求详情时被过滤掉。

3.4 app.json 中的 tabBar 和页面路由

打开小程序根目录的 app.json，配置页面路径和底部导航。下方配置是一个常见的商城导航，包括首页、分类、购物车、我的四个标签页。

{ "pages": [ "pages/index/index", "pages/category/category", "pages/detail/detail", "pages/cart/cart", "pages/order/order", "pages/user/user" ], "window": { "navigationBarTitleText": "美妆护肤馆", "navigationBarBackgroundColor": "#ffffff", "navigationBarTextStyle": "black", "backgroundColor": "#f7f7f7" }, "tabBar": { "color": "#999999", "selectedColor": "#d81e3c", "borderStyle": "black", "list": [ { "pagePath": "pages/index/index", "text": "首页" }, { "pagePath": "pages/category/category", "text": "分类" }, { "pagePath": "pages/cart/cart", "text": "购物车" }, { "pagePath": "pages/user/user", "text": "我的" } ] }, "sitemapLocation": "sitemap.json" }

注意：detail 页面通常不作为 tabBar 页面，它通过 wx.navigateTo 从列表页跳转进入。首页、分类页、购物车页、个人中心页通常放在 tabBar 中，tabBar 只允许配置 2 到 5 个页面。购买流程中的订单确认页也不放进 tabBar，而是单独跳转进入。

4. 实现首页、商品列表、详情和加入购物车流程

4.1 首页加载商品列表的云函数

云开发环境中，小程序前端不能直接像传统后端那样执行任意 SQL 查询，但可以通过wx.cloud.callFunction调用云函数，云函数再使用@cloudbase/node-sdk查询数据。也可以在小程序前端直接通过wx.cloud.database()操作数据库。两种方式都可行，但推荐把关键业务操作封装成云函数，便于控制权限和复用逻辑。

先在cloudfunctions/goods目录中创建云函数，代码如下：

// cloudfunctions/goods/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db = cloud.database() exports.main = async (event) => { const { action = 'list', categoryId = '', page = 1, pageSize = 10 } = event if (action === 'list') { let where = { status: 'on' } if (categoryId) { where.categoryId = categoryId } const countResult = await db.collection('goods').where(where).count() const res = await db.collection('goods') .where(where) .orderBy('createdAt', 'desc') .skip((page - 1) * pageSize) .limit(pageSize) .get() return { code: 0, data: { list: res.data, total: countResult.total, page, pageSize } } } if (action === 'detail') { const { id } = event const res = await db.collection('goods').doc(id).get() return { code: 0, data: res.data } } return { code: 1, message: '未知 action' } }

这段代码要部署到云开发环境。方式有两种：在开发者工具云函数目录上右键“创建并部署：云端安装依赖”，或先在本地右键“上传所有文件”，再到云开发控制台查看云函数列表和运行日志。

前端首页pages/index/index.js中调用示例：

// pages/index/index.js Page({ data: { goodsList: [], loading: false }, onLoad() { this.loadGoods() }, async loadGoods() { this.setData({ loading: true }) try { const res = await wx.cloud.callFunction({ name: 'goods', data: { action: 'list', page: 1, pageSize: 10 } }) if (res.result.code === 0) { this.setData({ goodsList: res.result.data.list }) } } catch (err) { console.error('加载商品失败', err) wx.showToast({ title: '加载失败，请重试', icon: 'none' }) } finally { this.setData({ loading: false }) } }, goDetail(e) { const id = e.currentTarget.dataset.id wx.navigateTo({ url: `/pages/detail/detail?id=${id}` }) } })

这里的一个关键点是：云函数默认使用DYNAMIC_CURRENT_ENV，会自动切换到当前调用方所在环境，避免了在代码里写死环境 ID。

4.2 首页 WXML 商品列表结构

首页的商品列表在 WXML 中通常用 flex 换行布局。以下代码适合两列商品卡片展示：

<!-- pages/index/index.wxml --> <view class="page"> <view class="goods-list"> <view class="goods-item" wx:for="{{goodsList}}" wx:key="_id" >// pages/detail/detail.js Page({ data: { id: '', goods: null, selectedSku: '', quantity: 1 }, onLoad(options) { const { id } = options if (!id) { wx.showToast({ title: '缺少商品参数', icon: 'none' }) return } this.setData({ id }) this.fetchDetail(id) }, async fetchDetail(id) { const res = await wx.cloud.callFunction({ name: 'goods', data: { action: 'detail', id } }) if (res.result.code === 0) { const goods = res.result.data let selectedSku = '' if (goods.skuList && goods.skuList.length > 0) { selectedSku = goods.skuList[0].spec } this.setData({ goods, selectedSku }) } }, chooseSku(e) { this.setData({ selectedSku: e.currentTarget.dataset.spec }) } })

详情页 WXML 的关键片段：

<view class="sku-panel"> <view class="sku-label">规格</view> <view class="sku-list"> <view wx:for="{{goods.skuList}}" wx:key="spec" class="sku-item {{selectedSku === item.spec ? 'sku-active' : ''}}" >// pages/detail/detail.js 中加入购物车逻辑 addToCart() { const { goods, selectedSku, quantity } = this.data if (!goods) return const cart = wx.getStorageSync('cart') || [] let skuPrice = goods.price const sku = goods.skuList.find(item => item.spec === selectedSku) if (sku) { skuPrice = sku.price } const cartItem = { goodsId: goods._id, title: goods.title, cover: goods.cover, spec: selectedSku || '默认', price: skuPrice, quantity, checked: true } const existIndex = cart.findIndex(item => item.goodsId === cartItem.goodsId && item.spec === cartItem.spec ) if (existIndex > -1) { cart[existIndex].quantity += quantity } else { cart.push(cartItem) } wx.setStorageSync('cart', cart) wx.showToast({ title: '已加入购物车', icon: 'success' }) }

购物车在开发阶段使用本地缓存是合理的，但上线前仍然建议迁移到数据库。因为用户换一部手机或清理缓存后购物车会丢失。稳定的商城体验应当至少把购物车数据同步到服务端。

4.5 购物车计算金额与全选逻辑

购物车页面读取本地缓存，渲染列表，并完成全选、单选、增减数量、删除等操作。金额计算的关键点是遍历购物车中checked为 true 的项，累加price * quantity。

computeTotal(cart) { const total = cart.reduce((sum, item) => { if (item.checked) { return sum + item.price * item.quantity } return sum }, 0) this.setData({ cart, total: total.toFixed(2) }) }

页面中每个商品行的选中态使用 checkbox 或自定义 view 实现。不要把所有计算都放在 WXML 里反复调用函数，每次点击时更新缓存和金额数组即可。

5. 登录、订单与支付链路对零基础项目的真正影响

5.1 用户登录：先获取微信身份，再关联会员数据

商城通常需要记录用户身份，以便查看订单、积分和会员等级。小程序标准登录流程是调用wx.login获取临时 code，再把 code 发送到云函数或后端，后端用 code 调用微信接口换取 openid。opendid 是用户在当前小程序内的唯一标识，同一用户在不同小程序里 openid 不同。

在云开发环境中，云函数可以通过cloud.getWXContext()直接获取 openid，省略了换取 token 的复杂环节。

// cloudfunctions/login/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) exports.main = async () => { const { OPENID, APPID, UNIONID } = cloud.getWXContext() const db = cloud.database() const userCollection = db.collection('user') const res = await userCollection.where({ openid: OPENID }).get() let user if (res.data.length === 0) { const newUser = { openid: OPENID, nickName: '', avatarUrl: '', phone: '', createdAt: db.serverDate() } const addRes = await userCollection.add({ data: newUser }) user = { _id: addRes._id, ...newUser } } else { user = res.data[0] } return { code: 0, data: user } }

在小程序前端页面，调用云函数 login，登录后把用户数据保存到 globalData 或缓存中。早期的wx.getUserInfo和wx.getUserProfile弹参数框的做法已经不适合当前隐私保护要求，获取用户头像昵称应当在用户主动点击“获取信息”这类场景下操作。

5.2 微信支付：真实收款一定由商户平台下发能力

做商城项目，很多零基础用户会在某一步问：为什么我按代码写了 uni.requestPayment 还是无法调起支付？原因几乎都是没有满足支付前置条件。支付链路可以用一张简单流程理解：

1. 用户在商城小程序创建订单。
2. 商家后端调用微信支付“统一下单接口”，传入金额、商品描述、用户 openid、回调地址。
3. 微信支付返回预支付交易单号。
4. 小程序通过wx.requestPayment拉起收银台。
5. 用户输入支付密码后，微信后台向商家配置的 callback 地址发送支付结果通知。
6. 后端确认支付成功后修改订单状态为“已支付”。

真正适合零基础个人学习者的是：先把订单创建流程写成日志，不要真实扣款。在本地开发时，即使没有商户号，也可以用假的支付成功状态模拟订单流转，待支付资质下来后再衔接真实接口。

5.3 订单创建要写“商品快照”，不能只存商品 id

常见低质量商城写法，是在订单表里只存一个商品 id 和数量。这样会引发一个问题：商家后台改价或删除商品后，历史订单里的金额和名称也会跟着变动，用户查看历史订单时看起来毫无可信度。

正确的做法是，在下单瞬间把商品的标题、图片、规格名、单价、数量快照存入订单或订单明细中。即使日后商品表变化，历史订单仍然保持下单时的样子。订单表结构可以简化成：

{ "_openid": "用户openid", "orderNo": "20250515123000001", "status": "pending", "totalFee": 19900, "payFee": 19900, "discountFee": 0, "items": [ { "goodsId": "g_001", "title": "玻尿酸保湿精华液", "cover": "cloud://...", "spec": "30ml", "price": 19900, "quantity": 1 } ], "receiver": { "name": "张三", "phone": "13800000000", "province": "广东省", "city": "深圳市", "detail": "南山区某街道某号" }, "remark": "", "createdAt": "2025-05-15 12:30:00", "paidAt": "", "payTradeNo": "" }

金额字段全部以“分”为单位保存。orderNo可以取日期加随机数或云函数内的自增序列。展示给用户时再用(item.price / 100).toFixed(2)转换成带两位小数的价格。

6. 美妆护肤品上架、首页装修和售后细节

6.1 商品分组与首页装修思路

常见商品商城首页包括顶部搜索框、中部轮播图、金刚区图标、分类导航、商品瀑布流、品牌推荐等内容。实际搭商城时不建议一次性把模块全部塞满，先做一个简单、能展示出美妆调性的首页即可。

内容模块顺序可以按用户决策逻辑安排：

1. 首屏轮播图推荐当季热卖或新人礼包。
2. 分类金刚区：护肤、彩妆、香水、个护清洁、美妆工具。
3. 标题区“今日必买”或“敏感肌专区”。
4. 商品双列瀑布流。
5. 底部显示售后保障和品牌备案信息。

小程序端建议使用灵活的“装修配置”数据结构。不必真的做可视化拖拽编辑器，只需在 banner 和 goods 集合中配置排序值即可。

6.2 美妆商品详情页的合规描述要点

在录入商品描述时，不要虚构功效。文案中避免使用“药到病除”“祛皱抗衰老”这类容易误导的词汇，尽量使用“保湿”“修护”“舒缓”“提亮”等相对稳妥的成语。护肤品宣称“美白”或“防晒”，需要特殊化妆品批准文号；普通神经酰胺、玻尿酸、烟酰胺等成分介绍要基于成分表描述。

详情页建议固定展示以下模块：

• 产品名称和品牌
• 规格和价格
• 核心成分和成分解读
• 适用人群与肤质提示
• 使用方法
• 生产日期和保质期
• 库存与发货说明
• 售后政策和退换货规则

如果是美妆集合店或跨境贸易，还要展示发货地、清关方式、是否支持七天无理由退货等。

6.3 库存与临期商品提醒机制

护肤品类最担心的问题之一是“压货”和“临期”。在商品集合中维护stock字段只是一层基础，还需要通过在云函数中增加“扣减库存”逻辑防止超卖。下单成功后，应使用云开发数据库的事务能力，先查库存，再扣减库存，把扣减操作放到一个事务内执行。

临期商品可以通过shelfLife和货架到期日期做提醒。如果商品不存储具体的保质期到期日，至少应在后台记录生产日期和保质期月数，供导出时提示运营人员处理。实际商城中，临期商品在详情页标注“保质期截至 XXXX 年 XX 月”，能显著降低售后争议比例。

7. 常见问题：从无法编译到审核被拒的排查顺序

7.1 报错“app.json: tabBar.list[0].pagePath 不存在”

现象：开发者工具编译时直接红色报错，提示 tabBar 某个页面路径不存在。

原因：app.json 里声明了 tabBar 页面路径，但 pages 目录中并没有对应文件，或者 pages 列表没有把该路径注册进去。

检查顺序：

1. 确认pages数组中是否包含 tabBar 中声明的页面。
2. 确认 pages 目录下文件是否齐了四个同名文件：.js、.json、.wxml、.wxss。
3. 确认路径中没有写成绝对路径或以大写字母拼错目录名。

解决方式：在根目录的 pages 数组加入缺失路径，让开发者工具自动创建文件，或者删除 tabBar 中不在 pages 数组里的页面。

7.2 报错“url not in domain list”或“network error”

现象：在开发者工具中能预览商品图片，真机预览或发布体验版时图片不显示，接口请求失败。

原因：小程序要求网络请求地址和文件下载地址必须配置到合法域名。如果图片地址来自腾讯云云存储cloud://，不需要配置域名；如果是自购服务器或对象存储，需要在微信公众平台后台“开发管理 -> 开发设置 -> 服务器域名”中添加 request 合法域名、downloadFile 合法域名。图片域名还必须开通 HTTPS。

解决方式：

1. 小程序内不要直接请求http://地址，微信小程序默认不允许明文 HTTP 请求。
2. 使用微信云的 cloud:// 地址无需域名配置。
3. 若图片来自阿里云 OSS、又拍云、腾讯云 COS，拷贝对应的 HTTPS 域名到合法域名列表。
4. 修改后注意同步替换数据库中所有旧图片地址。

参考排查表：

问题现象	检查方向	处理建议
首页商品空白	数据库是否有记录、云函数是否有日志	打开云开发控制台查看云函数日志
图片请求 403	防盗链或图片域名未配置	检查存储桶防盗链，并添加合法域名
请求 respond 404	云函数名称或路径写错	检查 callFunction name 与云函数目录是否一致

7.3 云函数调用失败并提示“FunctionName parameter could not be found”

现象：使用wx.cloud.callFunction调用 goods 云函数时，控制台报找不到云函数。

原因：云函数目录没有成功部署到当前环境，或开发者工具当前登录账号不是该云环境的管理员。

解决方式：

1. 在开发者工具中右键云函数目录，选择“创建并部署：云端安装依赖”。
2. 部署完成后，在云开发控制台 -> 云函数中查看是否出现该函数。
3. 部署过程中不要中途关闭开发者工具。
4. 如果本地依赖安装缓慢，先选择“云端安装依赖”模式。

7.4 小程序提审被拒，常见的是资质和内容问题

小程序审核拒绝不像编译报错那么直观，但绝大多数原因都能在“微信公众平台 -> 站内信”中找到。美妆商城最常见的驳回原因如下：

驳回原因	核心问题	处理建议
类目不符	营业执照缺少相关经营范围	新增经营范围或更换主体
涉及品牌授权	页面出现品牌 LOGO、产品销售但无授权材料	在类目资质中补充授权书
商品图片违规	页面使用夸大宣传用语、医疗用语	删除违规宣传词并重新上传
体验功能不完整	提交的审核版本里商品无法支付、下单失败	在测试环境配置虚拟支付或者准备测试账号配合审核
隐私弹窗不明确	未配置用户隐私保护指引	在小程序后台配置隐私协议并声明收集手机号、位置等信息的目的

提审前要养成一个习惯：先运行一次体验版，使用“生成体验版二维码”功能由审核人员进行内部自测。体验二维码的生成路径在开发者工具“预览”面板，也可以上传代码后在小程序后台生成体验版二维码。

7.5 支付提示“由于小程序违规，支付功能暂时无法使用”

现象：商城页面正常，其他小程序也正常，只有当前小程序在调用微信支付时提示“由于小程序违规，支付功能暂时无法使用”。

原因：这一般不是前端代码问题，而是小程序账号或关联的微信支付商户号被平台风控或处罚。常见触发原因包括虚拟支付违规、类目与经营内容不符、买家投诉过高、诱导分享等。

处理方式不是修改代码绕过限制，而是先登录微信公众平台或微信支付商户平台，查看站内信和处罚原因，根据提示提交申诉或整改材料。前端可以紧急下线违规商品、修改合规文案、下架未取得资质的产品，然后等待平台评估。不要轻信网络上声称可以“强制拉起支付”的通道或脚本，这些做法既破坏微信支付协议，也容易导致商户号被永久清退。

正确做法是建立支付问题追踪清单：先把用户支付失败反馈记录到客服系统；确认是全部用户失败还是仅部分用户失败；再分别检查商户号状态、AppID 与商户号绑定关系、签名算法和订单金额是否合法。

8. 上线前检查清单与零基础学习路径

8.1 完整上线检查清单

在版本提交审核前，建议对照清单逐项打勾。该清单可以直接用在团队内部验收环节：

• [ ] 营业执照、品牌授权、化妆品资质是否已上传并审核通过。
• [ ] 小程序 AppID 与微信支付商户号是否已完成绑定。
• [ ] 云开发环境是否已从测试切换为正式环境，或至少区分测试集合和上线集合。
• [ ] 商品图片是否已上传到云存储或 CDN，域名是否加入合法域名。
• [ ] 首页、详情、购物车、订单四个核心页面是否在体验版中完整跑通。
• [ ] 商品详情页是否展示生产日期、保质期、使用方法等必要信息。
• [ ] 订单金额在多个规格和多个数量下计算是否正确。
• [ ] 库存为 0 的商品能否正常置灰。
• [ ] 用户提交订单前是否要求填写收货地址，并在无地址时引导添加。
• [ ] 订单状态流转是否清晰：待付款、已付款、待发货、已发货、已完成、已退款。
• [ ] 是否配置了客服联系方式或小程序客服组件。
• [ ] 是否已经在隐私协议中声明收集用户信息的目的。
• [ ] 是否存在“敏感词”“夸大宣传”“绝对化用语”等文案。
• [ ] 是否设置数据库权限，保证用户不能篡改他人订单。
• [ ] 是否配置价格等关键数据的后台校验。
• [ ] 是否准备回滚方案，比如上一版本代码备份。
• [ ] 是否配置日志监控和订单异常告警。

8.2 学习小程序商城的推荐顺序

零基础读者不要一开始就去读完整的微信小程序开发文档，也不要直接下载大型商城模板然后逐行分析。最有效的学习顺序是：

1. 先注册一个小程序测试号，通过教程创建一个能显示的页面，理解页面跳转和事件绑定。
2. 用 wx.cloud 数据库手动录入 5 条商品数据，实现首页列表加载。
3. 给列表页加入点击跳转详情页、详情页展示不同规格的功能。
4. 实现购物车本地缓存逻辑，理解全选和金额计算。
5. 再用云函数重构购物车和服务端数据存储。
6. 接入订单创建，模拟支付成功，把订单状态流转完整跑通。
7. 申请微信支付商户号，联调真实支付回调。
8. 完善售后、物流、会员积分、优惠券等复杂模块。

这个路径的核心思想是“先闭环，再完善”。很多搭建失败的项目，不是技术能力不够，而是试图一次性完成所有功能，结果首页、支付、会员、分销全都半途而废。上线一个功能完整、页面简洁、能完成“浏览 -> 加购 -> 下单 -> 支付”的最小商城，比长期停在“无限开发中”更有价值。

如果实在需要快速验证市场，可以先选择有成熟模板的 SaaS 平台，把商品上架、结算、物流跑通，积累订单数据；等到需要深度定制会员体系、积分商城、ERP 对接时，再投入开发资源迁移到云开发或自研架构。反向操作则不建议：不要在尚未验证消费者需求时，先花大量成本开发超大规模项目。商业模式的验证速度，往往比代码架构的完美程度更重要。

9. 回到开发本身：代码之外的三点提醒

做美妆护肤品小程序商城，最终呈现出来的不只是几行代码或一套模板，而是一套可以被信任的交易流程。小程序只是门店的前台，真正支撑用户复购的是商品质量、成分透明、物流体验和退款处理速度。

开发阶段最能提升项目质量的三个动作是：把时间花在商品详情结构化上；不要把金额、库存的校验只放在前端；把订单日志从第一天就单独记录下来。零基础用户的第一版商城，可以没有会员、没有分销、没有直播，但必须有清晰的商品表、正确的金额字段、可靠的库存扣减和能自查的订单日志。这些基础模块一旦建好，后续任何新功能都是在这个地基上做加法，而不是推翻重来。

完成本文示例中的商品列表、详情、购物车和订单数据结构，相当于把一个商城的最小闭环跑通了。接下来可以根据实际品类继续扩展：如果你要做的是敏感肌护肤品商城，可以增加“肤质测试”和“成分避雷”模块；如果做的是线下美妆集合店，可以增加“门店自提”和“到店预约”能力。每次扩展，都建议从数据结构和用户流程两个方向同时考虑，避免只加了前端按钮、后端却无法支撑对应业务。