企业官网建设流程全解析

简介：一套面向小程序入门者与个人开发者的微信小程序源码合集，覆盖情侣头像、朋友圈背景、动态壁纸三类个性化展示场景。项目采用纯前端实现，无需服务器和数据库，配合微信开发者工具调试并绑定合法域名即可运行，流量主功能也直接在前端替换，附带视频教程可快速上手。压缩包共119个文件，以js逻辑、json配置、wxml页面结构、wxss样式为主，png/jpg素材用于头像与背景图，wxs辅助数据处理，整体仅295KB，轻量易读。已有153人学习下载。资源适合希望在社交类小程序方向快速出作品、理解前端模板与个性化内容展示逻辑的开发者；从文件结构中可清楚看到动态壁纸详情、头像模板、朋友圈背景等多个页面模块，便于二次开发，对熟悉组件化开发与自定义数据处理也很有帮助。

1. 情侣头像、朋友圈背景、动态壁纸三合一小程序源码：先搞清楚这套代码到底值什么

做素材类小程序的人手里大概率都存过这样一套源码：栏目拆成三个入口，左边是情侣头像，中间是朋友圈背景图，右边是动态壁纸，后台共用一套数据表、一套上传逻辑、一套分类筛选。用户进来翻分类、搜关键词、看图、保存到相册，你在列表底部挂横幅广告、在看高清大图前插一个激励视频，收益来自微信流量主。对于想低成本验证工具类小程序能不能跑通变现的开发者，这是性价比很高的起点。

但收到源码之后别急着部署，先想一个问题：这套代码里最值钱的不是那几十个 WXML 页面，而是内容管理逻辑和授权适配。图片有人维护、分类有人更新、保存链路不翻车，它才是能持续产出收益的流量入口；如果只是把静态页面搭起来，那它和你本地随便写个网页没有区别。下面的内容我会按「初始化工程 → 图片与分类配置 → 动态壁纸的视频边界 → 保存授权与审核避坑 → 接入流量主」的路径，把一套可运行的方案拆开讲，包含可以直接复制改用的代码和你会遇到的真实坑。

2. 从压缩包到能跑：初始化小程序工程与三个栏目的数据流

2.1 拿到源码压缩包后先改这三处：appid、project.config.json 与页面路由

很多人在这一步翻车。把代码拖进微信开发者工具，点了预览发现白屏，第一反应是改业务代码，其实问题通常出在三件套上：AppID 没换成自己的、project.config.json 里的 appid 字段还是原作者的、app.json 里的页面路径和实际目录对不上。

先说 AppID。如果你用的是测试号，request 域名、流量主、云开发全都不可用，只能看到静态页面；建议直接用自己的小程序 AppID。打开 project.config.json，核心字段长这样：

{ "appid": "wx你的小程序AppID", "compileType": "miniprogram", "libVersion": "3.7.12", "setting": { "urlCheck": true, "es6": true, "minified": true } }

urlCheck 对应开发工具里「不校验合法域名」的开关。开发阶段很多人的习惯是关掉它，本地跑通就行，但上线前必须改回 true，否则正式版一到真机上，图片和接口全部请求失败。libVersion 建议保持和你开发者工具一致，或者往上调一档，不要为了兼容老手机去锁定过低的库版本，后面用 Canvas 和视频组件时容易缺 API。

再打开 app.json，这套源码的典型路由结构是这样：

{ "pages": [ "pages/index/index", "pages/category/category", "pages/detail/detail", "pages/wallpaper/wallpaper", "pages/setting/setting" ], "tabBar": { "list": [ { "pagePath": "pages/index/index", "text": "情侣头像" }, { "pagePath": "pages/category/category", "text": "背景图" }, { "pagePath": "pages/wallpaper/wallpaper", "text": "动态壁纸" } ] }, "window": { "navigationBarTitleText": "素材小站" } }

