微信小程序源码合集：选型、运行、改造与避坑全解析

简介：合集收录160套微信小程序源码，覆盖电商购物、外卖点餐、电影资讯、求职招聘、天气工具、休闲娱乐等众多场景，含AppleMusic、知乎日报、豆瓣图书、移动商城、拼团倒计时等典型项目，既适合前端新手对照学习，也方便进阶者参考架构和组件设计。包内共8133个文件，以js逻辑、wxml结构、wxss样式、json配置四类核心代码为主，同时有大量png切图和部分md说明文档，整体约217.34MB，能较完整地还原多套小程序的工程目录。上手时既可整包运行体验交互流程，也可单独提取城市天气、科学计算器、省市选择控件、轮播图等成熟模块进行二次改造，其中移动小商城还包含基于Node的前后台实现，满足从界面展示到数据联调的学习需求。该资源已有6125人学习，下载后按需检索即可快速定位参考代码，实战价值较高。

1. 160套小程序源码合集能干嘛：先弄明白这批源码的真实身份

你拿到一个“160套小程序源码微信小程序源码合集”，第一反应通常是赶紧挑一个最漂亮的项目跑起来。我要先泼一盆冷水：这160套里面真正能跑、你又用得上的，可能只有三五十套，剩下的要么是转手包重复打包、要么是半成品课程设计。这个资源的价值不在于数量，而在于你会不会拆、会不会改。

对刚接触微信小程序的开发者，这套源码合集是练手改代码的好原料；对已经写过一两个项目的熟手，它更像是组件参考库——订单流程、个人中心、商品卡片这类通用模块，提取出来能省不少时间。但如果你想拿它直接上生产，几乎不可能：缺少有效的 AppID、后端域名失效、登录方式停留在两年前的接口。这篇文章按选型、运行、改造、避坑、验证的顺序讲透，最后给一份能直接抄作业的检查清单。

2. 拆包先分类：原生小程序、uniapp、wepy 混在一起怎么选型

合集压缩包解开之后，别急着拖进微信开发者工具。这160套来源五花八门：有GitHub上的开源demo，有课程设计成品，有培训班结业项目，甚至有几份是从旧论坛搬来的残缺源码。先用十分钟把结构摸清楚，能省出后面一整天的排错时间。

2.1 打开压缩包先看的三个文件：readme、目录清单和 project.config.json

我最常做的第一步，是先看目录清单和readme，再去找project.config.json。终端里执行两行命令就能把结构摸清：

# 列出压缩包内所有文件，前 40 行足够看出目录层级 unzip -l 160-src.zip | head -40 # 解压后，全目录搜 project.config.json，确认有多少个真正的微信小程序根目录 find . -name "project.config.json" -maxdepth 3 | head -30

第一行命令输出会告诉你压缩包是不是套了一层又一层目录；第二行命令站在源码根目录执行，能快速统计出有多少个项目自带微信开发者工具需要的配置文件。

这个检查的要点是判断“能不能直接导入”。微信开发者工具要求导入的目录必须包含 app.js、app.json、app.wxss 和 project.config.json；如果只有页面文件没有配置文件，导入就会失败。常见套路是：外层是“160套合集”文件夹，里面每个子目录再压缩一层，你需要先解压所有层级，再逐个导入。建议先挑目录名清晰、带 readme 或 demo 截图的项目优先尝试。

2.2 原生小程序、uniapp、wepy、Taro 的区别：哪个先跑哪个做参考

合集中最常见的四类技术栈，判断方式很简单：

这里有个链接是很关键的：很多合集里写的是“小程序源码”，实际是 uniapp 工程。你要先看有没有 package.json 和 src 目录；如果有，导入微信开发者工具之前必须先完成一次 uni-app 的微信小程序打包，否则工具只会报“找不到 app.json”。

而对真正想把这160套用起来的人来说，我建议优先跑原生项目。原因是 uni-app 和 Taro 的构建链路各有各的坑：Node 版本不对、依赖装不上、样式在跨端之后排版混乱，加起来足够消耗一个周末。原生项目只要有一个有效的 AppID 和正确的目录，五分钟之内就能进入编译状态。

2.3 看接口与登录代码识别项目年龄：老接口怎么对应基础库版本

源码的“年龄”决定了改造工作量。快速翻几个项目的 pages 目录下代码，看三点就能判断新旧：

