简介：这份压缩包整合了情侣头像、朋友圈背景、动态壁纸三类微信小程序源码，定位为轻量级个性化内容工具，面向有小程序前端基础、希望快速验证创意并尝试流量主变现的开发者。整体采用纯前端架构，无需自建服务器和数据库，使用微信开发者工具直接调试，绑定合法域名后即可上线，大大降低部署门槛。压缩包共119个文件，类型以png/jpg图像素材、js逻辑与请求封装、json页面配置、wxss样式、wxml页面结构、wxs辅助脚本为主，资源包仅295KB，结构紧凑且目录模块分明，便于二次开发。附带视频教程覆盖开发者工具调试、域名绑定、流量主替换等关键步骤，适合零基础或初级开发者对照上手。目前已有153人学习查看，可作为情侣互动、朋友圈美化、动态壁纸展示等小场景的快速起步样板，也能为个人作品集或商业尝试提供可运行的基础代码。

1. 三个小程序源码包，吃透微信小程序的一套完整素材闭环

这套情侣头像微信小程序源码，连同朋友圈背景、动态壁纸一共三个独立的小程序工程，覆盖了微信小程序开发里最典型的三个场景：图片列表与筛选、Canvas 生成图片、定时器驱动的动效界面。如果你正在做毕业设计、接外包，或者想快速上线一个工具类小程序，这三个源码包能直接拆着用：情侣头像模块解决「选图——配对——保存——分享」，朋友圈背景模块解决「文字/图片合成背景图」，动态壁纸模块解决「多图轮播与手势交互」。而且它们都是原生微信小程序语法，不是 uniapp 转译的，路由、组件、API 调用都保留着原生工程的原始结构，读代码比读文档来得快。适合有基础 JS 语法、想跳过「搭框架」阶段直接看业务实现的开发者。

2. 工程结构与工具配置：先跑起来再改代码

2.1 三个子工程的目录与页面路由

拿到源码包解压后，里面是三个独立的工程文件夹，每个文件夹都能单独用微信开发者工具打开。原生小程序工程的标准结构是 app.js、app.json、app.wxss 三个全局文件打底，pages 目录放页面，utils 目录放公共方法。我拆过的这包源码里，情侣头像工程 pages 下面有 index（首页列表）、detail（头像大图）、pair（配对页）；朋友圈背景工程有 index、editor（编辑文字）、preview（预览导出）；动态壁纸工程有 index、player（播放页）。

// app.json 是入口配置，页面注册顺序也决定加载优先级 { "pages": [ "pages/index/index", "pages/pair/pair", "pages/detail/detail" ], "window": { "navigationBarBackgroundColor": "#FF6B81", "navigationBarTextStyle": "white", "navigationBarTitleText": "情侣头像" } }

第一个页面必须放在 pages 数组首位，这是小程序冷启动的入口。navigationBarTitleText 是可以动态改的，比如从详情页返回时恢复默认标题，这比在 onShow 里用 wx.setNavigationBarTitle 硬编码更灵活。工具栏的颜色值建议跟着视觉稿走，遇到深色背景配白字，浅色背景配黑字，否则真机上状态栏时间看不清。

2.2 导入开发者工具的密钥配置

这一步最容易翻车的是 AppID。源码包里默认填的是测试号，你直接点「导入」会看到登录态异常或者请求接口报错。我一般习惯在 project.config.json 里把 appid 字段改成自己的小程序 AppID，如果只是本地预览，用测试号也能跑，但 wx.saveImageToPhotosAlbum 这类需要用户授权的能力在测试号下行为不完全一致，建议注册一个个人小程序账号，AppID 免费拿。

{ "miniprogramRoot": "./", "projectname": "couple-avatar", "appid": "touristappid", "setting": { "es6": true, "enhance": true, "postcss": true, "minified": true } }

appid 填 touristappid 表示游客模式，适合只想看界面的情况；要测完整能力链必须换真实 AppID。这里 es6 编译、代码压缩、样式补全三个开关保持开启，这三个选项直接决定你写 async/await 和箭头函数时会不会在低版本基础库上白屏。如果发现代码里用了可选链操作符?.，基础库版本最好压到 2.16.0 以上，在 project.config.json 的 libVersion 字段里指定。

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

