简介这是一份面向微信小程序学习者的豆瓣电影查询项目源码包以完整可运行的示例形式呈现适合正在学习WXML/WXSS页面搭建和JavaScript交互逻辑的开发者作为练手参考。压缩包共含24个文件其中8个JS逻辑脚本负责页面交互与数据处理4个WXSS样式表定制界面视觉3个WXML页面结构搭建页面骨架3个JSON配置文件管理全局与页面参数另附4张PNG、1张GIF图片素材和1份说明文档整体大小仅1.85MB结构紧凑、便于逐个模块拆解。项目核心代码覆盖App.js全局配置与Page.js页面管理以及数据绑定、setData动态刷新、页面路由跳转、用户授权和常见动画交互等关键技能通过阅读源码和运行调试可理解请求豆瓣API时对电影列表、评分和简介等数据的处理方式进而掌握微信小程序从开发、调试到发布上线的完整流程。目前已有890人学习下载特别适合刚接触小程序开发、希望用真实项目巩固基础并进阶提升的开发者。 看到“微信小程序豆瓣电影.zip”这个标题我第一反应就是又一个拿豆瓣数据练手的小程序项目。这类项目在开发者圈子里一直很火原因也很简单——豆瓣电影有完善的数据结构、清晰的业务场景做出来的东西看得见摸得着不管是拿来练手、做毕设还是想上架搞点流量都很合适。这个项目本质上就是一个基于豆瓣电影数据接口的微信小程序包含电影列表展示、搜索、详情页、评分展示、收藏等核心功能最后打包成zip分发。它能解决什么实际问题往小了说是让你快速上手小程序开发全流程往大了说是让你摸清楚一个完整应用从零到上线的每个环节。适合新手学习也适合有经验的人快速搭一个电影类应用框架。我会从整体设计、核心功能实现、真实踩坑记录、打包分发这几个维度把整个项目拆开揉碎了讲。下面直接进入正题。1. 项目整体设计与技术选型思路1.1 核心需求拆解先别急着写代码动手之前得把需求理清楚。豆瓣电影类小程序核心需求其实就四块电影内容展示包括正在热映、即将上映、Top250这些榜单以及电影的海报、简介、评分、演员信息。搜索能力用户能按片名搜索电影搜索结果要能按评分、年份排序。收藏与记录用户可以把想看的电影加入收藏数据要存在本地或后端。基础体验加载状态、网络异常提示、下拉刷新、触底加载这些细节不能少。这四块听起来简单但每一块展开都有不少细节。比如“正在热映”什么时候更新“即将上映”的数据源稳不稳定评分展示用星星还是数字这些都需要在动手前想清楚。1.2 技术选型原生框架还是uni-app很多人在技术选型上纠结我直接说结论个人项目优先选原生小程序框架哪怕你之后要上 uni-app也建议先用原生跑通一个完整项目。原因有三点原生框架性能最好没有中间层的损耗上手门槛也不高WXML和WXSS其实就是语法糖版本的HTML和CSS。原生开发者工具对项目结构的提示、调试、性能分析都最直接出问题好排查。踩坑资料最多。你在社区搜到的问题答案90%是基于原生框架的。uni-app的优势是跨端一套代码能跑小程序、App、H5但代价是你在排查问题时要多绕一层比如热词里提到的“uniapp保存图片失败saveImageToPhotosAlbum:fail”大概率是uni-app封装层的适配问题不是微信原生API的问题。所以我的建议是如果是练手原生如果是商业项目且确定要多端投放uni-app但要做好多端适配的心理准备。本项目的核心逻辑用原生框架来写后期如果需要跨端原生代码也能迁移到uni-app中成本并非不可接受。1.3 项目目录结构规划一个清晰的项目结构能省掉你大量找文件的烦恼。我在这个项目里的目录划分如下project/ ├── app.js // 全局逻辑App实例 ├── app.json // 全局配置页面路由窗口表现 ├── app.wxss // 全局样式 ├── project.config.json // 项目配置 ├── sitemap.json // 微信索引配置 ├── assets/ // 静态资源 │ ├── icons/ // 小程序内引用的小图标 │ └── images/ // 默认图、占位图 ├── utils/ │ ├── request.js // 请求封装 │ ├── util.js // 工具函数格式化时间/评分等 │ └── constant.js // 全局常量接口地址密钥 ├── pages/ │ ├── index/ // 首页-电影列表 │ ├── search/ // 搜索页 │ ├── detail/ // 电影详情页 │ ├── favorite/ // 收藏页 │ └── profile/ // 个人中心页 └── components/ ├── movie-card/ // 电影卡片组件 ├── star-rate/ // 星级评分组件 └── empty-view/ // 空状态占位组件组件化这个事很多人早期项目不注意所有代码堆在page里结果一个页面几千行维护起来痛不欲生。我的建议是从小项目就养成拆组件的习惯电影卡片、评分星星、空状态这类UI元素独立成组件不仅首页用、搜索页用、收藏页也用改动一处全局生效这才是组件化存在的意义。2. 核心功能实现与关键代码解析2.1 电影列表与请求封装这个项目里所有页面都要发请求所以第一步是封装一个统一的请求方法。核心诉求有两个统一处理成功和失败统一处理异常提示。// utils/request.js const request (url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url, method, data, header: { Content-Type: application/json }, success: (res) { if (res.statusCode 200) { resolve(res.data); } else { wx.showToast({ title: 请求失败请重试, icon: none }); reject(res); } }, fail: (err) { wx.showToast({ title: 网络异常请检查网络, icon: none }); reject(err); } }); }); };这里有个关键设计把请求封装成Promise调用方就能用async/await的方式写代码处理压平回调地狱。很多新手项目直接用wx.request原生回调页面里嵌套三四层success/fail代码像意大利面一样那就是给自己挖坑。首页电影列表我用了滚动分页加载的方案这是列表类页面最常见的交互模式。每次请求一页数据滚动到底部后把页码加一继续请求直到没有更多数据。Page({ data: { movies: [], page: 1, pageSize: 20, hasMore: true, loading: false }, async loadMovies(reset false) { if (this.data.loading) return; if (!reset !this.data.hasMore) return; this.setData({ loading: true }); if (reset) { this.setData({ page: 1, movies: [], hasMore: true }); } try { const res await request(/api/movie/top250?start${this.data.page * this.data.pageSize}count${this.data.pageSize}); const movies reset ? res.subjects : this.data.movies.concat(res.subjects); const hasMore movies.length res.total; this.setData({ movies, page: this.data.page 1, hasMore, loading: false }); } catch (err) { this.setData({ loading: false }); } }, onReachBottom() { this.loadMovies(); }, onPullDownRefresh() { this.loadMovies(true).then(() wx.stopPullDownRefresh()); } });分页参数的设计要注意start表示起始位置count表示每页数量。豆瓣旧版API里Top250的total最多是250这个数字决定了hasMore的判断逻辑不能拍脑袋写个死循环。2.2 电影详情页与数据传递列表页点击卡片跳转详情页最常用的方式是使用URL参数传idwx.navigateTo({ url: /pages/detail/detail?id${movieId} });详情页在onLoad里接收id再根据id请求详情接口。这里有一个细节要提醒详情页里有时会有上一页传过来的部分数据比如海报地址可以用它做首屏占位然后在onLoad里异步拉取完整详情这样用户体验比一张白屏好很多。Page({ data: { movieId: null, detail: null, loading: true }, onLoad(options) { this.setData({ movieId: options.id }); this.loadDetail(); }, async loadDetail() { try { const res await request(/api/movie/subject/${this.data.movieId}); this.setData({ detail: this.processDetail(res), loading: false }); } catch (err) { this.setData({ loading: false }); } }, processDetail(data) { // 预处理数据比如把演员列表拼成字符串 const casts (data.casts || []).map(c c.name).join( / ); return { ...data, castsText: casts }; } });预处理数据这个步骤很容易被忽略但实际体验影响很大。原始接口返回的数据结构跟页面展示需求不一定一致比如演员列表、导演列表接口给的是数组页面上要显示成“导演XXX”你就在这个环节拼好不要到WXML里用花括号写复杂逻辑。WXML模板里尽量保持简洁只做数据绑定复杂的数据加工放JS。2.3 星级评分组件的实现评分组件看似简单但里面有个细节豆瓣评分是带小数点的比如8.6分、9.2分用整颗星没法精确表达。我的实现方案是使用半颗星效果具体做法是这样view classstar-rate !-- 底层灰色星星 -- view classstar-layer text classstar★★★★★/text /view !-- 上层高亮星星宽度按分数比例变化 -- view classstar-layer highlight stylewidth: {{percent}}%; overflow: hidden; text classstar★★★★★/text /view /viewComponent({ properties: { score: { type: Number, value: 0 } }, observers: { score(newVal) { // 豆瓣10分制换算成5颗星每颗星占20% const percent Math.round((newVal / 10) * 100); this.setData({ percent }); } } });这个思路很简单底层永远显示五颗灰星上面一层是五颗同样的星但颜色是黄色宽度按percent裁剪就像一把尺子量出多少显示多少。4.3分就是43%宽度视觉上刚好两个多一点的星星。这种方案比用图片或者逐帧判断整数星再补半个星图的方式更精确也更好维护。2.4 搜索页与防抖处理搜索这个功能最大的坑就是过度请求。用户每敲一个字就发起一次搜索请求接口扛不住流量也会大量浪费。常规做法是加防抖debounce。let timer null; function searchMovie(keyword) { clearTimeout(timer); timer setTimeout(async () { if (!keyword) return; const res await request(/api/search?q${encodeURIComponent(keyword)}); this.setData({ results: res.subjects }); }, 300); }300毫秒是权衡后的选择太短没防抖效果太长用户会觉得卡顿。另外搜索关键字要记得encodeURIComponent编码保含中文、特殊字符时不至于把URL弄坏了。搜索结果的展示跟首页列表很相似完全可以复用movie-card组件这就是把组件抽出来带来的直接好处——新页面开发成本被大幅压缩。2.5 收藏功能的本地存储设计收藏功能用微信的wx.getStorageSync和wx.setStorageSync就能实现不需要后端。但这个功能想做好数据结构要提前想清楚。// 存储结构{ movieId: { id: , title: , image: , rating: , createdAt: }, ... } // 每个电影id作为key方便查询和去重 function toggleFavorite(movie) { const favorites wx.getStorageSync(favorites) || {}; if (favorites[movie.id]) { delete favorites[movie.id]; } else { favorites[movie.id] { ...movie, createdAt: Date.now() }; } wx.setStorageSync(favorites, favorites); return !!favorites[movie.id]; }用对象做存储而不是数组理由是查询和去重的复杂度是O(1)。如果用数组每次判断某部电影是否已收藏都要遍历一遍数据多了性能不佳代码也麻烦。收藏页在onShow里读存储并更新页面。注意一定要用onShow而不是onLoad因为从详情页返回收藏页时onLoad不会重新执行但onShow会。这是小程序页面生命周期的一个经典坑。3. 踩坑实录兼容性与交互细节3.1 全局网络异常提示网上有人问“网络不可用的时候怎么全局统一显示网络不可用提示”这个问题的本质是你不想在每个页面的每个请求回调里都写一遍错误处理。我的做法是在请求封装里统一拦截。上面代码里已经做了fail回调里弹出toast。但更好的做法是可以做一个全局的页面状态// utils/request.js function checkNetwork() { return new Promise((resolve) { wx.getNetworkType({ success: (res) { resolve(res.networkType ! none); }, fail: () resolve(true) }); }); }在App启动时监听网络状态变化// app.js App({ onLaunch() { // 监听网络状态变化 wx.onNetworkStatusChange((res) { if (!res.isConnected) { // 断网时通过全局事件通知页面显示网络异常 const pages getCurrentPages(); const currentPage pages[pages.length - 1]; if (currentPage currentPage.showNetworkError) { currentPage.showNetworkError(); } } }); } });这个方案的核心思路是页面不主动感知网络状态而是接收全局事件通知。你在每个页面里封装一个showNetworkError方法断网时调用它切换页面状态展示全屏的网络异常占位图。不过要提醒一点如果要做得更精细网络状态监测最好配合全局状态管理比如用全局变量或观察者模式否则页面多了以后事件通知也容易乱。3.2 自定义导航栏高度适配很多小程序会关闭默认导航栏做自定义导航先把胶囊按钮的位置搞清楚再去算高度。关于顶部导航栏高度网上有一堆文章其实核心就一个公式状态栏高度 wx.getSystemInfoSync().statusBarHeight 导航栏高度 胶囊按钮位置top - 状态栏高度 (胶囊按钮高度 - 胶囊按钮与状态栏的间距) * 2说得更直白一点computeNavBarInfo() { const info wx.getSystemInfoSync(); const rect wx.getMenuButtonBoundingClientRect(); const statusBarHeight info.statusBarHeight; // 导航栏高度通常约等于44pxiPhone X以上因为刘海屏会有差异 const navBarHeight (rect.top - statusBarHeight) * 2 rect.height; this.setData({ statusBarHeight, navBarHeight }); }为什么navBarHeight要这么算因为胶囊按钮在导航栏中的垂直居中位置决定了整个导航栏的高度。胶囊按钮顶部到状态栏底部的距离乘以2再加上胶囊按钮的高度就是导航栏的总高度。不同机型上的胶囊按钮位置会微调所以一定要在运行时动态计算绝不写死44px。3.3 swiper嵌套video全屏错位有开发者遇到“iOS中swiper组件嵌套video组件导致全屏错位”的问题这个bug很典型我也遇到过。出错的场景是在swiper里放多个video点击一个视频全屏播放退出全屏后整个轮播图错乱。问题根因是video组件在小程序里是一个原生组件层级最高跟swiper的滚动手势会有冲突。iOS上全屏切换时原生组件的frame信息更新异常导致显示错位。坑位一能否再问一下视频全屏时能不能隐藏其他视频这个跟具体业务有关如果只是单一视频就推荐不用swiper直接在页面里放video。我推荐的方案是不要在swiper里直接放video而是用视频封面图代替点击封面时才动态渲染video组件。swiper swiper-item wx:for{{videos}} wx:keyindex !-- 未播放时显示封面 -- image wx:if{{!playingIndex index}} src{{item.cover}}>// 保存网络图片到相册 function saveImageToAlbum(url) { return new Promise((resolve, reject) { wx.downloadFile({ url, success: (res) { wx.saveImageToPhotosAlbum({ filePath: res.tempFilePath, success: resolve, fail: (err) { if (err.errMsg.includes(auth deny) || err.errMsg.includes(authorize)) { wx.showModal({ title: 提示, content: 需要您授权相册权限才能保存图片, success: (modalRes) { if (modalRes.confirm) { wx.openSetting(); } } }); } reject(err); } }); }, fail: reject }); }); }另外微信对没有用户点击行为触发的保存经常拦截所以这类操作必须放在按钮的tap事件回调里做不要在网络请求的回调里自动触发。4. 项目打包、部署与分发4.1 微信开发者工具上传流程项目开发完在微信开发者工具里点“上传”填写版本号和备注代码就到了微信后台。然后去mp.weixin.qq.com配置为体验版扫码即可预览。正式发布要在后台提交审核个人主体的小程序审核相对快一些。这里提一个大家常忽略的步骤request合法域名配置。开发时可以在开发者工具里勾选“不校验合法域名”来绕过限制但体验版和正式版必须在后台把用到的接口域名加入“request合法域名”列表否则请求直接失败。前缀必须是https且域名不能带路径参数。4.2 zip打包的正确姿势项目交付或开源分发时通常会把整个工程压缩成zip。打包有几点要注意node_modules目录不打包如果有依赖保留package.json即可别人拉下来后npm install。打包前删掉开发者工具生成的文件如 unpackage目录如果是uni-app、.idea、.vscode等编辑器配置保持工程干净。如果是给别人的源码最好附带一个README写清楚运行步骤、接口地址、AppID配置。# 打包命令示例 zip -r my-movie-app.zip . -x node_modules/* .git/* .idea/* .vscode/*4.3 关于源码保护有热词提到“已经部署的微信小程序怎么能拿到源码”这里我多说两句。小程序打包发布后代码是经过编译混淆的但不要把它想成绝对安全。只要有足够的技术手段前端的逻辑还是可以被逆向分析出来。所以如果你们的项目有敏感逻辑比如密钥、算法一定要放在服务端不要在客户端代码里有任何隐秘逻辑。对于正常的开源项目打包成zip分发时建议在README里标明技术栈、运行环境要求、可能存在的接口限制。这样别人拿到项目后能很快跑起来而不是发消息追问你“怎么报错”。5. 常见问题与排查技巧实录做一个排查速查表可以直接粘贴到你的项目README里也可以拿来当自查清单。问题现象可能原因排查思路与解决办法首页数据加载不出来接口域名未配置到合法域名列表检查mp后台-开发管理-服务器域名确认request合法域名包含接口域名图片加载失败图片域名未配置downloadFile合法域名如果图片是网络链接需要配置为“downloadFile合法域名”保存图片到相册失败网络图片没有先下载先wx.downloadFile再saveImageToPhotosAlbum页面白屏JS报错 或 数据为空打开vConsole查看console错误检查接口返回数据结构是否符合预期真机正常模拟器异常可能是机型兼容问题用真机调试工具查看具体报错堆栈onReachBottom不触发页面没有设置可滚动高度检查页面是否被page容器包裹且页面整体没有overflowhidden限制收藏数据丢失小程序缓存被清除本地存储本来就有生命周期重要数据需要同步后端用户切换账号后数据窜了storage按设备存储不区分账号如果有多账号登录场景存储key里加上用户唯一标识自定义导航栏在不同机型上错位没有动态计算胶囊位置用wx.getMenuButtonBoundingClientRect计算不要把高度写死定位问题的通用心法就一句话先把问题缩小到数据层、渲染层还是交互层。数据层的错误看Network和Console渲染层的错误看WXML渲染结果和样式计算交互层的错误需要自己一遍遍复现操作路径。大多数小程序问题90%都出在数据层——接口返回和预期不一致。还有一个小技巧开发时多利用微信开发者工具的“隔离调试”和“真机调试”两种模式配合使用很多模拟器上无法复现的机型问题真机上一抓一个准。6. 项目扩展思路与个人经验这个项目做完之后后续扩展空间很大。比如接入mpvue做多端复用比如加一个后台管理系统来管理影片数据再比如引入WebSocket做即时互动功能。但如果你是新手我不建议一上来就加这些复杂度先跑通一个完整的闭环——从列表到详情到收藏——比堆功能更重要。另外现在微信小程序生态里个人开发者的流量扶持相对有限但如果这个项目能跑出一个完整的开发流程后面做成“电影推荐”“影单分享”之类的差异化产品定位也不失为一个方向。在接口数据这块要特别提醒豆瓣官方开放接口已经很有限且政策随时可能调整。做学习项目时使用非官方或社区维护的接口要注意合规风险。如果你的项目要长期上线建议自建一个简单的后端服务来代理请求或者使用自己整理的数据文件。这既是法律合规的底线也是技术上对项目可持续性的保障。最后再分享一个小习惯每次开发到一个小里程碑就用git打一个tag比如v0.1.0、v0.2.0。这样你回头改坏了代码能清楚地知道自己是从哪个版本开始动手的。“微信小程序豆瓣电影.zip”这个项目看起来简单但一趟走下来从框架搭建、接口封装、页面联动、组件拆分到打包上线小程序开发的主流知识点基本都覆盖到了。这套流程跑通一遍下一次再做任何小程序项目你都会有底气。本文还有配套的精品资源点击获取 微信小程序豆瓣电影项目实战：从架构到上线全流程解析
简介这是一份面向微信小程序学习者的豆瓣电影查询项目源码包以完整可运行的示例形式呈现适合正在学习WXML/WXSS页面搭建和JavaScript交互逻辑的开发者作为练手参考。压缩包共含24个文件其中8个JS逻辑脚本负责页面交互与数据处理4个WXSS样式表定制界面视觉3个WXML页面结构搭建页面骨架3个JSON配置文件管理全局与页面参数另附4张PNG、1张GIF图片素材和1份说明文档整体大小仅1.85MB结构紧凑、便于逐个模块拆解。项目核心代码覆盖App.js全局配置与Page.js页面管理以及数据绑定、setData动态刷新、页面路由跳转、用户授权和常见动画交互等关键技能通过阅读源码和运行调试可理解请求豆瓣API时对电影列表、评分和简介等数据的处理方式进而掌握微信小程序从开发、调试到发布上线的完整流程。目前已有890人学习下载特别适合刚接触小程序开发、希望用真实项目巩固基础并进阶提升的开发者。 看到“微信小程序豆瓣电影.zip”这个标题我第一反应就是又一个拿豆瓣数据练手的小程序项目。这类项目在开发者圈子里一直很火原因也很简单——豆瓣电影有完善的数据结构、清晰的业务场景做出来的东西看得见摸得着不管是拿来练手、做毕设还是想上架搞点流量都很合适。这个项目本质上就是一个基于豆瓣电影数据接口的微信小程序包含电影列表展示、搜索、详情页、评分展示、收藏等核心功能最后打包成zip分发。它能解决什么实际问题往小了说是让你快速上手小程序开发全流程往大了说是让你摸清楚一个完整应用从零到上线的每个环节。适合新手学习也适合有经验的人快速搭一个电影类应用框架。我会从整体设计、核心功能实现、真实踩坑记录、打包分发这几个维度把整个项目拆开揉碎了讲。下面直接进入正题。1. 项目整体设计与技术选型思路1.1 核心需求拆解先别急着写代码动手之前得把需求理清楚。豆瓣电影类小程序核心需求其实就四块电影内容展示包括正在热映、即将上映、Top250这些榜单以及电影的海报、简介、评分、演员信息。搜索能力用户能按片名搜索电影搜索结果要能按评分、年份排序。收藏与记录用户可以把想看的电影加入收藏数据要存在本地或后端。基础体验加载状态、网络异常提示、下拉刷新、触底加载这些细节不能少。这四块听起来简单但每一块展开都有不少细节。比如“正在热映”什么时候更新“即将上映”的数据源稳不稳定评分展示用星星还是数字这些都需要在动手前想清楚。1.2 技术选型原生框架还是uni-app很多人在技术选型上纠结我直接说结论个人项目优先选原生小程序框架哪怕你之后要上 uni-app也建议先用原生跑通一个完整项目。原因有三点原生框架性能最好没有中间层的损耗上手门槛也不高WXML和WXSS其实就是语法糖版本的HTML和CSS。原生开发者工具对项目结构的提示、调试、性能分析都最直接出问题好排查。踩坑资料最多。你在社区搜到的问题答案90%是基于原生框架的。uni-app的优势是跨端一套代码能跑小程序、App、H5但代价是你在排查问题时要多绕一层比如热词里提到的“uniapp保存图片失败saveImageToPhotosAlbum:fail”大概率是uni-app封装层的适配问题不是微信原生API的问题。所以我的建议是如果是练手原生如果是商业项目且确定要多端投放uni-app但要做好多端适配的心理准备。本项目的核心逻辑用原生框架来写后期如果需要跨端原生代码也能迁移到uni-app中成本并非不可接受。1.3 项目目录结构规划一个清晰的项目结构能省掉你大量找文件的烦恼。我在这个项目里的目录划分如下project/ ├── app.js // 全局逻辑App实例 ├── app.json // 全局配置页面路由窗口表现 ├── app.wxss // 全局样式 ├── project.config.json // 项目配置 ├── sitemap.json // 微信索引配置 ├── assets/ // 静态资源 │ ├── icons/ // 小程序内引用的小图标 │ └── images/ // 默认图、占位图 ├── utils/ │ ├── request.js // 请求封装 │ ├── util.js // 工具函数格式化时间/评分等 │ └── constant.js // 全局常量接口地址密钥 ├── pages/ │ ├── index/ // 首页-电影列表 │ ├── search/ // 搜索页 │ ├── detail/ // 电影详情页 │ ├── favorite/ // 收藏页 │ └── profile/ // 个人中心页 └── components/ ├── movie-card/ // 电影卡片组件 ├── star-rate/ // 星级评分组件 └── empty-view/ // 空状态占位组件组件化这个事很多人早期项目不注意所有代码堆在page里结果一个页面几千行维护起来痛不欲生。我的建议是从小项目就养成拆组件的习惯电影卡片、评分星星、空状态这类UI元素独立成组件不仅首页用、搜索页用、收藏页也用改动一处全局生效这才是组件化存在的意义。2. 核心功能实现与关键代码解析2.1 电影列表与请求封装这个项目里所有页面都要发请求所以第一步是封装一个统一的请求方法。核心诉求有两个统一处理成功和失败统一处理异常提示。// utils/request.js const request (url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url, method, data, header: { Content-Type: application/json }, success: (res) { if (res.statusCode 200) { resolve(res.data); } else { wx.showToast({ title: 请求失败请重试, icon: none }); reject(res); } }, fail: (err) { wx.showToast({ title: 网络异常请检查网络, icon: none }); reject(err); } }); }); };这里有个关键设计把请求封装成Promise调用方就能用async/await的方式写代码处理压平回调地狱。很多新手项目直接用wx.request原生回调页面里嵌套三四层success/fail代码像意大利面一样那就是给自己挖坑。首页电影列表我用了滚动分页加载的方案这是列表类页面最常见的交互模式。每次请求一页数据滚动到底部后把页码加一继续请求直到没有更多数据。Page({ data: { movies: [], page: 1, pageSize: 20, hasMore: true, loading: false }, async loadMovies(reset false) { if (this.data.loading) return; if (!reset !this.data.hasMore) return; this.setData({ loading: true }); if (reset) { this.setData({ page: 1, movies: [], hasMore: true }); } try { const res await request(/api/movie/top250?start${this.data.page * this.data.pageSize}count${this.data.pageSize}); const movies reset ? res.subjects : this.data.movies.concat(res.subjects); const hasMore movies.length res.total; this.setData({ movies, page: this.data.page 1, hasMore, loading: false }); } catch (err) { this.setData({ loading: false }); } }, onReachBottom() { this.loadMovies(); }, onPullDownRefresh() { this.loadMovies(true).then(() wx.stopPullDownRefresh()); } });分页参数的设计要注意start表示起始位置count表示每页数量。豆瓣旧版API里Top250的total最多是250这个数字决定了hasMore的判断逻辑不能拍脑袋写个死循环。2.2 电影详情页与数据传递列表页点击卡片跳转详情页最常用的方式是使用URL参数传idwx.navigateTo({ url: /pages/detail/detail?id${movieId} });详情页在onLoad里接收id再根据id请求详情接口。这里有一个细节要提醒详情页里有时会有上一页传过来的部分数据比如海报地址可以用它做首屏占位然后在onLoad里异步拉取完整详情这样用户体验比一张白屏好很多。Page({ data: { movieId: null, detail: null, loading: true }, onLoad(options) { this.setData({ movieId: options.id }); this.loadDetail(); }, async loadDetail() { try { const res await request(/api/movie/subject/${this.data.movieId}); this.setData({ detail: this.processDetail(res), loading: false }); } catch (err) { this.setData({ loading: false }); } }, processDetail(data) { // 预处理数据比如把演员列表拼成字符串 const casts (data.casts || []).map(c c.name).join( / ); return { ...data, castsText: casts }; } });预处理数据这个步骤很容易被忽略但实际体验影响很大。原始接口返回的数据结构跟页面展示需求不一定一致比如演员列表、导演列表接口给的是数组页面上要显示成“导演XXX”你就在这个环节拼好不要到WXML里用花括号写复杂逻辑。WXML模板里尽量保持简洁只做数据绑定复杂的数据加工放JS。2.3 星级评分组件的实现评分组件看似简单但里面有个细节豆瓣评分是带小数点的比如8.6分、9.2分用整颗星没法精确表达。我的实现方案是使用半颗星效果具体做法是这样view classstar-rate !-- 底层灰色星星 -- view classstar-layer text classstar★★★★★/text /view !-- 上层高亮星星宽度按分数比例变化 -- view classstar-layer highlight stylewidth: {{percent}}%; overflow: hidden; text classstar★★★★★/text /view /viewComponent({ properties: { score: { type: Number, value: 0 } }, observers: { score(newVal) { // 豆瓣10分制换算成5颗星每颗星占20% const percent Math.round((newVal / 10) * 100); this.setData({ percent }); } } });这个思路很简单底层永远显示五颗灰星上面一层是五颗同样的星但颜色是黄色宽度按percent裁剪就像一把尺子量出多少显示多少。4.3分就是43%宽度视觉上刚好两个多一点的星星。这种方案比用图片或者逐帧判断整数星再补半个星图的方式更精确也更好维护。2.4 搜索页与防抖处理搜索这个功能最大的坑就是过度请求。用户每敲一个字就发起一次搜索请求接口扛不住流量也会大量浪费。常规做法是加防抖debounce。let timer null; function searchMovie(keyword) { clearTimeout(timer); timer setTimeout(async () { if (!keyword) return; const res await request(/api/search?q${encodeURIComponent(keyword)}); this.setData({ results: res.subjects }); }, 300); }300毫秒是权衡后的选择太短没防抖效果太长用户会觉得卡顿。另外搜索关键字要记得encodeURIComponent编码保含中文、特殊字符时不至于把URL弄坏了。搜索结果的展示跟首页列表很相似完全可以复用movie-card组件这就是把组件抽出来带来的直接好处——新页面开发成本被大幅压缩。2.5 收藏功能的本地存储设计收藏功能用微信的wx.getStorageSync和wx.setStorageSync就能实现不需要后端。但这个功能想做好数据结构要提前想清楚。// 存储结构{ movieId: { id: , title: , image: , rating: , createdAt: }, ... } // 每个电影id作为key方便查询和去重 function toggleFavorite(movie) { const favorites wx.getStorageSync(favorites) || {}; if (favorites[movie.id]) { delete favorites[movie.id]; } else { favorites[movie.id] { ...movie, createdAt: Date.now() }; } wx.setStorageSync(favorites, favorites); return !!favorites[movie.id]; }用对象做存储而不是数组理由是查询和去重的复杂度是O(1)。如果用数组每次判断某部电影是否已收藏都要遍历一遍数据多了性能不佳代码也麻烦。收藏页在onShow里读存储并更新页面。注意一定要用onShow而不是onLoad因为从详情页返回收藏页时onLoad不会重新执行但onShow会。这是小程序页面生命周期的一个经典坑。3. 踩坑实录兼容性与交互细节3.1 全局网络异常提示网上有人问“网络不可用的时候怎么全局统一显示网络不可用提示”这个问题的本质是你不想在每个页面的每个请求回调里都写一遍错误处理。我的做法是在请求封装里统一拦截。上面代码里已经做了fail回调里弹出toast。但更好的做法是可以做一个全局的页面状态// utils/request.js function checkNetwork() { return new Promise((resolve) { wx.getNetworkType({ success: (res) { resolve(res.networkType ! none); }, fail: () resolve(true) }); }); }在App启动时监听网络状态变化// app.js App({ onLaunch() { // 监听网络状态变化 wx.onNetworkStatusChange((res) { if (!res.isConnected) { // 断网时通过全局事件通知页面显示网络异常 const pages getCurrentPages(); const currentPage pages[pages.length - 1]; if (currentPage currentPage.showNetworkError) { currentPage.showNetworkError(); } } }); } });这个方案的核心思路是页面不主动感知网络状态而是接收全局事件通知。你在每个页面里封装一个showNetworkError方法断网时调用它切换页面状态展示全屏的网络异常占位图。不过要提醒一点如果要做得更精细网络状态监测最好配合全局状态管理比如用全局变量或观察者模式否则页面多了以后事件通知也容易乱。3.2 自定义导航栏高度适配很多小程序会关闭默认导航栏做自定义导航先把胶囊按钮的位置搞清楚再去算高度。关于顶部导航栏高度网上有一堆文章其实核心就一个公式状态栏高度 wx.getSystemInfoSync().statusBarHeight 导航栏高度 胶囊按钮位置top - 状态栏高度 (胶囊按钮高度 - 胶囊按钮与状态栏的间距) * 2说得更直白一点computeNavBarInfo() { const info wx.getSystemInfoSync(); const rect wx.getMenuButtonBoundingClientRect(); const statusBarHeight info.statusBarHeight; // 导航栏高度通常约等于44pxiPhone X以上因为刘海屏会有差异 const navBarHeight (rect.top - statusBarHeight) * 2 rect.height; this.setData({ statusBarHeight, navBarHeight }); }为什么navBarHeight要这么算因为胶囊按钮在导航栏中的垂直居中位置决定了整个导航栏的高度。胶囊按钮顶部到状态栏底部的距离乘以2再加上胶囊按钮的高度就是导航栏的总高度。不同机型上的胶囊按钮位置会微调所以一定要在运行时动态计算绝不写死44px。3.3 swiper嵌套video全屏错位有开发者遇到“iOS中swiper组件嵌套video组件导致全屏错位”的问题这个bug很典型我也遇到过。出错的场景是在swiper里放多个video点击一个视频全屏播放退出全屏后整个轮播图错乱。问题根因是video组件在小程序里是一个原生组件层级最高跟swiper的滚动手势会有冲突。iOS上全屏切换时原生组件的frame信息更新异常导致显示错位。坑位一能否再问一下视频全屏时能不能隐藏其他视频这个跟具体业务有关如果只是单一视频就推荐不用swiper直接在页面里放video。我推荐的方案是不要在swiper里直接放video而是用视频封面图代替点击封面时才动态渲染video组件。swiper swiper-item wx:for{{videos}} wx:keyindex !-- 未播放时显示封面 -- image wx:if{{!playingIndex index}} src{{item.cover}}>// 保存网络图片到相册 function saveImageToAlbum(url) { return new Promise((resolve, reject) { wx.downloadFile({ url, success: (res) { wx.saveImageToPhotosAlbum({ filePath: res.tempFilePath, success: resolve, fail: (err) { if (err.errMsg.includes(auth deny) || err.errMsg.includes(authorize)) { wx.showModal({ title: 提示, content: 需要您授权相册权限才能保存图片, success: (modalRes) { if (modalRes.confirm) { wx.openSetting(); } } }); } reject(err); } }); }, fail: reject }); }); }另外微信对没有用户点击行为触发的保存经常拦截所以这类操作必须放在按钮的tap事件回调里做不要在网络请求的回调里自动触发。4. 项目打包、部署与分发4.1 微信开发者工具上传流程项目开发完在微信开发者工具里点“上传”填写版本号和备注代码就到了微信后台。然后去mp.weixin.qq.com配置为体验版扫码即可预览。正式发布要在后台提交审核个人主体的小程序审核相对快一些。这里提一个大家常忽略的步骤request合法域名配置。开发时可以在开发者工具里勾选“不校验合法域名”来绕过限制但体验版和正式版必须在后台把用到的接口域名加入“request合法域名”列表否则请求直接失败。前缀必须是https且域名不能带路径参数。4.2 zip打包的正确姿势项目交付或开源分发时通常会把整个工程压缩成zip。打包有几点要注意node_modules目录不打包如果有依赖保留package.json即可别人拉下来后npm install。打包前删掉开发者工具生成的文件如 unpackage目录如果是uni-app、.idea、.vscode等编辑器配置保持工程干净。如果是给别人的源码最好附带一个README写清楚运行步骤、接口地址、AppID配置。# 打包命令示例 zip -r my-movie-app.zip . -x node_modules/* .git/* .idea/* .vscode/*4.3 关于源码保护有热词提到“已经部署的微信小程序怎么能拿到源码”这里我多说两句。小程序打包发布后代码是经过编译混淆的但不要把它想成绝对安全。只要有足够的技术手段前端的逻辑还是可以被逆向分析出来。所以如果你们的项目有敏感逻辑比如密钥、算法一定要放在服务端不要在客户端代码里有任何隐秘逻辑。对于正常的开源项目打包成zip分发时建议在README里标明技术栈、运行环境要求、可能存在的接口限制。这样别人拿到项目后能很快跑起来而不是发消息追问你“怎么报错”。5. 常见问题与排查技巧实录做一个排查速查表可以直接粘贴到你的项目README里也可以拿来当自查清单。问题现象可能原因排查思路与解决办法首页数据加载不出来接口域名未配置到合法域名列表检查mp后台-开发管理-服务器域名确认request合法域名包含接口域名图片加载失败图片域名未配置downloadFile合法域名如果图片是网络链接需要配置为“downloadFile合法域名”保存图片到相册失败网络图片没有先下载先wx.downloadFile再saveImageToPhotosAlbum页面白屏JS报错 或 数据为空打开vConsole查看console错误检查接口返回数据结构是否符合预期真机正常模拟器异常可能是机型兼容问题用真机调试工具查看具体报错堆栈onReachBottom不触发页面没有设置可滚动高度检查页面是否被page容器包裹且页面整体没有overflowhidden限制收藏数据丢失小程序缓存被清除本地存储本来就有生命周期重要数据需要同步后端用户切换账号后数据窜了storage按设备存储不区分账号如果有多账号登录场景存储key里加上用户唯一标识自定义导航栏在不同机型上错位没有动态计算胶囊位置用wx.getMenuButtonBoundingClientRect计算不要把高度写死定位问题的通用心法就一句话先把问题缩小到数据层、渲染层还是交互层。数据层的错误看Network和Console渲染层的错误看WXML渲染结果和样式计算交互层的错误需要自己一遍遍复现操作路径。大多数小程序问题90%都出在数据层——接口返回和预期不一致。还有一个小技巧开发时多利用微信开发者工具的“隔离调试”和“真机调试”两种模式配合使用很多模拟器上无法复现的机型问题真机上一抓一个准。6. 项目扩展思路与个人经验这个项目做完之后后续扩展空间很大。比如接入mpvue做多端复用比如加一个后台管理系统来管理影片数据再比如引入WebSocket做即时互动功能。但如果你是新手我不建议一上来就加这些复杂度先跑通一个完整的闭环——从列表到详情到收藏——比堆功能更重要。另外现在微信小程序生态里个人开发者的流量扶持相对有限但如果这个项目能跑出一个完整的开发流程后面做成“电影推荐”“影单分享”之类的差异化产品定位也不失为一个方向。在接口数据这块要特别提醒豆瓣官方开放接口已经很有限且政策随时可能调整。做学习项目时使用非官方或社区维护的接口要注意合规风险。如果你的项目要长期上线建议自建一个简单的后端服务来代理请求或者使用自己整理的数据文件。这既是法律合规的底线也是技术上对项目可持续性的保障。最后再分享一个小习惯每次开发到一个小里程碑就用git打一个tag比如v0.1.0、v0.2.0。这样你回头改坏了代码能清楚地知道自己是从哪个版本开始动手的。“微信小程序豆瓣电影.zip”这个项目看起来简单但一趟走下来从框架搭建、接口封装、页面联动、组件拆分到打包上线小程序开发的主流知识点基本都覆盖到了。这套流程跑通一遍下一次再做任何小程序项目你都会有底气。本文还有配套的精品资源点击获取