企业官网建设流程全解析

简介：一套仿小米商城风格的微信小程序商城模板，适合前端初学者、小程序开发人员以及需要快速搭建商城原型的个人或团队参考学习。资源以完整源代码和界面截图为核心，包含全局配置与页面入口、样式表、工具类封装等典型电商项目结构，覆盖首页、日志等基础页面，便于直接导入微信开发者工具运行或二次扩展。压缩包共14个文件，主要类型为js逻辑文件、wxml页面结构、wxss样式文件、json配置以及png截图，分别承担交互逻辑、界面骨架、视觉样式与效果预览，整体大小约956KB，轻量易用。目前已有2381人学习下载，具有一定的社区参考价值。通过该模板，读者不仅能直观对照截图预览页面效果，还能快速理解项目目录划分与代码组织方式，积累电商场景下常用的界面布局与交互实现技巧。

1. 微信小程序商城模板与小商城风格的工程取舍

“微信小程序 商城模板 小米商城”这组关键词背后，通常是一个很具体的诉求：用最短时间得到一个能演示、可二次开发、视觉上不廉价的商城小程序。仿小米商城风格受欢迎，不只是因为橙色识别度高，更因为它把商城最复杂的三件事——首页楼层组织、分类导航、SKU 选择——都用稳定的交互结构固定了下来。模板附带源代码和截图，意味着拿到手就能对照效果图定位对应页面。但真正的分水岭在第一次改版：楼层数据是写死在页面里还是走 mock 层，请求 URL 是集中在配置里还是散落在各页面，购物车状态是全局订阅还是页面内临时变量，这三点基本决定模板还能用多久。下面按骨架、页面、数据层、上线排查四个环节展开。

2. 商城模板骨架搭建：tabBar 参数与页面目录的复刻要点

2.1 app.json 里 tabBar 的关键参数与常见误配

拿到模板第一步要看的不是页面长什么样，而是 app.json。tabBar 在小程序里是声明式配置，所有 tab 的注册都在这里完成。仿小米商城风格的四个 tab 通常是这样：

{ "pages": [ "pages/index/index", "pages/category/category", "pages/cart/cart", "pages/user/user", "pages/goods/list/list", "pages/goods/detail/detail" ], "tabBar": { "color": "#999999", "selectedColor": "#FF6700", "backgroundColor": "#ffffff", "borderStyle": "black", "list": [ { "pagePath": "pages/index/index", "text": "首页", "iconPath": "images/tab/home.png", "selectedIconPath": "images/tab/home-active.png" }, { "pagePath": "pages/category/category", "text": "分类", "iconPath": "images/tab/category.png", "selectedIconPath": "images/tab/category-active.png" }, { "pagePath": "pages/cart/cart", "text": "购物车", "iconPath": "images/tab/cart.png", "selectedIconPath": "images/tab/cart-active.png" }, { "pagePath": "pages/user/user", "text": "我的", "iconPath": "images/tab/user.png", "selectedIconPath": "images/tab/user-active.png" } ] } }

这段配置里最容易被改坏的地方是 pagePath 与 pages 数组不同步。pages 数组决定小程序编译时注册哪些页面，tabBar.list 里的 pagePath 则告诉底部导航要去哪里，两者差一个大小写就会报“未找到入口页面”。其次是图标路径：tabBar 的 iconPath 只支持本地图片，模板里的占位图标在替换成新视觉稿之前，尽量保持原有文件名和尺寸，避免破坏布局。

有些模板会额外带 custom-tab-bar 目录，这是微信规定的自定义 tabBar 目录名，只要存在就被优先渲染。它适合做中间凸起按钮、购物车角标这类原生配置做不到的交互，但代价是每个 tab 页都要在 onShow 里通知自定义组件更新状态。如果只需要换品牌色，建议把 custom-tab-bar 直接移除，让模板回到原生 tabBar，省掉一整套消息同步代码。

提示：模板中若存在 custom-tab-bar 目录，app.json 里的 tabBar 配置只作为数据源，实际渲染逻辑全部由该目录下的组件接管。

2.2 页面目录与组件复用边界的划分

模板源码目录通常不会太复杂，但组件划分质量差异很大。有些模板把商品卡片在首页、列表页、搜索页复制三份，也有把搜索栏做成独立组件的。仿小米商城模板里复用率最高的五类组件是搜索栏、商品卡片、楼层导航、SKU 弹层和价格标签。建议二次开发时按以下结构整理：