这三个源码包都用了自定义导航栏，就是 app.json 里 window 配了"navigationStyle": "custom"，好处是沉浸式、可以放自定义按钮，坏处是顶部状态栏高度得自己算。网上很多帖子直接写死 64px，那是 iPhone X 时代的数值，现在底部安全区和顶部刘海都在变，写死必错。

// utils/system-info.js 获取胶囊按钮位置与状态栏高度 const getNavBarInfo = () => { const systemInfo = wx.getSystemInfoSync() const capsule = wx.getMenuButtonBoundingClientRect() const navBarHeight = (capsule.top - systemInfo.statusBarHeight) * 2 + capsule.height return { statusBarHeight: systemInfo.statusBarHeight, navBarHeight, capsule } }

这里的关键是胶囊按钮的几何信息，微信把右上角胶囊的位置暴露给了开发者，用它做基准来反推导航栏高度。公式中的(capsule.top - statusBarHeight) * 2 + capsule.height，含义是：状态栏底部到胶囊顶部的距离，加上胶囊自身高度，再乘以一个对称系数——多数机型胶囊上下留白是对称的，这个算法比任何固定值都稳。动态壁纸工程里我就是用这个返回值给顶部遮罩层设 padding，避免时间显示被刘海遮住。

3. 情侣头像模块：配对、保存、分享的完整链路

3.1 头像数据源与 grid 列表

情侣头像的数据结构是「一组两张」，男方一张、女方一张。源码里把数据放在 utils/data.js 里，每组的对象包含 groupId、maleUrl、femaleUrl、tags。列表页用 grid 两列布局，左男右女。数据量超过 50 组以后，不建议再往 data.js 里塞，因为主包体积会膨胀，我会把图片 URL 换成 CDN 地址、只保留 id 和文件名，这样源文件瘦身效果明显。

// utils/data.js 的数据格式，图片地址指向 /assets/images/avatar/ 目录 const avatarGroups = [ { groupId: 101, male: '/assets/male-101.jpg', female: '/assets/female-101.jpg', tag: '清新' }, { groupId: 102, male: '/assets/male-102.jpg', female: '/assets/female-102.jpg', tag: '日常' } ] module.exports = { avatarGroups }

页面里用 wx:for 渲染时，注意给 wx:key 传 groupId，不要用默认的 index。原因是微信列表渲染的 diff 机制依赖唯一 key，如果你在中间插一组头像，用 index 会导致后面所有行重新渲染，视觉上会闪一下，用 groupId 只增量更新变化的那一行。tag 字段可以留给筛选 tab 用，情侣头像通常按「ins 风」「可爱」「古风」分类，加一个简单的 tag 过滤，代码量不多但用户体验差别很大。

3.2 随机配对与沐光逻辑

配对页的核心玩法是「掷骰子」：用户点击按钮，系统从全部头像组里随机抽一组，展示男女两张图。这里有一个容易忽略的随机重复问题，如果完全随机，连续抽到同一组的概率并不低，体验很不好。源码里用了「去重随机」策略，记录上一次抽取的下标，下一次从剩余集合里选。

// pages/pair/pair.js 随机配对逻辑 let lastIndex = -1 Page({ data: { current: null, index: 0 }, shuffle() { const total = avatarGroups.length let randomIndex = Math.floor(Math.random() * total) // 避免连续抽到同一组，这个循环最多退让五次 while (randomIndex === lastIndex) { randomIndex = Math.floor(Math.random() * total) } lastIndex = randomIndex this.setData({ current: avatarGroups[randomIndex] }) } })

Math.floor(Math.random() * total) 得到 0 到 total-1 的整数。while 循环在极端情况下可能死循环——如果 total 等于 1，randomIndex 永远等于 lastIndex。实际数据量不会这么极端，但如果改成"同组不出现"的加强版洗牌算法，需要引入 Fisher-Yates 洗牌，把整个数组打乱后按顺序取，那样更专业。setData 的 current 是对象类型，微信的 diff 算法会逐字段对比，这里一次只更新一个对象，性能没有压力。

