微信小程序电影周周看源码拆解：云开发与支付实战

简介一份面向微信小程序初学者的完整项目源代码以“电影周周看”为实战案例帮助读者理解小程序从全局配置到页面交互的完整开发流程。压缩包共30个文件大小仅1.02MB其中6个json承担项目与页面的配置声明5个js负责全局逻辑和页面行为4个wxss与3个wxml完成视图层布局与样式png、gif、jfif等图片素材则用于界面展示与功能演示。资源目录划分清晰app.json、app.js、app.wxss定义小程序运行框架pages目录下weekly、detail、about三个页面分别对应列表、详情和个人中心等常见场景utils中的util.js集中封装可复用函数方便新手学习模块化写法。已有2832人学习下载非常适合零基础读者对照源码逐行拆解掌握WXML模板语法、WXSS样式控制及JavaScript事件绑定等核心技能为独立开发小程序打下坚实基础。 做微信小程序开发五六年期间维护过不少内容类项目。最近整理出一套电影周周看的微信小程序源代码打包成 .7z 发出去后陆陆续续收到一些开发者私信问得最多的不是“这个项目怎么跑”而是“这代码里为什么这么设计”。与其挨个解释不如把整套思路、目录结构、支付接入和踩过的坑摊开来写一篇拆解。这篇东西适合两类人看一是刚接触微信小程序、想找一个完整项目练手的初学者二是准备做内容推荐类小程序、想复用一套现成方案的朋友。电影周周看不是那种大而全的视频平台它核心就干一件事按周推荐电影。这个定位决定了它不需要复杂的后台管理、权限体系、多级分类功能边界可以做得非常收敛。但功能少不等于代码简单为了保证“每周推荐”这个体验足够顺滑项目里涉及云开发数据库、云函数、微信支付 v3、自定义导航栏、视频播放等多个技术点串起来就是一个很有代表性的内容类小程序样本。1. 项目定位一个周更场景下的电影小程序该长什么样拿到源码压缩包之后第一步不是急着导入开发者工具而是先理解“电影周周看”这个名字背后的产品逻辑。它不是一个电影大全而是一个每周更新片单的推荐工具。用户每周打开首页看到的是本周片单不是几百个分类和上千部影片。这个差异直接影响页面结构、数据结构甚至用户体验路径。首页把“本周推荐”放在最高优先级先让用户在三秒内看到有价值的内容。相比那些一进来就是注册引导、消息推送、分类入口的 App这种内容优先的设计方式在留存上更有优势。我当初设计这套源码时刻意保留了这个克制的前置逻辑代码里没有做任何强制登录和授权弹窗用户不点“我的”甚至可以完全不触发授权流程。1.1 核心功能拆解整套小程序功能可以拆成五块首页轮播图加本周片单轮播复用本周推荐影片不用单独维护一套广告位数据详情页海报、评分、导演演员、剧情简介、预告片播放、收藏按钮搜索按片名和导演做模糊检索数据源来自云数据库我的头像昵称展示、我的收藏、观看记录、会员状态会员页展示会员权益触发微信支付流程会员状态在后端落库。这五个页面覆盖了内容类小程序的典型闭环发现内容、查看详情、收藏/记录、为增值能力付费。后面你想改成书单周周看、食谱周周看只需要把数据集合字段替换一下页面结构基本能照搬。1.2 为什么坚持原生微信小程序而不是 uni-app源码里没有用 uni-app 或者 Taro 这类跨端框架不是它们不好而是内容类小程序用原生开发的地板比想象中低。这个项目核心页面就五六张原生小程序的 WXML、WXSS、JS 三件套完全够用而且遇到问题时网上可复现的原生语法答案最多排查起来最省时间。依赖方面的取舍也值得说明一下。样式部分用了 less 写嵌套但没有引入完整的 UI 组件库weui 只取里面几个控件的样式片段。数据拉取走微信云开发省去自己搭服务器的成本。这样选型的结果是拿到源码、导入微信开发者工具、开通云环境按文档操作十分钟左右能跑起来。对想快速理解小程序运行机制、又不想被复杂工程化折腾的朋友来说这套源码的阅读曲线是比较友好的。2. 源码包目录逐一拆解全局配置、请求封装与云函数解压 .7z 之后顶层是两个核心目录miniprogram和cloudfunctions再加上project.config.json工程文件。project.config.json保存了开发者工具的编译设置和 appid导入时记得把 appid 换成自己的测试号或者正式号否则云开发环境会关联到别人的账号下。2.1 app.json 的页面注册与 tabBar 配置miniprogram/app.json是全局配置入口。这套项目注册了四个 tabBar 页面首页、搜索、我的、会员。底栏常驻四个入口用户可以在推荐内容、内容检索、个人中心、会员开通之间快速切换。这里有个设计细节会员入口为什么单独占一个 tabBar 位置。通常内容类小程序会把“我的”放最后会员入口一般藏在个人中心里面。但电影周周看的核心变现就是会员把入口提前可以提升开通率代价是底栏多占一个位置。如果你不打算做付费功能把这个 tab 删掉即可只需同步改 app.json 里的 pages 列表和 tabBar 配置。还要特别注意app.json里的style: v2。这个配置会让组件使用新版样式老项目中一些 button、navigator 的默认间距会变化。如果你二开之后发现某个按钮突然多了一圈默认边框优先检查这个配置。2.2 工具类与请求封装项目里统一维护了一个utils/request.js用来包装云函数调用。很多新手写小程序喜欢在 Page 里直接wx.cloud.callFunction短期看着方便页面多了以后重复代码会非常密集。我的做法是统一封装const callFunction async (name, data {}) { const res await wx.cloud.callFunction({ name, data }); if (res.result res.result.code 0) { return res.result.data; } wx.showToast({ title: res.result.message || 请求失败, icon: none }); throw new Error(res.result res.result.message); }; module.exports { callFunction };页面里就变成了const list await callFunction(getWeekly)请求细节、错误提示、统一返回格式全部收口到一个文件里。这套源码所有页面都遵守这个约定新加页面直接复用即可不用重复处理 loading 和报错逻辑。2.3 云函数目录cloudfunctions下按业务拆了四个函数getWeekly返回本周推荐片单getMovieDetail返回影片详情和播放地址searchMovie按关键字模糊搜索影片createOrder创建会员订单调用微信支付统一下单payNotify处理支付回调通知验签解密后更新会员状态。后面两个函数涉及支付逻辑会稍微复杂一些代码里已经用注释标明了哪里需要换成你自己的商户号、证书序列号和 API v3 密钥。有一点容易被忽略云函数的 node_modules 没有打进压缩包部署时需要在每个函数目录下执行一次npm install漏掉这步会直接报 module not found。3. 周推荐数据结构和首页拼装过程首页是整个源码的核心场景。运营人员每周在数据库写入一组推荐数据用户打开小程序时看到的就是最新片单。这个“每周更新”的节奏通过数据集合里的weekLabel和publishTime字段实现不是在前端写死的。3.1 数据库集合设计我建了四个集合movies存影片主表weekly存每周推荐配置users存用户和会员信息orders存订单记录。movies集合的一条记录大概长这样{ _id: movie_001, title: 星际穿越, director: 克里斯托弗·诺兰, rating: 9.4, year: 2014, poster: cloud://example.jpg, brief: 近未来的地球黄沙遍野人类生活面临巨大威胁……, trailerUrl: https://example.com/trailer.mp4, playUrl: https://example.com/movie.mp4, tags: [科幻, 冒险] }这里比较容易踩坑的是poster字段。项目支持两种图片来源一种是云存储 fileID以cloud://开头WXML 里可以直接渲染另一种是外链 HTTPS 图片但域名必须在小程序后台加进 downloadFile 合法域名白名单真机上才能正常显示。weekly集合的结构更简单{ _id: weekly_2025_w13, weekLabel: 2025年第13周, movieIds: [movie_001, movie_002], publishTime: 1736611200000 }首页拉数据时先取publishTime最近的一条 weekly 记录再根据movieIds批量查影片详情。这样推荐列表和影片主表分离运营调整片单顺序时不用去改影片本身的数据也方便以后做“往期片单”的翻页回顾。3.2 首页 WXML 拼装逻辑首页从上到下分三段swiper 轮播、本周片单列表、更多电影网格。轮播数据不是单独配置的而是复用本周片单里评分最高的三部减少运营配置成本。列表用wx:for渲染每条记录绑定bindtap跳转详情页。跳转时我只传一个_id参数详情页再根据_id调接口拉完整数据。有的代码习惯是把整个对象JSON.stringify之后通过 URL 传过去这样做页面加载快一点但数据一旦更新详情页看到的可能是过期内容。传_id虽然多一次网络请求但能保证数据一致性。页面在onShow里会检查本地缓存如果发现自己已经看过本周片单且数据在有效期内就直接先渲染本地缓存再后台刷新避免每次打开首页都白屏等接口。这个策略对内容类小程序很重要用户心智是“快速打开看推荐”不是“等待加载”。4. 详情页、搜索与“我的”用户留存三件套详情页是整个项目信息密度最高的页面同时要处理收藏状态、观看记录、会员解锁、播放器初始化四件事。如果全部堆在 Page 里代码会很乱所以我把“收藏”和“浏览历史”抽成了独立模块也就是utils/favorite.js和utils/history.js本质都是对wx.setStorageSync的封装。4.1 播放器与会员解锁预告片播放用的是小程序原生 video 组件。这里有一个非常容易踩的坑video 组件的 src 不认cloud://协议。如果播放地址存在云存储里必须先通过wx.cloud.getTempFileURL把 fileID 转成临时 HTTPS 链接再塞给 video否则真机上直接黑屏。正片播放做了会员校验。播放按钮点击后云函数会查询当前用户的vipExpireTime过期或者没有记录就弹引导层按钮文案变成“开通会员后观看”。这里的小技巧是不要把所有影片都拦住预告片永远免费只有正片需要会员。让用户先看完一段高质量内容再决定付费转化率会比直接弹购买页好很多。4.2 搜索能力的实现边界搜索页面没有接外部搜索服务直接用云开发数据库的查询能力const db wx.cloud.database(); const _ db.command; const res await db.collection(movies) .where(_.or([ { title: db.RegExp({ regexp: keyword, options: i }) }, { director: db.RegExp({ regexp: keyword, options: i }) } ])) .limit(30) .get();这种方式适合几百部影片的小规模数据。如果以后内容量涨到上万条建议把搜索逻辑挪到云函数里做聚合或者给 title 字段加索引再考虑用前缀匹配代替整段模糊搜索调用速度和配额消耗都会好很多。小项目先跑通等量上来了再优化这个顺序不要反过来。4.3 用户信息授权的变化“我的”页面里有头像和昵称展示。早期代码用wx.getUserProfile弹窗获取但平台后来收紧了用户隐私策略新写法是让用户主动点击头像昵称填写组件不能在小程序启动时直接弹。源码里我改成了button open-typechooseAvatar配一个昵称输入框用户点了才拉数据这样能减少审核麻烦也符合现阶段的隐私合规要求。会员状态展示同样在“我的”页面从users集合取vipLevel和vipExpireTime过期就显示“续费”按钮跳转去会员页。这里提醒一句客户端展示会员到期时间可以但正片播放的权限校验必须在云函数里做不能信任前端传过来的状态。否则别人改一下本地缓存就能绕过支付逻辑这是我后来实际发现过的漏洞。5. 微信支付 v3 接入实录以及支付权限被回收的教训会员支付流程是这套源码里最有学习价值的部分。微信支付 v3 和 v2 最大的区别是签名方式v3 使用Authorization: WECHATPAY2-SHA256-RSA2048请求头敏感字段用 AES-256-GCM 加密而不是以前那种简单的 MD5 加密钥方式。项目中我把支付逻辑都收敛在云函数createOrder和回调函数payNotify里前端不处理任何敏感参数。5.1 统一下单的云函数实现要点v3 接口下单之前要准备好四样东西商户号、商户 API 证书序列号、商户 API 私钥、API v3 密钥。云函数里用 Node.js 发起 HTTP 请求签名串格式如下POST\n /v3/pay/transactions/jsapi\n 1630000000\n randomstring\n {appid:...,mchid:...,description:...,out_trade_no:...,notify_url:...,amount:{total:100,currency:CNY}}\n把这个字符串用商户私钥做 SHA256 签名拼成WECHATPAY2-SHA256-RSA2048 mchid...,nonce_str...,signature...,timestamp...,serial_no...请求头。拿到prepay_id之后还要对客户端参数再做一次签名返回给小程序端const payment { timeStamp, nonceStr, package: prepay_id${prepayId}, signType: RSA, paySign };小程序端拿到这个对象后调用wx.requestPayment。这里有个细节值得说一下对象里的package字段要加引号因为package是保留字直接写成package:在一些低版本基础库会编译报错。很多第一次接支付的朋友卡在编译阶段其实就是这个问题。5.2 回调通知的验签与解密支付结果不能只看前端success回调必须以后台收到微信服务器主动 POST 到notify_url的通知为准。云函数payNotify拿到回调报文后做三件事用微信支付平台证书验签确认报文来自微信官方取resource字段中的密文用 API v3 密钥和 AES-256-GCM 解密根据out_trade_no更新orders和users里的会员到期时间。解密部分如果手写特别容易出错最典型的问题是把authTag和ciphertext的顺序搞反。我第一次实现时调试了大半天最后换成官方维护的wechatpay-node-v3库才跑通。这也是我把依赖写进代码注释的原因省得后人再踩一遍。5.3 关于“小程序违规导致支付功能暂时无法使用”的教训代码里完整实现了支付但我要把话说在前面支付功能不是写进代码就能用的。如果小程序自身存在违规记录或者经营类目和支付场景不匹配平台会暂停支付能力前端表现就是“支付功能暂时无法使用”。这个限制是账号维度的和源码本身没有关系。我做这个项目时也遇到过类似状态后来排查出来主要有两个原因类目选得过于宽泛支付场景和实际类目对不上把虚拟服务做成了简单充值缺少真实商品或服务履约流程。所以现在这套源码里会员页面先展示会员权益再明确生成订单最后走支付。如果你在二次开发一定要把支付业务设计成“购买真实有用的服务”而不是一个单纯的打赏或虚拟币充值。这样平台审核和支付开放都会顺利很多也能避免把自己折腾进“支付功能封禁—申诉—补充材料”的循环里。6. 把源码跑起来之后常见的坑与排障思路最后整理一下部署和二开过程中最常遇到的五个问题我按照实际排查链路来写争取对号入座直接解决。6.1 video 无法播放先别怀疑代码有一段时间好几个朋友反馈预告片黑屏。我让他们先把trailerUrl复制到浏览器打开发现浏览器能播小程序里却黑屏。原因基本都在视频编码格式或者域名白名单上。小程序 video 组件对编码兼容性是有要求的H.264 编码的 MP4 是兼容性最好的格式FLV、MKV 以及部分 MPEG-TS 流在部分机型上不支持转码后问题基本消失。另一个常见原因是“资源域名校验”。开发者工具上可以勾选“不校验合法域名”但真机不行。视频播放域名必须在小程序后台加到 downloadFile 合法域名配置完最好杀掉小程序重进一次再测否则缓存可能还带着旧配置。6.2 自定义导航栏高度计算项目里用了自定义导航栏这样才能实现沉浸式头图。原生导航栏在列表滚动时标题一直占着位置自定义之后可以把背景色和状态栏连成一体。但 custom 之后需要手动获取高度否则页面内容会顶到状态栏下面const systemInfo wx.getWindowInfo(); const menuButton wx.getMenuButtonBoundingClientRect(); const navBarHeight (menuButton.top - systemInfo.statusBarHeight) * 2 menuButton.height;这段计算公式是为了适配不同手机的胶囊位置。安卓和 iOS 的状态栏高度、胶囊尺寸都不一样直接写死常数是自定义导航栏上下错位的主要原因。源码里把这段逻辑放进了utils/navigation.js同时兼容了 iPhone 灵动岛。6.3 调试时抓包的建议排查网络请求时开发工具自带的 Network 面板很好用但真机上出现的接口返回差异有时候在开发者工具里复现不了。这时可以借助代理工具抓真机小程序流量。抓包前需要确认微信已经开启了“使用系统代理”相关的代理设置再把小程序切换到调试模式否则流量全走加密通道代理工具只能看到 TLS 握手看不到明文请求。拿到请求之后对比线上环境和本地的env参数通常很快就能定位是数据源不一致还是请求头被代理污染了。6.4 提审前的自检清单最后是一份我每次发版前都会过的检查清单app.json里所有页面路径都存在没有多余的已注册页面会员支付环境切换成正式商户号避免测试订单触发告警所有云函数依赖安装完整密钥没有硬编码进前端代码视频域名、图片域名都已经加进合法域名白名单使用chooseAvatar、chooseMedia等隐私接口时已经配置好用户隐私保护指引清缓存后完整走一遍链路首页加载、搜索、看预告片、下单支付、支付回调、会员状态更新。这套源码里我特意留了几处 TODO 标记给使用者留了一个动手的位置。源代码压缩包在我看来不是终点拆开理解、改掉验证、跑通自己的版本才算真正拿到了这套代码的价值。后面我还会继续更新周更数据的导入脚本和运营后台到时候再写一篇完整的数据流说明补上。本文还有配套的精品资源点击获取