src/ ├── app.js ├── app.json ├── app.wxss ├── components/ │ ├── search-bar/ │ ├── goods-card/ │ ├── floor-nav/ │ ├── sku-popup/ │ └── price-tag/ ├── pages/ │ ├── index/ │ ├── category/ │ ├── cart/ │ ├── user/ │ └── goods/ │ ├── list/ │ └── detail/ ├── mock/ │ ├── home.js │ └── goods.js └── utils/ ├── request.js └── cart.js

我一般会在组件里保留一层业务事件转发：组件内部只处理 UI 交互，跳转、埋点、请求交给页面去做。例如商品卡片的点击事件，组件通过 triggerEvent 抛给页面，再由页面决定是跳详情还是弹登录。这样一来，goods-card 在搜索结果页、活动页都能复用，不会因为业务不同被迫复制一份。

如果模板组件化程度不高，先按页面一页一页接入商品卡片，不要一口气全部组件化。商城模板改造最容易出问题的是页面同步期间导航串路径，所以组件化的同时，把每一页的跳转都集中到一个函数里统一维护会更可控。

2.3 自定义导航栏的顶栏高度计算

模板里如果复现了仿小米商城的沉浸式搜索栏，就避不开 statusBarHeight 适配。经典错误是写死padding-top: 44px，在全面屏机型上会直接盖住时间栏。建议用胶囊位置动态计算：

// utils/nav.js export function getNavHeight() { const menu = wx.getMenuButtonBoundingClientRect() const win = wx.getWindowInfo?.() || wx.getSystemInfoSync() return { statusBarHeight: win.statusBarHeight, navBarHeight: menu.height + (menu.top - win.statusBarHeight) * 2, rightGap: win.windowWidth - menu.right } }

这段代码先拿胶囊菜单距离屏幕顶部的 top，减掉状态栏高度，得到导航栏两端延展区域的高度，再乘 2 加上胶囊自身高度，即为自定义导航栏占位高度。模板页面里统一让getNavHeight()的返回值设置容器 padding，就能同时兼容刘海屏、胶囊居中的安卓和折叠屏。若模板基础库版本较老，没有 wx.getWindowInfo，就用 wx.getSystemInfoSync 兜底。

注意：启用自定义导航栏后，页面内容会直接顶到状态栏。如果只改了 WXML 没同步调整占位高度，顶部搜索栏和系统时间会重叠。

后面如果想把模板迁移成 uni-app 微信小程序并同时发布到其他端，这一块要特别小心：pages.json 里配置navigationStyle: "custom"后，普通页面标题栏消失，不同端对胶囊位置计算的结果不完全一致，多端适配时建议分别跑一遍真机预览再定占位高度。

3. 商城模板首页与商品链路还原：楼层、列表与 SKU 弹层

3.1 首页楼层数据结构的模板渲染

仿小米商城首页的骨架可以抽象成 banner、金刚区图标、分类导航和一排商品楼层。楼层是一个数组，每个楼层有自己的标题、跳转链接和商品列表，数据结构决定模板后续扩展的灵活性。

// mock/home.js export const homeData = { floors: [ { floorId: 1, title: '手机热卖', more: '/pages/goods/list/list?categoryId=phone', goodsList: [ { id: 1001, name: 'Xiaomi 14', price: 3999, image: '/assets/goods/1001.jpg' }, { id: 1002, name: 'Redmi K70', price: 2499, image: '/assets/goods/1002.jpg' } ] }, { floorId: 2, title: '家电专区', more: '/pages/goods/list/list?categoryId=appliance', goodsList: [ { id: 2001, name: '空气净化器', price: 1299, image: '/assets/goods/2001.jpg' } ] } ] }

对应的 WXML 常用写法是双层 wx:for：外层遍历楼层，内层遍历楼层里的商品。注意内层wx:for-item="goods"必须给单独的别名，否则会覆盖外层的 item。

<view class="floor" wx:for="{{floors}}" wx:key="floorId"> <view class="floor__header"> <text class="floor__title">{{item.title}}</text> <text class="floor__more">onReachBottom() { if (this.data.loadedAll || this.data.loading) return this.setData({ page: this.data.page + 1 }) this.fetchList() }

这里的 loading 状态非常关键，缺失时用户快速滚动会连续发出多个重复请求，返回后把相同数据渲染进去，模板就会出现卡顿或重复 key 警告。切换排序时，页面要把 list、page、loadedAll 一起重置回初始值，而不是只改 sort 后继续追加，否则会出现“前两页旧排序数据加后两页新排序数据”的混排。

列表卡片如果是双列瀑布，外层容器一般用 flex-wrap 让左右两列交替排布，视觉上最接近原版。商品卡片高度不稳定时，给 image 加mode="aspectFill"并固定容器高度，避免出现底边大量留白。