3.3 保存到相册的授权链

用户选中心仪头像后，点「保存」会把图片写到系统相册。这个功能的坑在授权链路：wx.saveImageToPhotosAlbum 第一次调用会弹系统授权框，用户拒绝后再次调用会直接走 fail 回调，不会再弹框。源码里封装 authorizePhoto 方法处理这个链路，三段式：查设置—发请求—引导去设置。

// utils/authorize.js 保存图片的授权链 const authorizeSave = () => { return new Promise((resolve, reject) => { wx.getSetting({ success: (res) => { const hasAuth = res.authSetting['scope.writePhotosAlbum'] if (hasAuth === undefined) { // 第一次弹窗询问 wx.authorize({ scope: 'scope.writePhotosAlbum', success: resolve, fail: reject }) } else if (hasAuth === true) { resolve() } else { // 引导打开设置页，这里不能直接弹窗 wx.showModal({ title: '需要相册权限', content: '请在设置中开启相册权限', success: (modalRes) => { if (modalRes.confirm) wx.openSetting() } }) } } }) }) }

判断 hasAuth === undefined 是关键分支，表示用户从未被询问过。这里 reject 后我一般会在页面里 catch，然后提示"保存失败，请重试"。值得留意的是 wx.openSetting 只能由用户点击触发，不能在授权失败后自动调用，否则反馈「openSetting:fail can only be invoked by user TAP gesture」。保存之前还要过一层下载：网络图片不能直接保存，先 wx.downloadFile 拿到本地临时路径，再 saveImageToPhotosAlbum。

3.4 分享给好友的 onShareAppMessage 配置

情侣头像的传播场景高度依赖社交分享。源码里的分享逻辑把当前头像组 id 通过 query 传给接收方，接收方打开时读参数并定位到同一组。这个路径上，我最常遇到分享卡片图片不显示的问题——分享图路径必须是本地文件路径或者 CDN 绝对地址，不能是临时文件路径，临时文件在分享时会失效。

// index 页的分享配置 onShareAppMessage() { const current = this.data.currentGroup return { title: '来挑情侣头像', path: `/pages/index/index?groupId=${current.groupId}`, imageUrl: current.maleUrl // 用本地路径或 CDN 地址 } }

path 里 query 参数在接收方 onLoad(options) 中读取，注意参数类型是字符串，groupId 需要 parseInt 再用于数组查找。如果 imageUrl 用页面内的大图，分享卡片会压缩得很糊，更好的做法是在 assets 里放一张 500x400 的分享专用图。这个模块里我还建议加一个 onShareTimeline（分享到朋友圈），朋友圈分享卡片不受 2 张图限制，壁纸类内容打开率会高不少。

4. 朋友圈背景与动态壁纸：Canvas 绘制与图片预加载

4.1 Canvas 2D 绘制文字背景图

朋友圈背景模块的典型用法是「用户输入一句文案，程序生成一张带背景图和文字的图片，用户保存后发朋友圈」。这个功能底层是 Canvas 绘制，源码用的是 Canvas 2D 接口（type="2d"），不是老版的 wx.createCanvasContext。两者最直观的差别在新接口需要 wx.createSelectorQuery 获取节点，且坐标系不受滚动影响。

<!-- editor 页面里的 canvas 声明，注意 type="2d" 不能丢 --> <canvas type="2d" id="bgCanvas" style="width: 375px; height: 667px;"></canvas>

// editor.js 里初始化 canvas const query = wx.createSelectorQuery() query.select('#bgCanvas').fields({ node: true, size: true }).exec((res) => { const canvas = res[0].node const ctx = canvas.getContext('2d') const dpr = wx.getSystemInfoSync().pixelRatio canvas.width = res[0].width * dpr canvas.height = res[0].height * dpr ctx.scale(dpr, dpr) this.canvas = canvas this.ctx = ctx })