第一，页面里有没有高频使用wx.getUserInfo。这套授权接口在基础库更新之后已经被官方指认为旧接口，现在调用拿到的只是默认头像和昵称。第二，wx.request有没有被 Promise 封装，还是 callback 嵌套到底。第三，项目有没有用分包加载、云开发这类相对新的工程能力。

一个典型的老项目是：app.js 里调用wx.login拿到 code，再通过wx.request发到自建后端换 openid；页面上用wx.getUserInfo弹窗获取头像昵称。这种代码对应的是两三年前的开发模式，需要理解基础库版本和接口生命周期的对应关系，才能判断哪些能改、哪些直接删掉。

判断项目年龄的意义在于选改造对象：新项目改起来轻松，老项目可能一个页面里的接口全都过期。合集中大概有三分之一是明显老旧的，不必浪费时间，直接跳过。

3. 跑通第一套源码的完整流程：导入、报错排查与编译验证

选好一个目标项目之后，接下来的目标只有一个：让它在微信开发者工具里不报错的跑起来。这套流程我重复过几十次，只要项目不是残缺的，最多一小时就能走到验证阶段。

3.1 project.config.json 和测试号：导入前要改的两个配置项

微信开发者工具导入项目时，会要求填项目目录、项目名称和 AppID。这里有个关键选择：如果源码的 project.config.json 里写的是作者自己的 appid，你没有那个账号的权限，通常先直接选“测试号”来运行。测试号不需要注册小程序，适合本地开发和演示，但不能上传体验版。

导入之后，在工具里打开 project.config.json，用下面这份配置作为参考：

{ "appid": "touristappid", "projectname": "demo-from-160", "setting": { "urlCheck": false, "es6": true, "postcss": true, "minified": true }, "miniprogramRoot": "miniprogram/" }

参数说明：appid 为touristappid表示游客模式，也就是测试号；urlCheck: false是最重要的开发期开关，关闭后工具不会校验 request 接口的 HTTPS 域名是否在合法域名列表里。es6: true让工具帮你把 ES6 语法转成 ES5，老项目里大量用了箭头函数和 Promise，不开这个会报语法错；miniprogramRoot指向的是小程序代码根目录，如果项目结构里把代码放在miniprogram/子目录，这个字段必须写对。

实际导入中还可能遇到“无效 appid”的弹窗。此时在工具右上角的“详情-基本信息”里改成测试号即可。不要在导入接口里硬填一个不存在的 AppID，那样编译能过，但预览、真机调试全都做不了。

3.2 第一次编译报错怎么排查：按错误优先级逐层过

编译报错不用慌，次序排好，九成问题能自己定位。我会按“配置文件→页面文件→接口→样式”的顺序来排。

先看到的是“未找到 app.json”或“app.json 读取失败”，这表示导入的目录根本不是小程序根目录。终端跑一下：

find . -maxdepth 3 -name "app.json" | while read f; do echo "$f"; done

如果结果是多个 app.json，说明这个项目是聚合了多端产物；找到离 project.config.json 最近的那一个，把导入目录切到那一层。

接着是“编译错误：pages/index/index.js 不在 app.json 中注册”之类。打开 app.json 的 pages 数组，删掉不存在的路径，或者把缺失的页面文件补回来。很多合集源码是作者写了一半就上传的。这里的处理原则是：宁可少页面，不让编译卡死。

网络类的报错“域名不在合法域名列表中”在开发期直接忽略，用开发者工具右上角“详情-本地设置-勾选不校验合法域名”解决。WXML 语法错误会在 Console 里显示具体行号，多半是标签没闭合、或者用了已经移除的scroll-into-view用法这类老 API。

3.3 编译通过不代表能跑：检查请求、渲染、页面切换

编译过后，模拟器把首页渲染出来只是第一步。我一般做三轮功能检查：点击底部 tabBar 的每个页面，看有没有白屏；再打开调试器的 Network 面板，看 wx.request 请求有没有返回数据；最后切到 AppData 面板，确认网络返回的数据真的写进了 setData。

这里有个最容易翻车的点：包大小限制。老项目图片经常动辄几兆，一预览就报“代码包大小超出限制”。处理方式是把不用的页面从 app.json 里删掉，图片压缩到 100KB 以内，如果项目本身结构复杂，用分包加载：

{ "pages": [ "pages/index/index", "pages/order/order" ], "subPackages": [ { "root": "pages/activity", "pages": [ "list/list" ] } ] }