3.3 SKU 规格弹层的选择状态与库存联动

详情页的规格选择器是商城模板里最不容易改的模块。核心数据模型其实只有两部分：规格组合定义和 SKU 库存映射。

// 规格定义 const props = [ { key: 'color', name: '颜色', values: ['黑色', '白色'] }, { key: 'storage', name: '存储', values: ['8GB+256GB', '12GB+256GB'] } ] // SKU 库存映射，valueKey 用 | 连接 const skuMap = { '黑色|8GB+256GB': { price: 4299, stock: 13 }, '黑色|12GB+256GB': { price: 4599, stock: 0 }, '白色|8GB+256GB': { price: 4299, stock: 6 } } function getSelectedSku(selected) { const key = `${selected.color}|${selected.storage}` return skuMap[key] || null } function isStockValid(selected) { return getSelectedSku(selected)?.stock > 0 }

选择器要做两件事：选完整组合有库存时展示对应价格，未选完整时展示价格区间或提示“请选择规格”。置灰逻辑不建议做前端全量笛卡尔积计算，模板里的商品规格基本是几档有限组合，直接查 skuMap 判断 stock 是否为 0，逻辑最直接，也最不容易把服务端规则带偏。

点击规格按钮时，把当前按钮的规格值写进 selected 对象，再重新调用 isStockValid 判断。这里有一个常见误用：只判断当前按钮自身有无库存，不判断与其他规格组合后的结果。正确做法是点击后合并新值，再重新跑一次完整组合校验，否则会出现“第一个规格选完后所有按钮都置灰”的假死交互。

4. 模板数据层改造：mock 开关、请求封装与购物车状态

4.1 通过环境版本号切换 mock 与真实接口

许多商城模板直接把数据写在页面 data 里，这个阶段跑起来没问题，一旦联调接口就麻烦。更合适的做法是在数据层加一个环境开关，用小程序内置的__wxConfig.envVersion判断当前运行环境：

// config/index.js const env = typeof __wxConfig !== 'undefined' ? __wxConfig.envVersion : 'develop' export const config = { baseURL: env === 'develop' ? 'https://mock-api.example.com/v1' : 'https://api.example.com/v1', useMock: env === 'develop' }

各运行环境的数据源用途可以对照着看：

__wxConfig.envVersion在开发者工具和真机上都能取到，不需要手动改代码切换环境，配合 baseURL 就能避免上线忘了把 mock 切回真实接口的尴尬。注意在浏览器端或 uni-app 编译到其他平台时，__wxConfig不存在，所以代码里需要用 typeof 兜底。

还有一层限制得提前说：wx.request 的请求域名必须在小程序后台配置为合法域名。开发时可在开发者工具里勾选“不校验合法域名”，但真机预览必须配置。模板自带的 mock 数据如果走 http://localhost 这样的地址，真机上完全不可用，这也是为什么本地 mock 要封装成纯 JS 数据源，而不是依赖本地服务器。

注意：本地 mock 地址不要用 localhost，真机预览时访问不到；建议把 mock 数据直接放进 utils 层，用 Promise 包一层返回。

4.2 请求封装：token 注入与统一错误处理

模板里的请求封装至少要解决三件事：URL 统一拼接、token 自动注入、错误码统一提示。一个能直接替换页面里 wx.request 的封装如下：

import { config } from '../config/index' function request(path, { method = 'GET', data = {}, showError = true } = {}) { const token = wx.getStorageSync('token') return new Promise((resolve, reject) => { wx.request({ url: `${config.baseURL}${path}`, method, data, header: { 'Content-Type': 'application/json', ...(token ? { Authorization: `Bearer ${token}` } : {}) }, timeout: 10000, success(res) { if (res.statusCode >= 200 && res.statusCode < 300) { resolve(res.data) } else if (res.statusCode === 401) { wx.navigateTo({ url: '/pages/user/login' }) reject(res) } else { if (showError) { wx.showToast({ title: `服务异常 ${res.statusCode}`, icon: 'none' }) } reject(res) } }, fail(err) { if (showError) { wx.showToast({ title: '网络连接失败', icon: 'none' }) } reject(err) } }) }) } export const http = { get: (url, params) => request(url, { data: params }), post: (url, body) => request(url, { method: 'POST', data: body }) }

关键参数说明：

实际项目中还会遇到 statusCode 200 但业务 code 非 0 的情况，这种不建议在封装里统一弹提示，因为不同页面有自己的文案。业务错误交给各页面在 resolve 后自行判断，封装只处理传输层错误。改造时建议分两步：先把所有 URL 收拢到 config.baseURL，再把页面里的 success 回调抽到 http 层。