必须手动处理 dpr，否则 canvas 画出来的图在真机上会模糊。宽度取 375 是 iPhone 的逻辑像素，实际 canvas 物理像素是 375 * pixelRatio。绘制文字时 ctx.font 需要完整声明字号和字体族，比如ctx.font = 'bold 28px sans-serif'，不写 bold 就默认普通粗细。文字换行逻辑源码里是用 Array.reduce 按 measureText 宽度截断的，注意中英文混合时 measureText 对半角全角判断不一致，一个稳妥的做法是统一把字符串转成数组、逐字累加宽度判断是否该换行。

4.2 动态壁纸的帧切换与定时器生命周期

动态壁纸模块的玩法是：动态壁纸本质上是多张静态图按时间间隔轮播，配合轻微缩放动画营造「动感」。源码里 player 页面加载一组图片 URL，用 setInterval 切背景图，再配合 CSS transition 做透明度渐入。这里的核心问题不是动画效果，而是定时器的生命周期管理——小程序页面切到后台后定时器默认还在跑，会持续消耗资源。

// player.js 动态壁纸轮播核心 startPlay() { const total = this.data.wallpaperList.length if (this.timer) clearInterval(this.timer) this.timer = setInterval(() => { const next = (this.data.currentIndex + 1) % total this.setData({ currentIndex: next }) }, 3000) }, onHide() { // 页面不可见时必须清掉定时器，否则 Android 真机后台耗电明显 if (this.timer) { clearInterval(this.timer) this.timer = null } }, onShow() { if (this.data.isPlaying) this.startPlay() }

(currentIndex + 1) % total是经典的环形取模，到末尾后回绕到 0。onHide 里清理 timer、onShow 里重启，这对组合是原生小程序的标配，但动态壁纸场景还要处理一个情况：onShow 时如果用户切后台超过 30 秒，回到页面时图片可能还在加载，需要先展示 loading 遮罩，等当前帧图片 onload 后再移除。源码里在 image 组件上绑定了 bindload 事件，加载完成才设置 opacity 为 1，这样避免闪白。

4.3 图片预加载与内存释放

动态壁纸每切换一帧，前一张图如果还占着 Image 对象，内存会持续上涨。尤其是 GIF 动图格式，小程序 image 组件不支持 GIF 动画播放，只会显示第一帧，但内存是按整份 GIF 原始数据计算的。源码里的设计是预加载所有 URL，但控制并发数，我一般拆成「当前帧 + 下一帧」双缓冲，不要一次性把所有图片都 new Image 塞内存。

// utils/preload.js 双缓冲预加载 const preloadImage = (url) => { return new Promise((resolve, reject) => { const img = wx.createImage() img.onload = () => { resolve(img) } img.onerror = () => { reject(new Error('preload failed: ' + url)) } img.src = url }) }

调用侧只预加载 index+1 和 index-1 两张，其余懒加载。这里有一个取舍：预加载能减少卡顿，但占用内存；懒加载省内存但切换时白屏。双缓冲是平衡点。图片地址如果是 CDN，还可以在域名后面拼接?imageMogr2/format/webp之类的压缩参数，前提是图床支持，不支持就保持原样，别乱改参数。

5. 避坑手册：五条血泪记录

5.1 saveImageToPhotosAlbum 一直在授权，但相册里没有图

现象：用户点击保存，明明弹了系统授权框，也点了允许，但相册里找不到新图片。

原因：保存时用的是网络图片临时路径，而 downloadFile 成功后的临时路径只在本次小程序运行期有效，且真机上临时目录和相册是隔离的；另一个原因是部分 Android 机型上 saveImageToPhotosAlbum 保存的图片进的是「微信」文件夹而不是系统相册的「相机」目录，用户去了「相机」结果没看到。

解决：保存前先调用 wx.getFileSystemManager().saveFile 把临时文件转存为本地持久文件，再保存到相册；同时给用户一个「图片保存在系统相册的 Pictures/WeiXin 目录」的 toast 提示。这样用户在微信文件夹里也能找到。

5.2 Canvas 导出图片是黑底

现象：小程序 canvas 生成的图片在 iOS 上正常，Android 上导出后背景全是黑色，文字看不见。

原因：canvas 节点初始宽度为 0，draw 的时候把背景图绘制到了 0 宽度的画布外，导出的缓存图就是一张空画布。也可能是 canvas 离屏渲染时背景图未加载完成就直接调 wx.canvasToTempFilePath。