分包说明：主包保留首页和核心流程，活动页、优惠券这类低频页面放进 subPackages，用户访问时才加载对应的包体积。主包有 2MB 上限，分包能帮你在不改逻辑的前提下绕开上传限制。注意 activity 页面的相对路径和跳转路径要写完整，否则分包里的页面跳转全会失败。

三轮检查做下来，如果页面上有数据、点击切换不报错、真机预览正常，这套源码才算真正“跑起来”。

4. 改造出一套自己的小程序：改名、换接口、登录态与导航栏适配

跑通只是开始，大多数人要的是把这个合集里的项目改成自己的东西。改造的方向和顺序有讲究，先从全局配置动刀，再到数据层和登录层，最后处理样式兼容。

4.1 改项目名和页面结构：先动 app.json 再动页面

第一步，在 project.config.json 里改 projectname；第二步，把 app.json 里的 window 对象看作全局配置，navigationBarTitleText 改成你自己的标题，背景色、字体色一并调整；第三步，pages 数组的第一项决定启动页面，把这个顺序改成你要的首页。

tabBar 是另一个必改项。合集里的 tabBar 配置通常长这样：

"tabBar": { "color": "#999999", "selectedColor": "#1296db", "list": [ { "pagePath": "pages/index/index", "text": "首页", "iconPath": "images/tab-home.png", "selectedIconPath": "images/tab-home-active.png" } ] }

这里要注意三个参数：list 数量最少 2 个、最多 5 个，超过就报错；iconPath 是相对路径，图片格式必须是 PNG 且尺寸建议 81px×81px，用大图会导致 tabBar 图标整体变形；text 文字要简短。旧源码常在这些细节上瞒着，你会看到“首页”两个字被截断。

另外被很多人忽略的是：大多数合集项目没有 sitemap.json 的适配，工具会持续弹一个 sitemap 索引提示。如果你对搜索索引没有要求，直接删掉 sitemap.json 就好。

4.2 用 Promise 封装 wx.request：建立唯一的接口入口

老项目的接口调用是散落的，我今天建立一个统一请求入口utils/request.js：

// utils/request.js const request = (options = {}) => { // 这里填你自己的后端地址，本地开发可以先用测试域名 const baseURL = 'https://your-api.example.com/v1'; return new Promise((resolve, reject) => { wx.request({ url: `${baseURL}${options.url}`, method: options.method || 'GET', data: options.data || {}, timeout: 8000, header: { 'content-type': 'application/json' }, success: (res) => { // 约定后端返回 { code: 0, data: {...}, message: 'ok' } if (res.data && res.data.code === 0) { resolve(res.data.data); } else { // 业务码非0，按异常处理 reject(res.data || res); } }, fail: (err) => { // 网络错误或超时，统一进这里 reject(err); } }); }); }; module.exports = request;

逻辑说明：封装之后，页面里调用request({ url: '/order/list', method: 'GET' })就能拿到data.data字段，不再关心 wx.request 的细节，也不怕回调地狱。参数里timeout: 8000是超时时间，单位是毫秒，超过 8 秒自动走 fail；header里的 content-type 决定了微信端怎么解析请求体；后端协议约定 code 为 0 表示成功，不同项目要按实际情况改写 success 里的判断逻辑。

改造接口时记住，不是所有wx.request都要替换，很多页面是纯静态展示，保留模拟数据也能正常预览。老代码里有大量接口地址直接写死在页面里，搜https://全局替换效率更高。

4.3 登录获取手机号的旧代码改造：从 getUserInfo 到快速验证组件

合集里逢登录必弹 wx.getUserInfo，这套接口现在拿不到真实昵称头像，还会触发开发者工具的高风险提示。新的实现思路是用户点击按钮主动触发授权，结合头像昵称填写能力：

<!-- 页面内的登录按钮 --> <button bindtap="onChooseAvatar">设置头像</button> <input type="nickname" bindchange="onNicknameChange" placeholder="输入昵称" />

// 页面 js 中的处理 onChooseAvatar(e) { const { avatarUrl } = e.detail; this.setData({ avatarUrl }); }, onNicknameChange(e) { const nickname = e.detail.value; this.setData({ nickname }); }

参数说明：e.detail.avatarUrl是用户选择头像后返回的临时文件路径，要把这个路径上传到自己的存储空间再回填，否则换了手机头像会丢；input的 type 设置为nickname是微信专门给昵称输入提供的类型，能唤起微信的昵称填充能力。

