企业官网建设流程全解析

简介：一套面向化妆品电商卖家的微信小程序商城解决方案，帮助商家快速搭建美妆电商平台，适合有小程序开发基础或需要快速上线商城的运营者。压缩包共244个文件，以135个gif动图、31个png及3个jpg图片为主，提供丰富的商品展示与页面素材；24个js文件承载交互逻辑，17个wxss与16个wxml分别定义样式与页面结构，15个json用于页面配置，整体仅984KB，结构清晰精简。已有328人学习，适合学习电商小程序完整结构或直接改造上线。源码涵盖分类导航、关键词搜索、购物车结算、订单管理、用户中心及优惠券/满减/秒杀等促销模块，同时预留后台接口，开发者可使用微信开发者工具导入调试，按需替换图片素材、配置数据库与支付参数，快速完成上线部署。

1. 化妆品商城小程序模板：为什么同样是源码，落地差距比想象中大

打开一套化妆品商城小程序模板，第一件事如果是导入开发者工具看首页，后面大概率会在上线前翻车。原因很简单：模板解决的是界面和交互的复制问题，源码解决的是你能改什么的问题，而大部分标题里的“美妆化妆品电商小程序源码”把两者打包在一起，底层技术栈、数据库字段、支付与登录链路都需要先确认。本文按“选型 → 跑通 → 核心业务改造 → 避坑 → 上线前验证”的顺序展开，让你看完就能动手。适合刚拿到一套美妆商城小程序源码但还没跑通的人，也适合准备采购模板的运营和技术负责人，让你在动手前先知道钱该花在哪、坑可能埋在哪。

2. 先选型再看功能：识别化妆品商城小程序的真实技术栈

2.1 原生微信小程序、uniapp 还是 Taro：用目录特征快速识别

很多人问我，拿到资源第一步该干什么。我的习惯是先看技术栈，再谈功能，因为技术栈直接决定你能维护多久。这类源码交付常见的三种形态是原生微信小程序、uniapp 和 Taro 工程。原生小程序直接使用微信官方的 wxml、wxss、js、json 文件；uniapp 使用 Vue 语法，可以编译到微信、支付宝等多个端；Taro 使用 React 语法，适合全栈都是 React 背景的团队。

判断方法很简单，看目录。根目录下有app.json、app.js、app.wxss和pages/，大概率是原生小程序；根目录下有src/，并且里面有pages.json、manifest.json、uni.scss，这是 uniapp 工程；如果看到config/目录加project.config.json，并且src/里是index.tsx或app.tsx，那基本是 Taro。

# 原生小程序特征 app.json app.js app.wxss pages/index/index.wxml pages/index/index.js # uniapp 特征 src/pages.json src/manifest.json src/uni.scss src/main.js package.json # Taro 特征 src/config/index.ts src/app.ts src/pages/index/index.tsx package.json

为什么这一步重要？我见过不止一个人把 uniapp 源码当成原生小程序用，结果编译出来的dist/weapp目录里也有wxml文件，然后改错地方，越改越乱。如果你是团队里唯一的技术人员，选你熟悉的技术栈比选看起来“高级”的技术栈更重要。如果只想快速做微信单端，原生就够了；如果以后要发支付宝端或 App，uniapp 会省很多事；如果团队全是 React 背景，别硬啃 Vue，直接选 Taro。这里有一个容易被忽略的边界：多端发布和支付通道是两件事，uniapp 虽然能编译到支付宝小程序，但支付宝支付仍需要单独申请支付能力，不能直接复用微信支付商户号。

2.2 目录结构与模块盘点：先摸清前端、后端、管理后台三件套

技术栈确认后，第二步是看一套完整的商城源码长什么样。大多数交付物的目录结构是这样：

mall-app/ ├── client/ # 微信小程序前端 │ ├── app.json │ ├── app.js │ ├── app.wxss │ ├── pages/ │ │ ├── index/ │ │ ├── goods/ │ │ ├── cart/ │ │ ├── order/ │ │ └── user/ │ ├── components/ │ └── utils/ ├── server/ # 后端接口服务 │ ├── package.json │ ├── .env.example │ ├── routes/ │ ├── controllers/ │ └── models/ ├── admin/ # 管理后台 │ ├── index.html │ └── assets/ ├── sql/ │ └── init.sql ├── docs/ └── README.md