解决：确保 canvas 的 CSS 样式显式设置宽高，且在 canvasToTempFilePath 调用前用 wx.createSelectorQuery 检查 canvas 尺寸非零。绘制背景图时在 Image.onload 回调里再触发后续绘制，不要用固定 setTimeout。

5.3 动态壁纸切后台再回来，定时器「不走」了

现象：从 player 页切到微信聊天，再返回小程序，壁纸停在离开时的那一帧，不再轮播。

原因：微信小程序在页面不可见时可能冻结 JsCore，setInterval 的回调不会再触发，等重新可见时，旧 timer 已经失效但 handle 变量没有被清空，导致 startPlay 里清空操作没执行。

解决：onShow 里先无条件 clearInterval，再判断 isPlaying 决定是否重启。用 setInterval 前给 timer 赋值 null 并定时器编号判断，或者直接用 setTimeout 递归；如果兼容基础库在 2.18 以上，还可以用timersAPI 的 createRepeatingTimer。

5.4 网络图片多时，列表滚动掉帧卡顿

现象：头像列表 100 组图片，全部用 image 组件加载网络图，滑动列表时明显掉帧，iOS 卡，Android 直接白屏闪退。

原因：一次性创建 200 个 image 实例，每个都请求网络资源，GPU 内存爆了。图片没有设宽高，布局引擎反复计算滚动高度。

解决：列表用 wx:if + 懒加载，或者改用 image 组件的 lazy-load 属性，它原生支持滚动到可视区附近才加载资源。同时给 image 的 width/height 全部写死同比例尺寸，图片加载前后布局不跳动。

5.5 微信小程序真机预览白屏，开发者工具正常

现象：开发者工具调试一切正常，扫码真机版直接白屏，连首页都不渲染。

原因：控制台报错一般是appid 不匹配或者 ES6 语法在低版本基础库不支持。个人小程序的 appid 该工程配置的 appid 若为空或为测试号，真机上部分 API 会被禁用导致页面挂掉。

解决：project.config.json 的 appid 换成自己账号的；在详情面板把「ES6 转 ES5」打开；如果用了 Canvas 2D 新接口，把本地基础库版本调到与真机一致，调试基础库 3.x 与 2.x 的 canvas 行为会有差异。出现白屏时别急着猜，先连 vConsole 看 console 报错。

6. 三合一导航调度：把三个模块收进一个入口

三个源码包各自是独立工程，但实际使用时你要么切换工具打开不同项目，要么做一个「合集小程序」。我更推荐做一个导航容器页，把三个模块用页面路径统一调度，这比复制三个完整工程到同一项目里更省事——微信小程序的主包 2MB 限制摆在那，硬塞三个完整工程很容易超限。

// pages/home/home.js 一个入口调度三个模块 const modules = [ { name: '情侣头像', path: '/pages/couple/index/index' }, { name: '朋友圈背景', path: '/pages/bg/editor/editor' }, { name: '动态壁纸', path: '/pages/live/player/player' } ] Page({ data: { modules }, go(e) { const { path } = e.currentTarget.dataset wx.navigateTo({ url: path }) } })

dataset 里带出的 path 是字符串，navigateTo 的 url 可以是相对路径也可以是以 / 开头的绝对路径。这里我将每个子模块当成独立分包，配置在 app.json 的 subpackages 字段里，每个分包独立打包，不影响主包体积。路由带上初始参数比如?from=home，方便模块内统计来源。

这套「入口集中、分包隔离」的思路在后续迭代中收益很大：你要替换壁纸素材，不需要动其他模块；个别页面出错时可以单独降级包。我最初就是硬塞三个工程到主包，结果 source size 直接飙到 2612KB 撑爆 2MB 限制，后来才改成 subpackages 方案，首包压缩到 700 多 KB。从那以后，我每加一个新功能模块都强制走一遍分包流程：先看主包体积，再决定是 add 到已有分包还是新建页面。

希望帮你绕开这些坑，把素材真正变成能跑、能发布的小程序。

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