登录态方面，老的wx.login链路本身还能用，具体是：wx.login 拿到临时 code，把它发给后端，后端调 code2Session 接口交换 openid 和 session_key。这个链路可以在个人主体下正常跑通。但合集中的“获取手机号”功能要特别注意：现在官方主推的是快速验证组件，需要企业主体小程序认证后才能调用，个人主体 AppID 基本用不了。如果你拿的是个人主体测试号，遇到这类代码直接删掉相关按钮，不给用户看到报错。

4.4 自定义导航栏高度：用胶囊按钮位置计算代替写死像素

很多老源码特别喜欢把顶部状态栏高度写死成 20px，换到全面屏手机上直接顶到刘海。正确的做法是读取胶囊按钮的位置，动态计算导航栏高度：

// 计算自定义导航栏高度的通用公式 const { statusBarHeight } = wx.getWindowInfo(); const menuButton = wx.getMenuButtonBoundingClientRect(); this.setData({ statusBarHeight: statusBarHeight, navBarHeight: (menuButton.top - statusBarHeight) * 2 + menuButton.height });

逻辑说明：wx.getWindowInfo()返回当前窗口信息，statusBarHeight 是状态栏高度；菜单按钮也就是右上角胶囊的 top 和 height 是真实渲染坐标。胶囊按钮的垂直中点和自定义导航栏的中点对齐，所以用“(top - 状态栏高度) × 2 + 按钮高度”推算整条导航栏的高度。这个值在不同机型上是动态的，彻底解决刘海屏适配问题。

样式上同步做两件事：页面容器的 padding-top 设为 navBarHeight，背景色与导航栏颜色一致；不要在布局里硬编码px，微信小程序推荐用rpx作响应式单位。导航栏的坑往往不容易不想，但真机预览一次就暴露。

4.5 抽组件与样式隔离：合并多套源码前先定好规范

当你从160套里看中多个项目的某个功能，一定会走到组件复用这一步。比如从商城类项目抽一个商品卡片，从工具类项目抽一个步进器。建立公共组件目录 components/，组件内部默认不受页面样式影响，这是微信的设计，却也是大家第一次写组件最容易疑惑憋住的点。

需要注意组件的 styleIsolation 设置。在组件的 json 或 js 里声明：

{ "component": true, "styleIsolation": "isolated" }

参数说明：isolated表示组件内部 wxss 与页面互相隔离，页面里写到组件标签身上的选择器不会生效。如果需要外部传入 class 控制组件表现，用 externalClasses 字段声明外部样式名字。过去我在提取组件时总想直接改页面样式去覆盖组件，结果怎么都不生效，后来才发现是 styleIsolation 的默认隔离策略在起作用。

组件抽完，还要注意一点：组件 js 里不能直接调用页面方法，要通过 triggerEvent 抛事件给页面。这是微信组件通信的机制，也是源码改造中最容易踩的边界之一。

5. 避坑排查：这些老代码里最常见的五个炸点与解决方法

合集代码的质量参差不齐，这里集中讲五个我实际踩过的高频问题。每条都按现象-原因-解决写，排查的时候可以先对照现象对号入座。

5.1 导入就报 app.json 找不到：多数是解压层级不对

现象：把“160套源码合集”解压后直接导入微信开发者工具，提示“未找到 app.json”或“获取 app.json 失败”。

原因：不是源码缺文件，而是导入的目录层级错了。合集外层是一个总文件夹，每个子项目可能又压了一层压缩包，或项目代码放在二级目录里。工具把当前目录当成小程序根目录，自然找不到 app.json。

解决：先用find . -name "app.json" -maxdepth 4找出所有 app.json，然后选一个既有 app.js 又有 project.config.json 的目录层级导入。如果项目是 uni-app 构建产物，app.json 在 dist/build/mp-weixin 目录下，要导入那一层。避免用带中文和空格的路径，旧版工具容易因此读不到文件。

5.2 编译报错 wx is not defined 或 Page is not defined：项目结构被误判

现象：编译后控制台直接红屏，报wx is not defined或Page is not defined。

原因：这个错误在合集里几乎都是同一个根因：当前目录不是有效的小程序主包，工具没有按小程序模式解析 js。可能是导入到了 uni-app 源码目录而不是构建后的 mp-weixin 目录，也可能是 project.config.json 被改动后 miniprogramRoot 指向了错误路径。