这里最关键的判断是：标题里的“源码”到底有没有 server。很多所谓的“小程序模板”只有 client 目录，数据依赖mockjs或前端写死的 JSON，适合做演示，但不能接支付、不能管库存、不能上真实订单。区分方法是在前端utils/request.js里搜一下接口地址：

grep -rn "mockjs\|apiBaseUrl\|127.0.0.1" client/utils/

如果接口地址全是指向 mock，那就意味着你要补全一套后端。如果 server 和 sql 都在，恭喜，落地起点已经高了一截。常见做法是先看README.md，里面一般写了启动顺序；没有 README 的源码包，后续维护成本会很高，拿到手第一天就补一份自己的。

2.3 电商核心模块与化妆品类目特有字段

商城源码的通用模块是商品、购物车、订单、用户中心、优惠券、支付。但化妆品商城有几个特有字段不能省：品牌、商品备案编号、保质期、生产批次、规格容量、色号、适用肤质。普通电商模板通常只给一个goods表加一个spec文本字段，这对美妆商品来说是远远不够的。

我常用下面这张表来快速判断模板的完整度：

如果你准备做的是正经美妆电商，优先选带goods_sku表、goods_attribute表和order_refund表的源码。单规格商品模板适合练手和展示，但化妆品一个色号、一个容量、一个批次就是一条独立库存，入门价一百多的模板在这个位置特别容易露馅。这里的原则是：宁可多花时间改 module，也不要临时把 text 字段硬抠出来当规格。

2.4 环境准备：把本机变成可运行项目的最小环境

在跑通之前，还有一套环境要配好。后端如果带数据库和缓存，通常需要 Node.js、MySQL、Redis；如果是 PHP 源码，则需要 PHP 环境和 Nginx 或 Apache。先确认本机命令：

node -v npm -v mysql --version redis-cli ping

输出里没有报错，说明基础环境没问题。redis-cli ping如果返回PONG，Redis 服务在运行；如果不在运行，很多模板里的秒杀、购物车缓存逻辑会在下单时直接抛异常。这里我的建议是安装长期支持版本的 Node，数据库用 MySQL 5.7 或 8.x 即可，不需要追求最新版本。之后还要在微信开发者工具里准备一个小程序账号和对应 AppID，注意 AppID 和模板里自带的那个不是一回事，后面我会专门讲替换位置。

3. 把美妆化妆品电商小程序源码跑通：导入、配置、首屏验证

3.1 导入工程前先做两个检查：AppID 和接口地址

直接双击压缩包里的目录拖进微信开发者工具，经常会报“找不到 app.json”。在导入之前，我会先解压，然后在终端里检查几件事：

grep -rn "wx[0-9a-f]\{16\}" client/ --include="*.js" --include="*.json" 2>/dev/null | head -20

这条命令是搜代码里被硬编码的 AppID。如果输出很多，说明模板把 AppID 写死在多个文件里，需要全局替换。接下来看接口地址：

grep -rn "https://api\|http://localhost\|http://127.0.0.1" client/utils/request.js

这一步是为了确认前端请求到底打到哪。如果接口指向localhost，而你要用真机预览，那是必然失败的，因为手机上的localhost指向手机自己。如果接口指向某个公网地址，还要确认那是模板作者的服务器还是你自己部署的服务，不要傻乎乎地把数据传到别人的环境里。常见做法是把接口地址统一收敛到config.js或app.js的全局变量里，后面换域名只改一处。

3.2 修改全局配置：小程序页面与导航栏

导入项目后，先打开app.json。这个文件控制着小程序的页面注册、窗口样式和超时时间。一个最常见的配置长这样：

{ "pages": [ "pages/home/home", "pages/goods/detail", "pages/cart/cart", "pages/order/list", "pages/user/index" ], "window": { "navigationBarTextStyle": "black", "navigationBarTitleText": "美妆商城", "navigationBarBackgroundColor": "#ffffff" }, "networkTimeout": { "request": 20000 } }