这里有一个很多人忽略的细节：tabBar 的 pagePath 必须出现在 pages 数组里，而且 tabBar 页面不能带参数跳转。另一种常见做法是只有一个首页 tab，情侣头像、朋友圈背景、动态壁纸全部作为一级分类页从首页进去，这样少两个 tab 渲染，对低端手机更友好。我一般倾向于这种「一 tab + 分类页」的结构，因为素材类小程序用户目的性很强，进来之后点分类比左滑右滑更快。

2.2 数据从哪来：本地 JSON、云开发数据库还是 HTTP 接口

这套标题里的三类源码，本质上都是「图片列表 + 详情预览 + 保存」的展示型应用，不涉及复杂状态管理。所以数据层的选型决定你后面维护内容时的痛苦程度。常见的三种方式：

个人接单或自用，我推荐云开发数据库。原因很直接：这套源码的运营重点在「换内容」，云开发控制台能直接改记录，不用每次为一张新图发一个版本。而且云开发自带存储，图片上传后返回 fileID，前端直接用 渲染，天然避开了域名白名单的问题。

集合结构建议这样设计：

// 集合名：materials { _id: "auto", category: "avatar", // avatar 情侣头像 | bg 朋友圈背景 | dynamic 动态壁纸 title: "落日余晖情侣头像", type: "static", // static 静态图 | dynamic 动态视频壁纸 ratio: "1:1", // 图片比例，用于前端裁剪与占位 imageUrl: "", // 静态图地址或视频封面 videoUrl: "", // 动态壁纸的视频地址 width: 1080, height: 1080, tags: ["落日", "情侣", "暖色"], likes: 0, status: 1 }

前端读取时，用一个查询搞定三个栏目：

const db = wx.cloud.database() const COLLECTION = 'materials' Page({ data: { list: [], currentCategory: 'avatar', page: 0, pageSize: 20, finished: false }, async loadList(reset = false) { if (this.data.finished && !reset) return const page = reset ? 0 : this.data.page const db = wx.cloud.database() const _ = db.command const res = await db.collection(COLLECTION) .where({ category: this.data.currentCategory, status: 1 }) .orderBy('likes', 'desc') .skip(page * this.data.pageSize) .limit(this.data.pageSize) .get() const list = reset ? res.data : this.data.list.concat(res.data) this.setData({ list: list, page: page + 1, finished: res.data.length < this.data.pageSize }) }, onReachBottom() { this.loadList(false) } })

这段代码里有两个参数需要你特别注意。pageSize 建议固定在 20 左右，素材类小程序的图片单张可能到几百 KB，一次渲染太多会让低端机内存暴涨。orderBy('likes', 'desc') 是内容运营的抓手，把点赞多的排前面能明显提升保存转化率；但注意 likes 字段需要你在后台定期维护，或者后续做点击埋点自动累加。

2.3 分类切换与顶栏适配：把三个栏目做成一套渲染逻辑

三个栏目如果各写一套页面，后面每改一次样式要动三个文件，纯属自找麻烦。正确做法是首页只留一个列表容器，分类数据通过点击事件切换。WXML 关键部分：

<view class="category-tabs"> <view wx:for="{{categories}}" wx:key="key" class="tab-item {{currentCategory === item.key ? 'active' : ''}}" bindtap="onSwitchCategory" >const { statusBarHeight, systemInfo } = wx.getSystemInfoSync() const navBarHeight = 44 // 标准导航栏高度 this.setData({ statusBarHeight: statusBarHeight, navBarHeight: navBarHeight })

然后把外层容器 padding-top 设为 statusBarHeight + navBarHeight。这套源码如果要过审核，自定义导航还牵扯到后续的分享按钮和返回按钮布局，建议在接手第一天就统一封装成公共组件，不要每个页面各算一遍。

3. 图片内容与分类配置：把上千张情侣头像和朋友圈背景图管理起来

3.1 图片存哪里：COS、OSS 与云开发存储的选型逻辑

内容型小程序的命脉是图片加载速度。同一个页面，图片来自阿里云 OSS 和来自免费图床，用户体验差一个量级。源码本身不会给你绑定具体的存储商，但你要在填图之前先把存储位置定下来。

