简介一套仿小米商城风格的微信小程序商城模板适合前端初学者、小程序开发人员以及需要快速搭建商城原型的个人或团队参考学习。资源以完整源代码和界面截图为核心包含全局配置与页面入口、样式表、工具类封装等典型电商项目结构覆盖首页、日志等基础页面便于直接导入微信开发者工具运行或二次扩展。压缩包共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 只支持本地图片模板里的占位图标在替换成新视觉稿之前尽量保持原有文件名和尺寸避免破坏布局。参数类型作用常见误配pagePathstring导航指向的页面路径与 pages 数组不一致或漏注册iconPathstring未选中态的本地图标写成 http 链接后 tabBar 不显示图标selectedIconPathstring选中态的本地图标缺失时选中态只剩文字像按钮消失color/selectedColorhex普通态与选中态文字颜色只改一处结果双色并存有些模板会额外带 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 在搜索结果页、活动页都能复用不会因为业务不同被迫复制一份。组件复用处边界建议search-bar首页、分类页、商品列表只负责输入与事件抛出不持有搜索历史goods-card首页楼层、列表、搜索结果数据下行、事件上行不直接跳页面floor-nav首页接收楼层数据内部分发竖排卡片sku-popup详情页、购物车改规格内部管理规格选择态结算逻辑交给页面如果模板组件化程度不高先按页面一页一页接入商品卡片不要一口气全部组件化。商城模板改造最容易出问题的是页面同步期间导航串路径所以组件化的同时把每一页的跳转都集中到一个函数里统一维护会更可控。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?categoryIdphone, 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?categoryIdappliance, goodsList: [ { id: 2001, name: 空气净化器, price: 1299, image: /assets/goods/2001.jpg } ] } ] }对应的 WXML 常用写法是双层 wx:for外层遍历楼层内层遍历楼层里的商品。注意内层wx:for-itemgoods必须给单独的别名否则会覆盖外层的 item。view classfloor wx:for{{floors}} wx:keyfloorId view classfloor__header text classfloor__title{{item.title}}/text text classfloor__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 加modeaspectFill并固定容器高度避免出现底边大量留白。3.3 SKU 规格弹层的选择状态与库存联动详情页的规格选择器是商城模板里最不容易改的模块。核心数据模型其实只有两部分规格组合定义和 SKU 库存映射。// 规格定义 const props [ { key: color, name: 颜色, values: [黑色, 白色] }, { key: storage, name: 存储, values: [8GB256GB, 12GB256GB] } ] // SKU 库存映射valueKey 用 | 连接 const skuMap { 黑色|8GB256GB: { price: 4299, stock: 13 }, 黑色|12GB256GB: { price: 4599, stock: 0 }, 白色|8GB256GB: { 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 }各运行环境的数据源用途可以对照着看环境envVersion典型数据源用途开发版develop本地 mock 数据纯前端页面开发体验版trial测试后端UI 联调与真机验证正式版release生产后端提审与线上运营__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 }) }关键参数说明参数默认值说明path无接口路径自动拼接 baseURLmethodGET请求方法data{}请求参数showErrortrue置为 false 时屏蔽默认错误提示适合静默刷新 tokentimeout10000超过该毫秒数触发 fail 回调实际项目中还会遇到 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}}配合modeaspectFill固定容器宽高。图片自身像素宽度不要超过实际展示宽度的两倍750rpx 的设计稿导出 375px 宽的文件就够了原图直出会让体积放大好几倍。image classbanner__img src{{item.img}} modeaspectFill lazy-load bindtapgoBanner >// app.js 开发阶段临时开启 wx.setEnableDebug({ enableDebug: true })开启后真机屏幕右下角会出现 vConsole 悬浮球能看到 console 输出、网络请求和 system 信息。验证购物车状态的一个小技巧是直接在 vConsole 里执行wx.getStorageSync(cartList)如果完全查不到说明模板的购物车没有持久化冷启动后会丢数据。最后跑一遍“详情页选规格 → 加入购物车 → 回到首页 → 再进购物车改数量”的完整链路全程打开 vConsole 的 Network 面板确认每次操作产生的请求顺序正常。这套检查每次改动模板后都花不了两分钟但能提前暴露大半数据串台问题把这条验证路径放在模板 README 的第一行比任何注释都管用。本文还有配套的精品资源点击获取