这里的pages数组第一项是首页，不要随便调顺序。很多模板把启动页做成引导页或授权页，你需要改成真正的商城首页。navigationBarTitleText可以在每个页面的 json 里单独覆盖，所以这里的全局标题是兜底值。如果某个页面采用自定义导航栏，它的 json 里会出现"navigationStyle": "custom"，这种页面在真机上更复杂，遇到“头部标题显示位置不对”的问题，先检查这行配置。

3.3 启动后端服务：以 Node.js 后端为例

多数带后端的模板会提供server/目录和.env.example环境变量模板。我一般的启动流程是：

cd server cp .env.example .env vim .env npm install npm run dev

.env文件里常见变量如下：

PORT=3000 APPID=wx1234567890abcdef SECRET=yourappsecrethere MYSQL_HOST=127.0.0.1 MYSQL_PORT=3306 MYSQL_DB=cosmetic_mall MYSQL_USER=root MYSQL_PASSWORD=root REDIS_HOST=127.0.0.1 REDIS_PORT=6379

注意SECRET是小程序密钥，在微信公众平台获取，不能泄露到前端代码里。模板自带的SECRET和APPID通常是示例值，直接拿去请求微信接口会报 invalid appsecret。如果项目后端是 PHP 源码，那入口文件通常是public/index.php，启动方式以 README 为准，但环境变量的思路完全一样，配置外置、不在代码里硬编码密钥。

3.4 初始化数据库：导入 SQL 后如何自检

很多模板在sql/目录放了初始化脚本。导入数据库前先建一个库：

mysql -u root -p -e "CREATE DATABASE cosmetic_mall DEFAULT CHARACTER SET utf8mb4;" mysql -u root -p cosmetic_mall < sql/init.sql mysql -u root -p -e "USE cosmetic_mall; SHOW TABLES;"

SHOW TABLES的输出应该包含订单、商品、用户、购物车等核心表。如果只有三五张表，说明模板的完整度不高，后面接支付和售后会很吃力。如果sql/目录不存在，可能是靠后端启动时自动建表，那就先npm run dev，再观察日志里有没有建表语句。这里补充一个判断技巧：打开一张goods表结构，看一眼字段里有没有sku相关的关联字段。如果只有stock一个整数，那么这个模板大概率不支持多规格。

3.5 用开发者工具命令行稳定打开项目

如果项目已经导入，但团队里有人想快速拉起来看效果，可以使用微信开发者工具的命令行接口：

# macOS 示例 /Applications/wechatwebdevtools.app/Contents/MacOS/cli -o client --project /Users/你的机器名/mall-app # Windows 示例 cli.bat -o D:\workspace\mall-app

启动后如果页面白屏，优先看调试器的 Console，最常见报错是“request:fail”和“url not in domain list”。前者一般是网络问题，后者是域名白名单问题。开发者工具里勾上“不校验合法域名”可以快速调试，但真机预览仍然必须在微信公众平台配置 request 合法域名。整个跑通的标准不是首页能显示商品，而是能完成一次“浏览商品 → 加入购物车 → 提交订单 → 调起支付”的完整链路。

4. 核心改造：手机号登录、SKU 与营销这些代码藏在哪

4.1 微信小程序登录获取手机号：e.detail.code 与 wx.login 的 code 是两码事

“微信小程序登录获取手机号”这套流程，几乎每个商城模板都要改一遍，因为它牵扯到用户体系。现在的小程序获取手机号方式已经不再是服务端直传手机号码，而是通过<button open-type="getPhoneNumber">返回一个动态 code，再在后端换取真实手机号。

前端按钮和处理的代码通常是这样的：

// pages/login/index.js Page({ handleGetPhone(e) { if (!e.detail.code) { wx.showToast({ title: '未授权手机号', icon: 'none' }) return } wx.login({ success: (res) => { if (res.code) { this.submitLogin(res.code, e.detail.code) } } }) }, submitLogin(loginCode, phoneCode) { wx.request({ url: `${getApp().globalData.baseUrl}/user/login`, method: 'POST', data: { loginCode, phoneCode }, success: (res) => { if (res.data.token) { wx.setStorageSync('token', res.data.token) } } }) } })