云开发存储的做法最省事：开发者工具里可以直接上传到云存储，生成 fileID，前端 image 的 src 直接填 fileID 就能显示，不需要配域名。缺点是免费空间有限，图片上到几千张之后要付费扩容，而且没有真正的 CDN 加速能力，全国访问速度不如专业对象存储。

如果你判断这套内容能长期做，COS 或 OSS 是更稳妥的选择。以腾讯云 COS 为例，它提供 CDN 加速边缘节点，图片在朋友圈和微信聊天里打开速度更稳，还能在控制台直接刷新缓存。但代价是你要有一个备案域名，COS 的文件 URL 才能正常让小程序请求。对比下来，我的建议很简单：验证阶段用云开发存储，图库稳定后再迁到 COS，前期不要把时间花在对象存储配置上。

3.2 批量上传脚本：一次将几百张图片推上云端

素材类小程序上线第一天就得有几百张图才撑得起门面，一张张在控制台传不现实。常见做法是写一个本地 Node 脚本连 COS 或云存储批量上传。下面是连 COS 的脚本骨架：

// upload.js 常见做法示例：批量上传 images 目录下的文件到 COS 桶 const COS = require('cos-nodejs-sdk-v5') const fs = require('fs') const path = require('path') const cos = new COS({ SecretId: process.env.COS_SECRET_ID, SecretKey: process.env.COS_SECRET_KEY }) const bucket = 'xxx-1250000000' const region = 'ap-guangzhou' const localDir = path.resolve(__dirname, './images') function walk(dir) { const results = [] for (const file of fs.readdirSync(dir)) { const fullPath = path.join(dir, file) if (fs.statSync(fullPath).isDirectory()) { results.push(...walk(fullPath)) } else { results.push(fullPath) } } return results } async function uploadAll() { const files = walk(localDir) for (const file of files) { const key = `materials/${Date.now()}_${path.basename(file)}` const res = await cos.uploadFile({ Bucket: bucket, Region: region, Key: key, FilePath: file }) console.log(res.Location) } } uploadAll()

SecretId 和 SecretKey 建议通过环境变量注入，不要硬编码进源码库，尤其是这套源码以后可能要交给客户或协作者维护。脚本跑完后会打印每个文件的 URL，你把 URL 和对应的分类、标题逐个填进数据库。批量填充数据库时，可以再写一个同步脚本，用云开发的数据库 API 批量 insert，注意云开发单次 insert 最多 1000 条，超过就分批。

3.3 分类字段与展示规则：三个栏目的差异全藏在字段里

这套源码里的「情侣头像」「朋友圈背景」「动态壁纸」三个入口，很多人误以为需要三套页面，其实用 category 字段区分就够了。情侣头像通常是一对两张，前端要处理双图并列展示；朋友圈背景图需要按手机屏幕比例给预览蒙层；动态壁纸要走 video 组件。这些差异通过字段驱动比通过页面分支更干净。

推荐给每个栏目增加 renderType 字段：single 单图、couple 情侣双图、video 动态视频。列表页根据 renderType 渲染不同卡片布局，详情页也复用同一套逻辑：

// 详情页根据类型切换渲染 Page({ data: { item: null, renderType: 'single' }, onLoad(options) { const id = options.id const db = wx.cloud.database() db.collection('materials').doc(id).get().then(res => { this.setData({ item: res.data, renderType: res.data.renderType || 'single' }) }) } })

其中情侣头像是这套小程序去掉水印小程序的边界差异点：去水印类工具需要解析外部链接，而这套源码只做站内素材展示，所以操作链路短很多，审核风险也低。运营时你要保证同一个主题的两张图成对出现，否则用户点进详情发现另一边是风景图，体验瞬间崩掉。

3.4 朋友圈背景图的尺寸适配与九宫格裁剪

朋友圈背景图与头像不同，真实使用场景里用户是竖屏刷朋友圈，图片展示比例接近 9:16，所以列表卡片最好按宽高比裁剪。image 组件的 mode="aspectFill" 是首选，它会等比缩放并居中裁剪，既不变形也不会出现白边。副作用是超出容器的部分会被裁掉，这就要求你上传原图时构图主体居中。