调接口时如果发现数据对不上，用微信开发者工具的 Network 面板就能看到请求 URL、请求头、返回结果和耗时，模板页面里的跳转参数和发请求顺序也能全程跟着看，不需要另装第三方抓包工具。

4.3 购物车状态集中管理与页面订阅

商城模板里最容易出事故的是购物车，因为它跨页面共享：详情页加入、列表页切换、购物车改数量、结算页读取。购物车状态若放在某个页面的 data 里，退出后就会丢。正确做法是给购物车建一个独立模块，页面只订阅其结果：

// utils/cart.js let cartList = [] const listeners = [] function publish() { const payload = { list: cartList, totalCount: cartList.reduce((sum, item) => sum + item.count, 0), totalAmount: cartList.reduce((sum, item) => sum + item.count * item.price, 0) } listeners.forEach((fn) => fn(payload)) } export const cartStore = { add(goods, count = 1) { const existed = cartList.find((item) => item.skuId === goods.skuId) if (existed) { existed.count += count } else { cartList.push({ ...goods, count }) } publish() }, updateCount(skuId, count) { const item = cartList.find((i) => i.skuId === skuId) if (item) { item.count = Math.max(1, count) publish() } }, remove(skuId) { cartList = cartList.filter((i) => i.skuId !== skuId) publish() }, subscribe(fn) { listeners.push(fn) return () => { const idx = listeners.indexOf(fn) if (idx > -1) listeners.splice(idx, 1) } } }

购物车模块用发布订阅模式，而不是把 cartList 挂到 globalData 上的原因很简单：globalData 只有取值能力，没有变更通知机制，页面无法知道数据变了。cartStore.subscribe返回的取消订阅函数，页面在 onUnload 时必须调用，否则下一个页面进栈时会持续消费上次订阅，导致多余渲染。

页面侧的使用方式：

import { cartStore } from '@/utils/cart' Page({ onLoad() { this.unsubscribe = cartStore.subscribe((cart) => { this.setData({ totalCount: cart.totalCount, totalAmount: cart.totalAmount }) }) }, onUnload() { if (this.unsubscribe) this.unsubscribe() } })

这段实现并不长，却能让所有页面共享同一份购物车数据，且不引入额外状态管理库。模板如果用的是 mobx-miniprogram，核心思想其实一样，只是把 listeners 换成了 observable。手写版依赖最少、行为透明，适合商城模板二开项目快速接管。

5. 模板上线前必改的三处细节：包体、首屏与真机调试

5.1 大图资源与分包配置

模板仓库里的截图和商品占位图往往直接塞在 assets 目录，主包很容易超 2MB。上线前先在开发者工具的代码依赖分析里查一遍，把只在活动页、售后页用到的图片和页面拆进 subpackages：

{ "subpackages": [ { "root": "packageActivity", "pages": ["pages/activity/index", "pages/after-sale/index"] } ] }

分包后主包只保留 tabBar 页面和公共组件，进入活动页、售后页时按需下载，冷启动速度会明显提升。未使用的图片批量删除也很顺手，在编辑器中搜索图片文件名，没有引用的直接删掉。tab 图标和顶部导航图标可以转成 base64 或 iconfont，进一步减少图片请求数。

5.2 首屏图片懒加载与加载页背景

模板首页常见的性能瓶颈是 swiper 轮播图一次性把所有大图加载完。给 swiper 的图片加 lazy-load 属性，商品卡片的 image 也统一加lazy-load="{{true}}"，配合mode="aspectFill"固定容器宽高。图片自身像素宽度不要超过实际展示宽度的两倍：750rpx 的设计稿导出 375px 宽的文件就够了，原图直出会让体积放大好几倍。

<image class="banner__img" src="{{item.img}}" mode="aspectFill" lazy-load bindtap="goBanner" >// app.js 开发阶段临时开启 wx.setEnableDebug({ enableDebug: true })

开启后真机屏幕右下角会出现 vConsole 悬浮球，能看到 console 输出、网络请求和 system 信息。验证购物车状态的一个小技巧是直接在 vConsole 里执行wx.getStorageSync('cartList')：如果完全查不到，说明模板的购物车没有持久化，冷启动后会丢数据。

最后跑一遍“详情页选规格 → 加入购物车 → 回到首页 → 再进购物车改数量”的完整链路，全程打开 vConsole 的 Network 面板，确认每次操作产生的请求顺序正常。这套检查每次改动模板后都花不了两分钟，但能提前暴露大半数据串台问题；把这条验证路径放在模板 README 的第一行，比任何注释都管用。

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