这里最容易翻车的是把wx.login返回的 code 当成手机号 code 传给后端。loginCode是用来换openid的临时票据，phoneCode是专门换手机号的凭证，两个东西有效期不一样，也不能互相替代。后端拿到这两个 code 后，要做的是先换 openid，再换手机号明文：

// server/routes/user.js async function login(ctx) { const { loginCode, phoneCode } = ctx.request.body // 1. loginCode 换 openid const sessionRes = await fetch( `https://api.weixin.qq.com/sns/jscode2session?appid=${APPID}&secret=${SECRET}&js_code=${loginCode}&grant_type=authorization_code` ) const { openid } = await sessionRes.json() // 2. phoneCode 换手机号明文 const phoneRes = await fetch( `https://api.weixin.qq.com/wxa/business/getuserphonenumber?access_token=${ACCESS_TOKEN}`, { method: 'POST', body: JSON.stringify({ code: phoneCode }) } ) const { phone_info } = await phoneRes.json() // 3. 查或建用户 const user = await findOrCreateUser(openid, phone_info.phoneNumber) ctx.body = { token: createToken(user.id) } }

第二个参数phoneCode只能用一次，且五分钟内有效。如果用户在授权页反复进出，上次拿到的 phoneCode 就会失效。另一个常见问题是后端没有做access_token的缓存刷新逻辑，导致连续调用获取手机号接口时偶发报错。模板里如果只是简单fetch而不判断 token 过期，你需要自己补上 48 小时刷新逻辑。

4.2 化妆品多规格 SKU：色号、容量、套装组合怎么入库

美妆商城跟数码商城最大的差异在于商品属性的复杂度。一支口红的规格可能是“色号 #276 × 容量 3.5g”，护肤品套装可能是“洁面 120g + 水 200ml + 乳 100ml”。这种多规格商品必须用 SKU 表承载，而不是把一串属性拼在商品详情文本里。

我经过多个项目验证的表结构是这样的：

CREATE TABLE goods_sku ( id BIGINT PRIMARY KEY AUTO_INCREMENT, goods_id BIGINT NOT NULL, sku_code VARCHAR(64) NOT NULL COMMENT '商家自定义编码', spec_value_ids VARCHAR(255) NOT NULL COMMENT '规格值ID组合，如 1:3;2:6', price_cents INT NOT NULL COMMENT '价格，单位分', stock INT NOT NULL DEFAULT 0, sku_img VARCHAR(255) COMMENT '规格图' ); CREATE TABLE spec_value ( id BIGINT PRIMARY KEY AUTO_INCREMENT, spec_id BIGINT NOT NULL, name VARCHAR(50) NOT NULL COMMENT '规格值' );

前端拿到接口数据后，要把goods_sku拉平成一个 map，以规格值 ID 组合作为 key：

Page({ data: { skuMap: {}, selectedKey: '' }, onLoad(goods) { const skuList = goods.skuList || [] const skuMap = {} skuList.forEach(sku => { skuMap[sku.specValueIds] = { price: sku.priceCents / 100, stock: sku.stock, skuCode: sku.skuCode } }) this.setData({ skuMap }) }, onSelectSpec(e) { const key = e.currentTarget.dataset.key const target = this.data.skuMap[key] if (target) { this.setData({ currentPrice: target.price, currentStock: target.stock, selectedKey: key }) } } })

这里我强烈建议价格以“分”为单位存整数，前端展示时再除以 100。模板源码里如果用price: 199.9这种浮点数，累计多个商品后会出现 0.999999 之类的误差，结算金额对不上账是早晚的事。另一个容易漏的点是：当用户选中“色号”但还没选“容量”时，要判断当前组合是否完整，不完整就不要调接口，也不要让用户看到可下单状态。

4.3 营销插件改造：秒杀、拼团、砍价不能只改前端

很多商城模板自带秒杀、拼团、砍价这些模块，但打开代码你会发现，前端的活动按钮很漂亮，后端接口却没有真正校验活动状态。以秒杀为例，正确做法是活动期间用 Redis 做库存预扣，防止同一秒大量请求把数据库打死。