如果要做九宫格朋友圈背景，需要用 Canvas 把一张大图裁成九张。实现逻辑不复杂，但有一个参数必须算准：九宫格的单位尺寸。常见算法是 width / 3 作为单格边长，竖向三行、横向三列：

// 用 Canvas 2D 裁剪九宫格 const ctx = wx.createCanvasContext('shareCanvas') const cellSize = 300 // 每格边长，按需调整 const positions = [] for (let row = 0; row < 3; row++) { for (let col = 0; col < 3; col++) { positions.push({ sx: col * 450, // 原图裁剪起点 x sy: row * 450, // 原图裁剪起点 y sw: 450, sh: 450, dx: 0, dy: 0, dw: cellSize, dh: cellSize }) } } // 每个位置执行 ctx.drawImage 后再导出成图片

这里的 450 是原图上每一格的像素尺寸，实际要按原图真实大小换算，不要把 450 写死。很多第一次做的人在这里踩坑，导出的九张图之间有黑边、内容错位，多半是原图没有精确按正方形截取。建议上传端先校验原图宽高比接近 1:1，不满足就直接拒绝，别依赖 Canvas 拉伸。

4. 动态壁纸的实现边界：视频组件、封面策略与包体积控制

4.1 动态壁纸不是图片：video 组件与 src、poster 的配合

标题里的动态壁纸，本质上是一段视频或几张连续帧动画。为了流畅度和体积考虑，绝大多数源码用 video 组件承载视频源。动态壁纸的典型交互是：列表页看到封面图，点击进入预览页播放视频，播放过程中循环，用户觉得合适就保存到相册或者设置为壁纸。

video 组件在 WXML 里的最小配置长这样：

<video src="{{item.videoUrl}}" poster="{{item.poster}}" controls="{{true}}" autoplay="{{autoPlay}}" loop="{{true}}" muted="{{false}}" preload="metadata" show-center-play-btn="{{false}}" bindplay="onPlay" binderror="onVideoError" style="width: 100%; height: {{videoHeight}}px;" ></video>

参数里值得展开讲的是 preload 和 show-center-play-btn。preload 设置为 metadata，只加载视频元数据，不预加载全部帧，列表页不会因为多个视频并发请求而卡死。show-center-play-btn 为 false 时去掉视频中间的大播放按钮，让自定义封面海报更干净，点击事件自己接管。

动态壁纸视频不宜自带声音。用户设置壁纸后通常会长时间盯着锁屏界面，如果视频在播放中拖泥带水地带人声，审核会被投诉。因此线上运营建议把音频轨直接去掉，或者代码里强制 muted 为 true。video 组件的 muted 参数优先于用户手动开声音，这一点是很多源码没有处理干净的。

4.2 列表页防翻车：禁掉 autoplay、做预加载与封面兜底

动态壁纸列表页最容易出现的现场是：滑动频繁时视频组件黑屏、播放卡顿、甚至整个页面崩溃。原因大多是列表里每个视频都设置了 autoplay，用户一滑屏幕，十几个视频同时解码，低端机直接吃不消。

我处理这类页面时习惯做一个「单例播放」控制：当前只有一个视频实例处于播放状态，其他全部停掉。实现思路是监听 bindplay，当新的视频开始播放时，把上一个播放中实例的 context 调 stop 掉。

// 列表页单例播放控制 Page({ data: { activeVideoId: null }, onVideoPlay(e) { const videoId = e.currentTarget.dataset.id if (this.data.activeVideoId && this.data.activeVideoId !== videoId) { const ctx = wx.createVideoContext(this.data.activeVideoId) ctx.stop() } this.setData({ activeVideoId: videoId }) } })

同时视频封面 poster 必须有值。poster 是视频未播放时的占位图，若为空，列表页在滑动时会出现一大片黑块，体验断崖式下跌。封面图的最佳实践是取视频第一帧，压成 JPG 存到图床，大小控制在 100 KB 以内，这样列表页滑动时只加载图片，真正点击后才下载视频流。