解决：先确认导入的是小程序根目录，再检查 project.config.json 里 miniprogramRoot 有没有指向正位置。如果项目真的没有配置文件，手动新建 project.config.json，并把 appid 配成touristappid。还有一部分项目用了自定义构建脚本，运行时把生成代码输出到 miniprogram/，这类项目不要直接改源码，要走它自己的构建命令。

5.3 请求 status 200 但业务码 401：后端域名失效与登录态过期

现象：模拟器里网络请求全部返回 200，响应内容却是{"code": 401, "message": "未登录"}，页面数据一片空白。

原因：合集里的后端地址是作者自己的服务器和域名，过一年半载就会过期或被防火墙挡掉。即便请求能到服务器，你的登录凭证也换不来合法 openid，服务端自然拒绝。

解决：开发期直接把登录态写死，在 app.js 的 globalData 里放一个临时 token，请求封装层发现没有登录态时使用它；或者更省事，把页面数据切换成项目自带的模拟 JSON。等真正要联调，再替换成自己的后端并重新走 wx.login 流程。不要试图去破解旧接口，那些接口背后的服务端可能早已存在安全漏洞，不值得再连。

5.4 模拟器正常真机错乱：导航栏高度与 rpx 单位的老问题

现象：模拟器和开发者工具里字体、间距都正常，扫码真机预览后，顶部导航整体上移错位、字号忽大忽小。

原因：模拟器默认窗口接近 iPhone 逻辑分辨率，而真机上状态栏高度和屏幕宽度差异较大。老代码把导航高度写死，且混用了 px 和 rpx，导致全面屏机型上直接崩。

解决：按上一章 4.4 的动态计算方式替换导航栏高度；所有间距和字号统一使用 rpx；padding 和 margin 不要用 px 混搭。最后在开发者工具的机型模拟面板里切换“iPhone SE”和“iPhone 14 Pro”两组看，能提前暴露大部分布局问题。

5.4 云开发项目报 invalid env：合集中的云环境早被作者删了

现象：部分源码使用了 wx.cloud 能力，打开后界面加载失败，Console 提示env invalid或invalid env。

原因：作者在 app.js 里把wx.cloud.init的 env 指定成了自己账号的云环境 ID。合集不会附上作者的云后台，环境早已不存在。

解决：在开发者工具里实名开通自己的云开发环境，然后打开 app.js 把 env 字段改成你自己的环境 ID。同时，云数据库集合名称也要按当前项目文档建好，否则基础数据读不出来。这一部分对新手最花时间，跨过之后能完整理解云开发的链路，值得折腾。

这五个炸点覆盖了导入、编译、请求、布局、云环境五个阶段。如果你用一套源码每次都卡在同一个地方，先回想是不是漏掉了哪一个环境参数的配置。

6. 把160套源码变成组件资产：验证方法与上线前检查

到了这个阶段，你的目标不是“跑起来”，而是把合集变成可重复使用的项目素材。我的做法是每从合集里提取一个项目，都按这套验证方法过一遍：先从 app.json 的页面清单里删掉广告页、过期的活动页，只保留和你业务相关的核心流程；然后对保留页面逐一做真机预览，用少量真机测试去覆盖不同屏幕比例。

上线之前，我固定有三项检查。第一是代码里搜console.log和eval，生产环境不要带调试日志与动态执行；第二是确认全部请求域名已经通过小程序管理后台配置到 request 合法域名列表，并且都是 HTTPS；第三是检查隐私相关接口的授权弹窗文案，头像昵称、位置、手机号这类能力和你的隐私保护指引对得上，否则提审会被驳回。这最后一项，正是合集源码和合格发布版本最明显的差距——旧代码只想着能跑，不考虑隐私合规。

我自己用合集的经验是：只做减法，不做加法。选三五个结构清晰的原生项目，抽出订单流程、商品卡片、表单验证这些通用模块，重组进一个全新工程，而不是把某一套源码直接改名上架。改完之后的工程，命名、目录结构、接口层都按自己的规范来，后期维护成本反而比套用源码更低，这算是这几年被反复教育之后的教训。

希望这些步骤能帮你从“面对160套源码无从下手”走到“每一套都能快速判断值不值得改”。合集的最高价值不是那 160 个成品，而是它们背后每一行可被参考的交互和业务逻辑，这比下载次数重要得多。

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