简介一份包含120多套微信小程序模板源码的合集面向前端开发者、小程序初学者和需要快速搭建项目原型的站长。素材多为2017年前后产出部分模板开箱即用部分因接口版本或基础库变化需自行修复下载后可按需筛选用于学习页面结构、组件写法与交互逻辑。压缩包共含2000个文件核心类型以js、wxml、wxss、json和png为主js负责脚本逻辑wxml与wxss搭出页面骨架和样式json完成项目与页面配置png等图片文件提供界面素材另有html、css、scss及少量服务端示例可辅助理解完整开发流程整体约207.59MB。已有287人学习下载。虽然年代较早、质量参差不齐但胜在数量多、类型广既可作UI风格与布局灵感库也能在修复过程中锻炼调试和兼容性处理能力多套模板交叉比对还能帮助理解不同目录结构与代码组织方式适合作为本地素材长期保存。1. 现在做小程序别从零开始写代码模板源码是效率翻倍的入场券做了几年小程序开发我见过太多人栽在同一件事上明明一周能上线的小程序硬是从 app.json 手搓页面最后拖了一个月。微信小程序的模板源码本质上是把“页面结构 交互逻辑 基础样式 接口封装”打包好的半成品拿到手之后改改文案、换换图片、对接自己的后端就能直接提交审核。这套 120 多套的各类别模板包覆盖电商、餐饮、美业、社区、教育、工具等多个类目适合两类人一类是接外包单子的开发者直接拿模板做项目底子省掉前期框架搭建另一类是产品经理或运营想快速验证想法先跑通业务流程再迭代。它能解决的核心问题就是把你从重复造轮子的泥潭里捞出来让你把时间花在业务逻辑和后端对接上而不是每做一个新项目都从零开始搭 tabBar。2. 模板源码的真实构成从目录结构到页面复用逻辑先说个容易误解的地方很多人以为模板源码就是一个个完整可运行的小程序其实不然。这套资源里的“模板”分成两类一类是完整项目包包含完整的 app.js、app.json、project.config.json导入开发者工具就能跑另一类是页面级模板只有单个页面的 wxml、wxss、js 和 json需要自己拼接进现有项目里。搞清楚这个区别你的使用效率会差出两三倍。2.1 一套标准模板的目录拆解你必须认识的几个配置文件拿到一套模板源码第一件事不是急着看页面效果而是先理解它的骨架。一个规范的微信小程序模板核心目录和文件通常是这样组织的project-root/ ├── app.js # 应用入口注册小程序、初始化全局变量 ├── app.json # 全局配置页面路径、窗口样式、tabBar、networkTimeout ├── app.wxss # 全局样式公共颜色变量、通用按钮样式、字体规范 ├── sitemap.json # 搜索索引配置不配置默认全屏蔽 ├── project.config.json # 项目配置appid、编译设置、ES6转ES5开关 ├── pages/ │ ├── index/ │ │ ├── index.wxml # 页面结构 │ │ ├── index.wxss # 页面样式 │ │ ├── index.js # 页面逻辑数据绑定、事件处理 │ │ └── index.json # 页面级配置独立窗口样式、组件引用 │ └── cart/ │ ├── cart.wxml │ ├── cart.wxss │ ├── cart.js │ └── cart.json ├── components/ # 自定义组件目录如购物车数字角标 ├── utils/ │ └── request.js # 封装好的 wx.request通常含 baseURL 和 token 处理 └── images/ # 静态资源注意小程序包体积限制是 2MB 主包这里有两个参数控制着你后面会不会踩坑。第一个是app.json里的style: v2它决定启用新版组件样式如果你的微信开发者工具版本旧某些组件样式会错乱第二个是project.config.json里的appid默认是测试号你要改成自己的 AppID 才能真机预览和上传。我的习惯是拿到模板先全局搜索appid看它用的是测试号还是某个具体的开发者 ID如果是别人的正式 AppID会出现“无法上传、无法预览”的报错这几乎是模板下载后第一个拦路虎。2.2 页面级模板的多场景复用电商列表页改造成外卖点单页在 120 多套模板里你一定会遇到“这套页面的布局我只能用到一半”的情况。我一般不建议你去改别人的页面整体结构而是把页面拆成“区块”来复用。举个例子一套典型的电商首页模板包含以下几个区块搜索栏、轮播图 banner、金刚区图标导航、瀑布流商品列表、底部 tabBar。当你拿它去做一个外卖点单小程序时商品列表区块、购物车角标组件、优惠券弹窗都是可以直接复用的。// 外卖点单页复用商品列表时只需在 index.json 中调整分组字段 { usingComponents: { goods-card: /components/goods-card/goods-card }, navigationBarTitleText: 附近美食, enablePullDownRefresh: true, backgroundColor: #f2f2f2 }这段配置的核心在usingComponents字段它声明了当前页面要引用的自定义组件。你在电商模板里找到goods-card这个组件目录把它整体拷贝到自己项目的components文件夹下然后在页面 json 里引用它wxml 里就能直接用goods-card goods{{item}} bindtaponCardTap/goods-card。这个组件的入参和出参决定你能复用得有多顺畅所以选模板的时候优先看它有没有把商品卡片抽成独立组件而不是把商品布局写死在页面的 wxml 里。组件化了你换接口数据、调样式、加新字段都只用动一个文件。2.3 样式与主题切换维度改两处就能换品牌色模板里最常见的个性化需求是换主色调比如把默认的橙色改成蓝色。我看过很多新手直接在页面的 wxss 里把color: #ff6600全部替换成#0099ff这在小项目里可行但模板包动辄几十个页面文件全局替换费时且容易漏。更合理的路径是通过app.wxss里的 CSS 变量配合主题类名实现/* app.wxss */ page { --theme-primary: #ff6600; /* 主按钮、价格、选中态 */ --theme-gradient: linear-gradient(135deg, #ff9900, #ff6600); --theme-bg-light: #fff5e6; /* 模块底色 */ --theme-border: #ffd591; /* 描边和分割线 */ } .theme-dark { --theme-primary: #3b82f6; --theme-gradient: linear-gradient(135deg, #60a5fa, #3b82f6); --theme-bg-light: #eff6ff; --theme-border: #bfdbfe; }然后在app.js里维护一个globalData字段比如themeMode: default页面加载时判断当前模式给最外层节点加对应的 class 名。这套方案的另一个好处是模板里的图片资源如果也是橙色系的你就得连图片一起换。图片替换时注意小程序包体积单张高清图压到 200KB 以内是个合理阈值直接用media做响应式在真机上会有些限制不如用image组件自带的modeaspectFill配合压缩兼顾清晰度和包体积。如果模板里用的是iconfont字体图标那是好事可以用 CSS 变量控制颜色换主题色只需改一行。3. 界面的交互层与业务层谁负责让模板真正“活起来”很多模板下载下来跑起来看静态页面非常漂亮但一接入真实数据就露馅。常见的现象是首页商品列表加载转圈永远不结束、支付按钮点一下没反应、个人中心头像更换报错。这一章探讨的是模板里最容易造假和出问题的地方——交互逻辑与数据流。3.1 假数据与 Mock 接口的辨别方法别被漂亮 demo 骗了模板为了让展示效果好看经常在data里写死几十条假数据或者封装好的utils/request.js里指向一个假接口地址。你需要做的是在接后端之前先分清哪些数据是写死的哪些是动态请求的。一套成熟的模板业务数据一定是从接口拿的而 UI 配置数据比如轮播图列表可能写在前端配置里。// utils/request.js 中的典型封装注意看 baseURL 的占位符 const BASE_URL https://your-api-server.com/api/v1; // 需要替换成你的后端地址 function request(path, method GET, data {}) { const token wx.getStorageSync(token); return new Promise((resolve, reject) { wx.request({ url: ${BASE_URL}${path}, method: method, data: data, header: { Content-Type: application/json, Authorization: token ? Bearer ${token} : }, success: (res) { // 惯例后端返回 { code: 0, data: ..., message: ... } if (res.data.code 0) { resolve(res.data.data); } else { wx.showToast({ title: res.data.message, icon: none }); reject(res.data); } }, fail: (err) { wx.showToast({ title: 网络异常请稍后重试, icon: none }); reject(err); } }); }); } module.exports { request, BASE_URL };看到这段代码你要确认三件事第一后端返回的code字段约定是什么是0还是200有的模板后台用的200字段名叫status而不是code不统一的话你接后端时所有判断逻辑都得改第二BASE_URL是写死的还是从某个配置文件读取的我推荐改成从app.js的globalData里读这样换环境时不用改代码第三token 失效的处理有没有做好的模板会在返回码是 401 时自动跳转登录页差的模板只会弹个“登录过期”的 toast你得自己补上跳转逻辑。关于登录模板里如果有wx.login的封装最好是校验一下它有没有换成新版方式旧的方式在现网环境容易拿到无效 code导致登录失败。3.2 低频页面与表单逻辑模板里的“假按钮”重灾区很多模板的初级版会在结算页、提交订单页、表单页做出很完整的 UI但按钮绑定的事件是空的或者写死了一个wx.showToast。这是因为模板作者不想让 demo 流程走得太深毕竟按钮触发真实请求需要后端配合。这类页面恰恰是你验收模板质量时最需要翻出来看代码的。// 常见模板里的“半成品”按钮事件你一定要补全的部分 Page({ data: { orderInfo: null, paymentType: wechat }, // 原模板可能是submitOrder() { wx.showToast({ title: 提交成功 }); } // 需要改成真正的提交逻辑 submitOrder() { // 防重复点击加锁 if (this.data.submitting) return; this.setData({ submitting: true }); const orderData { goodsList: this.data.goodsList.map(item ({ goodsId: item.id, count: item.count, skuId: item.skuId })), addressId: this.data.addressId, remark: this.data.remark, paymentType: this.data.paymentType }; wx.showLoading({ title: 提交中, mask: true }); request(/order/create, POST, orderData) .then(res { wx.hideLoading(); // 未支付订单跳转收银台而非直接提示成功 wx.navigateTo({ url: /pages/cashier/index?orderId${res.orderId} }); }) .catch(() { wx.hideLoading(); this.setData({ submitting: false }); }); } })写这段时最容易忽略的点是防重复点击。模板里如果没加这个锁用户在弱网环境下连续点十次“提交订单”就会创建十个重复订单。另外注意setData的调用时机不要在then回调里不加判空就连续setData小程序对频繁setData有性能警告数据量大时页面会掉帧。还要注意wx.navigateTo的页面栈限制是十层如果订单流程走了好几步最后一步应该用wx.redirectTo或者wx.reLaunch跳转。3.3 通知栏与订阅消息的一体化设计模板有没有拉到“可用”级别一个模板是停在“好看”还是达到“能用”差距主要看模块是否闭环。以订阅消息为例很多模板在个人中心里做了个“消息通知”的开关但点击开关只改本地 storage并没有真正调起wx.requestSubscribeMessage。这类半成品逻辑在审核时容易被拒原因通常是“涉及收集用户信息但无明确用途”。如果你拿到的模板也有这种半吊子实现补全它并不复杂用户触发某个业务操作时比如支付成功再调订阅消息授权别在首页一进来就弹授权框微信官方对高频订阅提醒的审核比较敏感。// 在支付成功回调里请求订阅而不是在登录时 function requestNotifyPermission() { const tmplIds [ JgJg8fds9kLk8rS3b7vK2mWzA1R4cVbNqXyEo09dfghJkl, // 订单发货提醒模板ID需在后台申请 pQkLmNvBzXdSfGhJkLqWeRtyUioPzXcVbNmQwErtYuIoPl // 售后处理进度模板ID需在后台申请 ]; wx.requestSubscribeMessage({ tmplIds: tmplIds, success(res) { // res 对象以模板ID为 key值为 accept / reject / ban const granted tmplIds.some(id res[id] accept); if (granted) { wx.setStorageSync(notify_granted, true); } }, fail() { // 用户拒绝或调起失败不阻塞主流程 console.warn(subscribe message request failed); } }); }这里的模板 ID 要在小程序后台申请不同类目的模板库可用性不同电商类目下“发货提醒”订阅是一次性授权的每次订阅只能推一条用户下次下单还得重新订阅。这个行为约束直接决定你后端推送逻辑的设计——要么每次订单状态变化前主动检查并请求授权要么把多条业务通知合并成一条模板消息推送。模板里如果对这块的注释不够详细去微信官方文档查“订阅消息”的最新规则是第一优先级。另外如果你的模板量很大注意检查app.json里的permission字段有些旧模板会在里面声明scope.userLocation但代码里根本没有使用定位这种多余的权限声明审核时容易被驳回建议一并清理。4. 模板选型与质量检验120 套资源怎么淘、淘完怎么验收面对收纳了 100 多套模板的资源包最容易犯的错误是“全都下载下来再慢慢挑”。这样做有两个坏处一是项目目录混乱每个模板可能包含大量静态资源图片占用硬盘空间二是不同模板的第三方依赖组件互相冲突最后哪套都跑不起来。正确姿势是先看清单再定用途最后按需取用。4.1 按业务类目筛出“可改造程度”最高的候选模板模板不是越多越好而是跟你业务目标越贴合越好。120 多套模板如果按类目划分大致能归为电商交易类含商城、拼团、秒杀、分销、本地生活类餐饮、美容美发、健身、宠物、内容社区类论坛、资讯、短视频、工具类日历、记账、打卡、企业展示类官网、名片、服务预约。这里有一个判断可改造程度的经验指标翻看模板的 pages 目录哪些页面是业务通用页、哪些是垂直专属页。例如“拼团商城”模板里的“团详情页”、“邀请好友页”就非常垂直你如果要做普通的 B2C 商城这两个页面大概率用不上反过来它的“商品详情页”、“购物车页”则可复用率达到九成。选品时我会做的操作是打开app.json里的pages数组把页面列表复制出来画几张卡片标注哪些是必留、哪些是可删、哪些是参考但不直接搬运这个动作半小时内能帮你锁定 5-8 套重点深读的模板。另外也能从模板没有明显报错的时间维度来预筛模板包的创建时间在近一年内其project.config.json里的libVersion基础库版本通常不会太低太低的基础库会导致新写的 async/await 语法在低版本客户端上运行报错。如果看到libVersion是 2.x 的早期版本就得慎重考虑升级成本。4.2 导入编译阶段的三项强制检查清单确定了候选模板后接下来是逐套导入微信开发者工具检验它“开箱即用”能到什么程度。我的强制检查清单包含三个维度全部半小时内能完成检查项操作方式通过标准常见翻车现场编译通过性导入后直接点“编译”无红色报错缺少 node_modules 依赖或 sitemap.json 配置错误控制台警告打开调试器–Console 面板无第三方库报错某个组件未注册而页面内已引用报Component is not found真实设备预览手机扫码预览页面切换流畅、无白屏打开页面报require路径错误或静态资源 404第一项编译通过性里一拿到模板就npm install是个好习惯前提是模板里有package.json。如果模板是基于原生小程序语法而非第三方框架如 uni-app、Taro则不需要安装依赖直接编译即可。第二项控制台警告里Component is not found是出现率最高的报错原因通常是某个页面 json 文件的usingComponents引用了不存在的路径或者组件目录本身不全。第三项真机预览里比较阴间的坑是某些组件依赖了一部分只能在 PC 端调试的 API比如wx.createSelectorQuery的某些回调真机上拿到的节点信息为 null这需要你针对报错的页面单独做兼容处理。注意这一套检查做完如果 10 个模板里有 7 个连编译都过不了说明该资源包大概率是从不同渠道拼凑来的里面混有老项目残留需要优先挑选里面有完整文档或 demo 截图的那几套来用。4.3 一套模板同时跑通“前端 后端 数据库”有多难严格来说微信小程序模板很少附带可跑通的后端系统。大多数资源包里的“后端”就是几个 mock 接口有的甚至直接写死返回数据。所以你要对“开箱即用”有一个清醒预期前端页面基本可靠交互逻辑有七八成可用后端与数据库需要自己对接。从另一个角度讲如果一套模板兼容了云开发环境比如在app.js里能看到wx.cloud.init的调用那这套模板的价值会显著高于普通纯前端模板因为你可以把订单、用户、商品等数据直接存到云数据库省去自建服务器的部署成本。但要注意云开发的收费模式是按调用次数和存储量计费如果模板里某个页面循环请求数据库账单会涨得比较快上线前要仔细审查云函数的调用频率。无后端、纯静态加 mock 也不是没用它适合你在初期用来画原型、给团队演示流程到了真实开发阶段再接后端。5. 常见问题与避坑记录从模板运行错误到审核被拒的实锤经验这一章是实操环节最见真章的地方。我把自己和身边开发者踩过的坑按“现象 → 原因 → 解决”的方式列出来每一条都有血泪在里面。别小看这些细节它们决定了你下载这套模板后是花两小时跑起来还是掉进坑里浪费一整天。5.1 编译报错app.json未找到或sitemap.json配置错误现象导入模板后点击编译开发者工具报错“找不到 app.json 文件或者读取失败”。原因项目根目录结构不对模板压缩包内可能多套了一层文件夹比如解压后根目录下是一个命名随意的大文件夹真正的项目文件在它的子目录里。解决把外层壳文件夹重命名为项目名保证app.json直接在根目录下或者在导入时选择“导入项目”而不是“打开目录”手动定位到真正的项目根路径。这个坑出现率极高因为很多压缩包在打包时没有把内层目录清理干净。5.2 页面白屏与数据渲染不出来接口返回的数据结构与模板预期不一致现象真机预览时首页除了顶栏其余一片空白PC 端调试器 Console 里能看到Cannot read property map of undefined之类的报错。原因模板开发时对接的假数据字段是goodsList而你从后端拿到的真实接口返回字段叫items或者接口返回整体是字符串而非对象数组。解决先打开调试器确认接口实际返回结构再修改index.js里data的初始值以及setData时的字段映射注意把goodsList: []的初始值写好避免undefined.map。这是模板接入真实后端时最耗费时间的一类问题建议像 2.1 节那样先在request.js统一处理好数据解包逻辑让页面层拿到的永远是对象数组。5.3 真机预览正常但上传代码后无法通过审核类目选择与权限声明不匹配现象模板跑得好好的提交审核却被驳回理由通常是不属于你选择的类目或收集用户信息但未声明用途。原因模板内置了某些能力比如获取用户头像、读取位置、收集手机号但你的小程序类目并不支持这些权限。解决先确认自己的服务类目能在后台添加的权限尽量与模板代码涉及的能力保持一致如果模板带有“分享到朋友圈”但你的类目不支持则要移除相应按钮。这类问题跟代码质量无关是业务合规层面的最容易被人忽略且驳回一次之后二次审核会更严格。我一般在上传之前先检查app.json里的permission字段和实际调用的 API 是否一致多花十分钟省一周时间。5.4 分包加载后 tabBar 页面失效tabBar 页面必须在主包现象把模板里非核心页面拆到subpackages之后首页底部的 tabBar 还能显示但点击“购物车”直接跳转失败报找不到页面。原因app.json的tabBar.list字段中配置的页面路径必须在主包pages目录内不能指向分包路径。解决保持 tabBar 对应页面在主包把详情页、订单页这些非 tabBar 页面分包处理。另外tabBar 页面不能设置为分包页面这个问题在模板量较大、你想拆分冷启动包大小时尤其普遍。5.5 模板仓库内多套模板的 component 路径相互污染现象同时参考 A 模板和 B 模板时把 A 模板的组件拷贝到项目里却发现组件引用了某个utils目录下的文件而那个文件只存在于 B 模板里导致整个项目编译报错。原因组件内部存在相对路径引用拷贝组件时没有连同它依赖的工具文件一起拷贝。解决拷贝自定义组件时直接拷贝整个组件目录并检查组件内部有没有require(../../utils/xxx.js)这类跨目录引用一并补齐。这是“拼包”时最容易忽略的隐蔽问题它的排查成本高因为报错信息只提到某个文件找不到不会跟你说是哪个组件引用了它。6. 从模板到上线的二次开发技巧警惕小程序包体积的膨胀模板再多最终上线时都要回归到“包体积”这关。小程序主包限制是 2MB超过之后需使用分包加载而如果你选了一套塞满高清图的模板随便加点业务代码就可能撞上体积红线。我分享两个常用手段一是用 WebP 格式替换模板里的 PNG 和 JPG 大图在同等视觉质量下通常能减少 30% 到 50% 的体积二是把不常用的页面如帮助中心、关于我们、用户协议拆进分包并给它们加一个入口判断。{ pages: [ pages/index/index, pages/cart/cart, pages/user/user ], subpackages: [ { root: packageA, pages: [ pages/order-list/order-list, pages/order-detail/order-detail, pages/after-sale/after-sale ] }, { root: packageB, pages: [ pages/help/help, pages/about/about ] } ] }配置分包之后访问分包页面要走wx.navigateTo链接形式是/packageA/pages/order-list/order-list不能用原来的路径。这里有个隐含的坑如果你用wx.switchTab跳 tabBar 页面是不受分包限制影响的依然要求目标页在主包内。分包也不能依赖主包之外的静态资源所有图片和公共 JS 要么放主包要么随分包携带否则真机上报错找不到模块。另一个经验是如果模板的启动首页有很多首屏数据可以考虑把耗时接口拆到分包页面加载让主包首屏只渲染静态骨架屏体感会快很多。讲真从 120 多套模板里筛出一套合适的再经过上述体积优化和逻辑补全上线一个中规中矩的小程序并不难。模板的本质不是让你偷懒而是让你把时间和精力集中在真正需要思考的业务差异点上。从那以后我每次接手新模板都会强制走一遍“先看 app.json → 再跑编译 → 再查接口 → 再审一遍权限声明”的流程看起来多花半小时实则在为你后面省出好几个整天。希望帮到你。本文还有配套的精品资源点击获取