另一个翻车点是 iOS 上 video 组件的层级问题。iOS 小程序默认原生组件同层渲染，很多老版本微信里 video 会覆盖掉浮层和自定义导航，表现为「视频盖住了返回按钮」。常规解法是把视频页面独立成单页，不要和列表页复用同一套 UI，或者用 cover-view 覆盖在 video 上层。这套源码如果含相关页面，你要重点检查发布按钮、分享按钮是否被遮挡。

4.3 包体积与远程资源：为什么 mp4 不能打进包里

小程序的代码包有 2 MB 主包限制。有些人为了「离线可用」，把几段壁纸视频直接塞进工程目录，gzip 后仍然直接爆掉。尤其是用 uniapp 开发时，编译后资源文件处理不当，控制台会直接报 source size 2612kb exceed max limit 2mb 类似错误。这不是某一家工具的问题，是平台对主包体积的硬约束。

视频和图片都必须放远程。代码仓库里只保留节流后的封面图，或者干脆封面也走远程。如果图片已经很多，优先考虑分包加载：

{ "subpackages": [ { "root": "pages/wallpaper", "pages": ["index", "detail"] }, { "root": "pages/category", "pages": ["index"] } ], "preloadRule": { "pages/index/index": { "network": "all", "packages": ["pages/wallpaper"] } } }

分包配置里 preloadRule 常被忽略。它的作用是进入首页时后台预下载动态壁纸分包，等用户真正点进去时无需等待加载。network 建议设成 all，因为 WiFi 和蜂窝网络都要覆盖。

4.4 动态壁纸视频参数：码率、封装格式与分辨率建议

动态壁纸视频不是画质越高越好。1080p、高码率的视频在手机上解码压力大，还要耗费大量流量。素材源如果来自用户上传，你要在服务端做转码，统一输出 H.264 编码、MP4 封装、码率控制在 2-4 Mbps 的视频。分辨率按用户的手机来，主流做法是输出 1080x1920 竖屏和 1920x1080 横屏两个规格，窄边不小于 720。

编码参数我一般这样约定：H.264 High Profile，关键帧间隔 2 秒，帧率 24 或 30。帧率过高文件体积和 CPU 占用都上去了，但人眼在锁屏场景下感知不强。后端转码可以用 FFmpeg 一行命令批量处理：

ffmpeg -i input.mp4 -c:v libx264 -profile:v high -crf 28 -preset slow -r 30 -c:a aac -b:a 64k output.mp4

-crf 是画质控制参数，数值越大文件越小、画质越差，26 到 30 之间在手机上几乎看不出差别。如果视频没有音频需求，直接去掉 -c:a 和 -b:a，体积还能小一圈。这里要多说一句：动态壁纸的封面和视频必须能对上，有些源码视频链接是第三方平台的外链，一旦对方更新了防盗链规则，你的壁纸页就只剩封面图，所以线上运营时尽量把视频迁到自己的 COS 或云存储上。

5. 源码落地的常见问题与排障：保存授权、域名白名单与审核

5.1 用户点击保存，相册里看不到图：授权链路没走通

现象：真机上用户点了「保存图片」，弹窗后相册里什么都没有，或者提示保存失败。

原因：保存图片到相册必须申请 scope.writePhotosAlbum 权限，用户第一次拒绝后，后续调用会直接被拒。很多源码里只是调了 wx.saveImageToPhotosAlbum，却没有处理权限被拒之后的情况。

解决：在保存逻辑里前置判断授权状态，被拒后引导用户到设置页重新授权。

// 安全保存图片的标准流程 function saveToAlbum(filePath) { wx.getSetting({ success(res) { if (res.authSetting['scope.writePhotosAlbum']) { wx.saveImageToPhotosAlbum({ filePath: filePath, fail: () => wx.showToast({ title: '保存失败', icon: 'none' }) }) } else if (res.authSetting['scope.writePhotosAlbum'] === undefined) { wx.authorize({ scope: 'scope.writePhotosAlbum', success() { wx.saveImageToPhotosAlbum({ filePath: filePath }) }, fail() { wx.showModal({ title: '需要相册权限', content: '请在设置中打开保存到相册', success(modalRes) { if (modalRes.confirm) wx.openSetting() } }) } }) } else { wx.showModal({ title: '相册权限被拒', content: '请在设置中手动开启保存到相册权限', success(modalRes) { if (modalRes.confirm) wx.openSetting() } }) } } }) }