# server/services/seckill.py def seckill_buy(user_id, sku_id): # Redis 原子扣减 stock = redis.decr(f"seckill:sku:{sku_id}") if stock < 0: redis.incr(f"seckill:sku:{sku_id}") raise BizError("手慢了，商品已抢完") # 创建订单，失败则回补库存 try: order = create_order(user_id, sku_id, order_type="seckill") except Exception: redis.incr(f"seckill:sku:{sku_id}") raise return order

不是所有模板都支持 Redis，如果你的模板没有 Redis 依赖，也没关系，可以在数据库层面做原子扣库存：

UPDATE goods_sku SET stock = stock - 1 WHERE id = ? AND stock > 0;

如果UPDATE影响的行数等于 1，说明库存扣减成功，继续创建订单；影响行数为 0，则返回库存不足。这比“先 select 再 update”的写法安全得多，因为它把判断和扣减放在一条 SQL 里，不会出现两个人同时买到最后一支口红的问题。这类活动真正要关注的是幂等：同一个用户重复点击抢购，必须避免生成多笔订单。常见做法是给(user_id, activity_id, sku_id)建唯一索引。

4.4 订单金额必须以后端计算为准

模板里最可怕的逻辑是前端把每个商品的价格、优惠金额都算好，再传给后端生成订单。这样做相当于把定价权交给了前端，用户只要在请求里把总金额改成 0.01 就能下单。正确做法是前端只提交商品 SKU、数量、优惠券 ID、地址等信息：