另一个隐藏细节：有些手机上 wx.saveImageToPhotosAlbum 对图片路径有要求，必须是本地临时路径或持久路径，不能是网络 URL。所以保存前一定要走 wx.downloadFile 把文件拉下来，拿到临时文件路径再保存。后面第 5.5 条会单独展开。

5.2 上线后图片全部裂开：合法域名没有配置

现象：开发工具里图片显示正常，预览真机也正常，但提审后体验版图片全挂。

原因：微信小程序对网络请求做域名白名单校验。开发工具勾选了「不校验合法域名」所以正常，正式版会强制校验，你的图片域名没配到 request/downloadFile 合法域名里。

解决：登录微信公众平台，在「开发管理 -> 开发设置 -> 服务器域名」里配置 downloadFile 合法域名。图片属于 downloadFile 域，不是 request 域。如果图片走 CDN，要把 CDN 域名加进去，而且必须是 HTTPS，证书不能过期。

顺手多说一个容易被误伤的配置：如果你用了云开发存储，那把云开发的 fileID 直接交给 image 组件显示时不需要配域名；但如果你在代码里对 fileID 调用了 wx.cloud.getTempFileURL 再传给 image，那临时链接的域同样是微信官方的，不受白名单限制。这里不用过度担心，担心的是很多人把图床地址和 API 接口地址混在一起配错了位置。

5.3 动态壁纸黑屏转圈：视频源格式与 poster 问题

现象：列表页封面显示正常，点进详情页视频区一直转圈或黑屏。

原因一：视频源是 HLS 流，而你的前后端没有做 m3u8 分片；部分微信版本对 HLS 支持不稳定，尤其在弱网环境下。原因二：poster 封面尺寸过大，在弱网时封面一直加载不出来，视频区域一片黑。原因三：videoUrl 是国际域名或非备案域名，被平台拦了。

解决：统一转码为 MP4 封装、H.264 编码，这是最保守的兼容方案。poster 压缩到 100 KB 以内。如果确认视频链接在浏览器里能开，在小程序里打不开，优先检查域名是否有备案，以及是不是被判定为「诱导下载」的内容。

排障时可以用抓包工具看视频请求的返回状态，微信开发者工具的 Network 面板是最直接的，真机环境可以用抓包工具查看。如果你熟悉 Charles，可以抓小程序请求来区分是 403、404 还是超时，403 多半是防盗链，404 是链接过期，超时则要换 CDN。这一套排查逻辑在素材类小程序上很通用。

5.4 提审被拒：隐私声明、手机号登录与敏感内容

现象：提交审核后被告知「涉及用户隐私但未声明」或「存在功能与描述不符」。

原因：很多源码默认带了手机号一键登录功能，但只是弹了个授权框，后续根本没有用到手机号。既然用不到，就不要碰「微信小程序登录获取手机号」这个能力，它触发隐私采集声明，审核会重点检查你是否真有必要收集用户手机号。对素材展示类工具来说，游客模式完全够用，增加了登录门槛反而损失转化。

解决：不需要手机号登录就删掉相关组件和 API 调用。如果确需登录，则在「小程序管理后台 -> 设置 -> 服务内容声明 -> 用户隐私保护指引」里声明收集手机号的目的。

内容审核是另一个高频拒审点。情侣头像、壁纸类素材，一旦有用户上传功能，就会被要求加强内容审核机制。合规做法是接微信官方的内容安全检测接口，上传前调用 security.msgSecCheck 和 imgSecCheck，否则审核人员测试一次就知道你没有兜底。源码里如果只有前端而缺这个调用，上架前补上。

5.5 保存临时路径的坑：一定要先 downloadFile

现象：安卓真机保存图片失败，但 iOS 正常。