wx.request({ url: '/order/create', method: 'POST', data: { items: [ { skuId: 1, quantity: 2 }, { skuId: 5, quantity: 1 } ], couponId: 1003, addressId: 12 }, success(res) { // 后端返回订单号和预支付参数 wx.requestPayment(res.data.payment) } })

后端拿到items后，要从商品表重新查价格、查优惠券、查活动，再计算出最终应付金额。这一步没有捷径，也不能省。改造的时候先看订单接口里是否出现price、total这类字段从前端透传，如果透传，把它删掉，改成后端重新计算。这也是判断一套源码是“演示模板”还是“可上线源码”的一个硬指标。

5. 化妆品商城模板源码避坑：抓包、审核、支付回调里的 5 个典型问题

5.1 用户支付成功但订单一直显示待付款

现象：用户在小程序里完成支付，微信支付也提示成功，但订单列表里状态没有变化，管理后台也没有支付流水。

原因：支付状态不是靠小程序端同步结果确认的，而是靠后端notify_url接收微信支付回调。模板里的notify_url要么被写成前端本地地址，要么没有做验签和查询确认。

解决：先把notify_url改为线上可公网访问的 HTTPS 接口，再在后端回调方法里验证签名，并且在收到回调后主动调用微信支付订单查询接口，确认订单真实存在后再更新状态。PHP 后端的支付回调入口经常被写成这样：

$data = file_get_contents('php://input'); parse_str($data, $params); // 验签成功后，用 transaction_id 调用订单查询接口

不要直接信任回调里的result_code，因为回调可能被伪造。验证签名后，再根据out_trade_no修改订单状态，并且要把回调处理记在日志里，方便排查“支付成功但订单未更新”的诡异问题。

5.2 小程序抓包抓不到 HTTPS 请求

现象：开发者工具里能看到请求，但真机调试时想抓包，只看到一条 TCP 连接，看不到请求头和请求体。

原因：小程序真机请求是 HTTPS，抓包工具需要安装并信任根证书，否则只能看到加密握手，解不开明文。另一个常见原因是手机系统没有开启证书信任。

解决：先在电脑端安装抓包工具的 CA 证书，再用手机浏览器访问对应下载地址安装证书；iOS 还需要在“设置 → 通用 → 关于本机 → 证书信任设置”中打开开关。如果真机调试只是看接口数据，也可以直接在微信开发者工具的 Network 面板里看，比抓包方便得多。“小程序抓包”这件事，真正解决的是线上环境的问题，调试阶段完全没必要花太多时间在证书上。

5.3 手机号登录报“code 无效”或“参数错误”

现象：新用户点击授权手机号后，后端接口提示 code 无效；老用户偶尔正常，但过几分钟再试又不行。

原因：当前端拿e.detail.code当作wx.login的 code 传给后端，后端用错接口必然报错。此外，手机号 code 是一次性的，被使用过后再次重复提交也会无效。

解决：检查前端代码里按钮绑定的是不是open-type="getPhoneNumber"，并且把e.detail.code单独传递；检查后端是否先通过loginCode调jscode2session获取 openid，再拿phoneCode调getuserphonenumber。后端在处理时，要把手机号 code 校验失败和 access_token 过期分开记日志，不要只打一行“login error”。

5.4 化妆品类目提审被拒：不是代码问题，是资质与功能一致性

现象：小程序提交审核后，平台返回“选择的类目与页面内容不一致”或“需要提供化妆品相关资质”。

原因：微信小程序对美妆个护商品要求先添加对应服务类目，并上传营业执照、行业资质等材料。如果营业执照经营范围里没有化妆品销售，或者没有品牌授权，审核就会卡住。

解决：在小程序后台的“服务类目”里找到美妆护肤相关类目，按要求提交资质。提审时，确保商城上架的商品都属于已提交类目的范围，不要顺手把食品、医疗器械功能也塞进去。模板里如果有测试用的积分签到、每日抽奖等模块，暂时隐藏掉再提审，等类目齐全后再打开。这不是技术问题，但卡过这个流程的人都知道，它比代码 bug 更耽误时间。

5.5 首页在开发者工具正常，真机白屏

现象：开发者工具里一切正常，清除缓存后真机预览或体验版打开就是白屏，Console 报request:fail url not in domain list。

原因：开发者工具勾选了“不校验合法域名”，真机不会豁免。模板里的接口地址如果用了http://127.0.0.1或http://内网IP，真机访问必然失败。

解决：把接口地址换成已备案并配置 HTTPS 的正式域名，在小程序后台配置 request 合法域名。调试阶段如果非要真机看效果，可以在开发版里开启“开发环境不校验请求域名”，但体验版和线上版本不会生效。另一个低概率但真实存在的原因：有些真机无痕模式或存储异常导致wx.setStorageSync抛错，代码里如果try/catch不规范，页面会卡在启动阶段。建议在app.js的启动逻辑里加一层错误兜底，查看前端控制台日志再判断。

6. 上线前验证清单：从订单闭环到性能体检的一个小时

不再讨论能不能跑通，进入上线前的验证。我会给自己留出一个小时，按下面顺序过一遍，全部通过才敢提交审核。

第一，验证登录链路。换一个新开发者微信账号，走一遍手机号授权、退出、再登录、再授权，确认不会出现 code 过期或重复创建用户的问题。第二，验证支付闭环。用小金额商品完成一单完整支付，然后立刻查订单回调日志、库存扣减、积分变动、佣金记录。如果有一项对不上，宁可不上线也不带病发布。

第三，验证库存一致性。找两个微信号同时下单同一个 SKU，看库存是否被超卖。可以在管理后台手动修改库存到 1，再用两个账号同时提交，跑完看订单数量和剩余库存。常见做法是用脚本循环调接口：

curl -X POST https://api.example.com/order/create \ -H 'Content-Type: application/json' \ -d '{"skuId":1,"quantity":1}'

如果响应时间超过 3 秒，或者返回 500，就去查慢查询日志和后端错误日志。流量预估过万的场景，至少要确认商品详情接口有缓存，不要每次打开都打到数据库。

第四，验证售后流程。发起退款、平台同意退款、退款回调更新订单状态，整个链路要和支付链路一样有完整日志。很多模板只有交易成功闭环，没有退款闭环，这类项目上线后财务对账会非常痛苦。我习惯把订单表和退款表都加上biz_no唯一键，退款单和支付单一一对应，避免重复退款。

第五，检查配置外置。AppID、SECRET、支付密钥、短信密钥不能出现在前端代码和仓库里。把敏感配置统一收进后端.env或配置中心，前端只保留基础接口域名。

最后一次上线前，我还会把“开发环境不校验域名”关掉，用体验版从零走一遍流程。上个模拟项目 X 上线时，因为漏配了一个支付回调地址，第一批用户支付成功但订单全部待付款，凌晨被运营电话叫醒，后来才在docs/release.md里把“回调地址检查”写进固定清单。从此我的每个商城项目发布前都会按这个清单过一遍，也希望这份清单能帮你少踩一次坑。

希望帮到你。

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