原因：部分安卓机型对网络图片直接调用 wx.saveImageToPhotosAlbum 会报参数错误，因为该 API 官方文档明确要求 filePath 为本地文件路径。

解决：先下载再保存。

// 先拿临时路径，再保存到相册 wx.downloadFile({ url: item.imageUrl, success(res) { if (res.statusCode === 200) { wx.saveImageToPhotosAlbum({ filePath: res.tempFilePath, success: () => wx.showToast({ title: '已保存', icon: 'success' }), fail: () => handleAuthFail() }) } }, fail: () => wx.showToast({ title: '下载失败', icon: 'none' }) })

这里的 res.tempFilePath 是临时路径，如果用户近期多次保存，临时路径可能被系统清理。稳妥做法是调用 wx.getFileSystemManager().saveFile 把临时文件转成持久文件。不过素材类场景下用户保存后立刻去相册查看，临时路径已够用，重点是别直接传网络 URL。

5.6 一个通用的排障习惯：先看后端返回，再动前端代码

做了几年小程序，最深的一个感受是：这类源码出问题，80% 不在代码逻辑，而在数据层和环境配置。前端白屏先看 Network 面板的请求状态码，再打开调试器看 console 输出，最后才去翻 WXML 绑定。很多人拿到代码先改样式，改了半天发现是云开发环境 ID 没配对。

检查清单：project.config.json 的 appid 是否替换、云开发环境 ID 是否匹配、数据库集合是否创建、collection 权限是否设为「所有用户可读」、图片域名是否白名单、视频域名是否白名单、隐私声明是否勾选。这七项全对，大部分源码跑不起来的问题都能在十分钟内解决。

6. 把这套小程序源码变成有收益的工具：流量主接入与验证方法

6.1 接流量的两个关键点：banner 位置与激励视频时机

图片素材类小程序的收益模型很统一：用户看得越多、保存越多，广告曝光就越多。banner 广告适合放在列表底部，用户滑到分类末尾时出现，不会打断浏览；激励视频则要放在价值交换点上——用户想保存高清原图时，弹一个「看视频解锁高清下载」，这是转化率最高的位置。

激励视频的标准写法：

let videoAd = null function showRewardForHD() { if (wx.createRewardedVideoAd) { videoAd = wx.createRewardedVideoAd({ adUnitId: 'adunit-你的广告位ID' }) videoAd.onClose((res) => { if (res && res.isEnded) { // 用户看完并关闭，执行高清下载 downloadHDImage() } else { wx.showToast({ title: '看完视频再保存哦', icon: 'none' }) } }) videoAd.show().catch(() => { videoAd.load().then(() => videoAd.show()) }) } }

激励视频广告位 ID 需要在流量主后台创建，通过审核后才能拿到，测试阶段可以用开发者工具里提供的测试广告位来验证逻辑。注意 onClose 里的 res.isEnded 判断不能省，很多用户看一半就关，这个字段决定了要不要放行。

6.2 用埋点验证这套源码值不值得投入

源码本身不产生价值，产生价值的是用户行为数据。建议在三个位置埋点：分类点击数、详情页打开数、保存成功数。用云开发的数据统计能力，或简单的埋点上报，数据量小的时候直接写进一个统计集合即可。重点看保存点击数。

如果保存率和详情页打开率长期低于 30%，问题通常出在内容质量或授权链路上，而不是页面样式。这时候先去查保存失败日志，优先解决第 5 章里说的授权坑，再优化图片吸引力。反过来，如果保存率很高但流量主收入很低，说明用户在晚上或周末集中使用，而广告填充率不足，可以考虑在低谷时段调整激励视频的出现位置。

做素材类小程序，我个人的习惯是每天开盘前看前一天的保存失败数和激励视频点击率，这两个数比新增用户数更真实地反映健康度。这套源码第一周的正常表现应该是：列表页分类点击率不低于 60%，保存成功率回到 95% 以上，激励视频人均触发不少于 0.5 次。达不到，就往数据传输合法域名或授权流程上查，别急着换 UI。希望这些调试路径能帮到你，让这套情侣头像、朋友圈背景、动态壁纸三合一的源码少走些弯路。

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