简介:这是一份以微信小程序为载体制作的婚礼邀请函完整项目,适合需要快速上线婚礼请柬的新人、前端爱好者以及正在学习小程序开发的工程师。压缩包内含项目源码、页面配置、云函数和图片素材,可直接导入微信开发者工具预览与二次开发。资源共70个文件,以wxml、wxss、js、json四类小程序核心文件为主,搭配png/jpg等视觉素材和gif动图,整个压缩包仅1.38MB,结构紧凑但覆盖完整开发链路。目前已有2966人学习下载,作为小型项目实例具备较高参考价值。通过该实例可以直观学习微信小程序的页面结构、交互事件、数据绑定以及云数据库的基础用法,还能在现有模板上快速修改主题、嘉宾名单和祝福语,将传统邀请流程转变为在线秀邀请函与确认出席的数字体验,兼顾学习与实用意义。
1. 婚礼邀请函小程序.zip 到手后,先想清楚这三件事
婚礼请柬小程序和普通工具类小程序最大的不同,是它几乎没有后端逻辑,却对页面表现力要求极高。一个 .zip 压缩包里装的通常就是完整的前端工程:pages 目录、app.json、wxml/wxss/js 文件、静态图片和音频。你能看到的是请柬封面、新人照片、滚动相册、地图导航和留言页面,看不到的是音频自动播放策略、地图选点坐标、分享参数拼接这些决定体验的细节。
拿到这类项目压缩包,你需要先确认三件事:工程是原生微信小程序还是 uniapp 构建产物,能否直接用微信开发者工具打开;图片和音频资源是网络地址还是本地打包,涉及域名白名单;有没有依赖云开发或第三方后端,决定你改完代码后能不能跑通完整流程。把这三件事梳理完,再谈改样式和加功能。
2. 拆解婚礼请柬小程序的页面结构与数据流
2.1 邀请函小程序的页面骨架:启动页、请柬主页、相册页、地图页、留言页
一个完整度较高的婚礼邀请函微信小程序,页面结构通常是五页起步。启动页承担品牌展示和资源预加载,请柬主页放婚礼信息和邀请语,相册页用滑动卡片展示新人照片,地图页定位酒店并支持跳转导航,留言页收集亲友祝福。这个结构与一般电商小程序的多 tab 结构完全不同,它的核心是单向浏览动线:从封面到详情,从了解到互动。
页面注册在 app.json 里完成,pages 数组第一个元素就是冷启动加载的页面。我见过不少 zip 项目在这一点上很随意,首页直接写成请柬主页,导致音乐和图片同时加载,弱网下白屏好几秒。正确做法是把启动页放在第一位,onLoad 里做资源预加载,再 redirectTo 到请柬主页。
{ "pages": [ "pages/splash/splash", "pages/invite/invite", "pages/photos/photos", "pages/map/map", "pages/message/message" ], "window": { "navigationBarBackgroundColor": "#f7e8dc", "navigationBarTextStyle": "black", "navigationBarTitleText": "婚礼邀请函", "backgroundColor": "#f7e8dc" }, "requiredPrivateInfos": ["getLocation"], "permission": { "scope.userLocation": { "desc": "用于展示婚礼酒店位置并导航" } } }这段配置里 pages 的顺序决定了页面路由层级,splash 作为第一项就是刚进入小程序时加载的页面。navigationBarTitleText 会在切换页面时被各页面的 json 覆盖,比如地图页可以单独设置标题为“婚礼地址”。requiredPrivateInfos 是微信官方对地理位置接口的强制声明,缺少这一项 getLocation 会直接报错。
2.2 uni-app 还是原生微信小程序:zip 导入方式的差别
zip 包有两种常见来源,一种是用微信开发者工具新建的原生工程,目录下直接能看到 app.js、app.json、project.config.json;另一种是 HBuilderX 里 uniapp 项目编译出来的产物,路径通常是 unpackage/dist/dev/mp-weixin。两者在微信开发者工具里的导入方式完全不同,原生工程直接导入根目录,uniapp 产物导入到 mp-weixin 子目录。
从检索热度看,uniapp 微信小程序在婚礼邀请函这类展示型项目里占比不低,原因是一套代码可以同时输出微信小程序和 H5 网页版请柬。但要注意,uniapp 项目源码本身不能被微信开发者工具识别,你必须先安装 HBuilderX,在菜单栏选择“发行 - 小程序-微信”,让编译器生成 mp-weixin 目录,再把这个目录当作微信小程序项目导入。每次改代码都要回到 HBuilderX 里重新编译,不能直接改 mp-weixin 里的文件,因为下一次编译会覆盖。
如果 zip 里同时有 src 目录和 mp-weixin 目录,说明这是个 uniapp 项目;如果只有 wxml 和 wxss 文件,就是原生小程序。这个判断决定了后面所有的调试路径,也是新手最容易卡住的地方。
2.3 微信小程序项目实例的目录约定:rpx、组件与静态资源
无论哪种工程,页面目录结构都遵循同一套约定。每个页面是一个文件夹,包含同名的 wxml、wxss、js、json 四个文件,json 负责当前页面的窗口表现,js 里写 Page 配置,wxml 决定结构,wxss 控制样式。尺寸单位用 rpx,750rpx 等于屏幕宽度,这样在设计稿和真机之间可以做到等比缩放。
pages/ splash/ splash.wxml splash.wxss splash.js splash.json invite/ invite.wxml invite.wxss invite.js invite.json photos/ photos.wxml photos.wxss photos.js photos.json map/ map.wxml map.wxss map.js map.json message/ message.wxml message.wxss message.js message.json static/images/ 封面背景图、头像、装饰元素 static/audio/ 背景音乐 mp3 utils/ format.wxs、request.js静态资源放 static 目录会被原样打包进 zip 包,图片总大小控制在 2MB 以内是硬指标,超出部分要么压缩要么换 CDN 地址。婚礼请柬里最容易超包的就是原图相册,一张手机照片动不动就是 3MB 以上。常见做法是相册图片全部走网络地址,本地只保留封面小图和图标,这样既减小包体,也让首屏渲染更快。
组件层面,请柬页常用的有 swiper 相册组件、button 的 open-type 分享能力、map 地图组件和 form 表单组件。这些组件都是微信原生能力,不依赖第三方库,这也是婚礼邀请函小程序适合用来做项目实例的原因:功能完整但技术栈收敛,踩坑点集中在资源策略而非框架复杂度。
3. 手写核心页面:音乐播放、相册滑动与地图导航
3.1 背景音乐自动播放的边界:wx.createInnerAudioContext 与用户手势
婚礼请柬的背景音乐几乎是标配,但微信小程序对自动播放有严格限制,开发者工具里能自动响,真机上 iOS 必须先有用户点击交互才能播放音频。常见的做法是启动页放一个“进入请柬”按钮,点击按钮时同时触发 redirectTo 和 audio.play(),让这次点击手势成为音频播放的授权信号。
// pages/splash/splash.js const audio = wx.createInnerAudioContext(); audio.src = 'https://cdn.example.com/wedding/bgm.mp3'; audio.loop = true; audio.volume = 0.6; Page({ enterInvite() { audio.play(); wx.redirectTo({ url: '/pages/invite/invite' }); }, onUnload() { audio.destroy(); } });这里有几个参数值得说明。src 使用的是网络地址,开发者工具模拟器里本地路径也能响,但真机上本地音乐文件容易遇到 iOS 解码兼容问题,mp3 格式选 128kbps 码率最稳。loop 设为 true 保证循环播放,volume 控制在 0.5 到 0.7 之间,避免盖过现场环境音。页面卸载时 destroy 是必须的,否则音频会跨页面继续占用播放通道。
3.2 滚动相册与长按拖拽滚动:swiper 组件的垂直滚动边界
婚礼照片展示最常见的交互是左右滑动查看,swiper 组件天然支持。把 swiper 的 vertical 属性设为 false,每页放一张图,indicator-dots 显示页码指示点,就能得到一个标准的全屏相册。如果追求更精致的体验,可以在 swiper-item 里叠加 scale 动画,让当前页图片略微放大,其他页图片缩小,形成卡片层叠感。
hot word 里提到的“长按拖拽滚动”在婚礼请柬场景里是一个误用重灾区。swiper 本身是固定滑动方向组件,长按拖拽改排序是列表需求,两者不能混用。如果确实需要让用户长按照片后调整顺序,应该用 movable-area 和 movable-view 配合长按事件模拟,但这类交互在请柬里很少用,我在项目中更推荐直接用 swiper 加 lottie 动画过渡,体验更顺滑。
<!-- pages/photos/photos.wxml --> <swiper class="photo-swiper" indicator-dots="{{true}}" indicator-color="rgba(255,255,255,0.4)" indicator-active-color="#ffffff" circular="{{false}}" previous-margin="30rpx" next-margin="30rpx"> <swiper-item wx:for="{{photos}}" wx:key="index"> <image src="{{item.url}}" mode="aspectFill" lazy-load="{{true}}" bindtap="previewPhoto" >// pages/map/map.js openAmap() { const location = { latitude: 31.2304, longitude: 121.4737, name: 'xx婚礼酒店' }; const url = `https://uri.amap.com/navigation?to=${location.longitude},${location.latitude},${encodeURIComponent(location.name)}&mode=car&src=wedding_miniapp`; wx.setClipboardData({ data: url, success: () => { wx.showModal({ title: '提示', content: '已复制高德导航链接,请打开浏览器访问', showCancel: false }); } }); }这段代码用高德 URI API 拼接跳转链接,将经纬度和目的地名称传到系统浏览器,由浏览器唤起高德 App。参数里 to 的格式是“经度,纬度,名称”,顺序不能颠倒;mode 支持 car、walk、bus 三种出行方式,婚礼场景默认 car。复制链接而不是直接用 web-view 打开,是因为微信内嵌浏览器对第三方 App 调起有限制,这种“复制 + 提示”的交互虽然多一步,但兼容性最好。
需要强调的是,苹果手机位置错误大多不是代码问题,而是获取坐标的方式问题。在小程序里获取当前定位用 wx.getLocation,返回的是 wgs84 或 gcj02 坐标,而高德和腾讯地图内部用的是 gcj02。如果拿 wgs84 坐标直接传给 uri.amap.com,目的地会偏移几百米。解决方法是调用 wx.getLocation 时明确传入 isHighAccuracy: true 和 type: 'gcj02',这样拿到的坐标体系与高德一致。
3.4 邀请函表单:单选框、留言提交与后端接口对接
留言页是邀请函少有的交互入口。常见字段有姓名、来宾身份、祝福语,其中“来宾身份”用 radio-group 最合适,让用户选择男方亲友还是女方亲友。留言提交既可以用微信云开发,也可以对接自己的后端接口。zip 包里如果没有云开发配置,默认走的都是 wx.request 到某个 HTTP 接口,这也是热词里“微信小程序的后端用 php 是如何实现的”对应的问题。
<!-- pages/message/message.wxml --> <radio-group class="role-group" bindchange="onRoleChange"> <label class="role-item"> <radio value="bride" checked="{{role === 'bride'}}" color="#d4a574" />新娘亲友 </label> <label class="role-item"> <radio value="groom" checked="{{role === 'groom'}}" color="#d4a574" />新郎亲友 </label> </radio-group> <input class="name-input" placeholder="你的名字" bindinput="onNameInput" /> <textarea class="msg-input" placeholder="写下祝福" bindinput="onMsgInput" maxlength="200" /> <button class="submit-btn" bindtap="submitMessage">送出祝福</button>radio-group 里每个 radio 必须配 label 才能扩大点击区域,checked 手动绑定当前选中值实现受控切换。textarea 的 maxlength 控制留言长度,避免超长文本导致列表页排版崩掉。submitMessage 里把三个字段聚合成对象,通过 wx.request 发到后端,后端校验身份字段合法后写库,再通过订阅消息通知新人查看新留言。这套流程和课程表小程序的提醒逻辑同构,只是触达对象从自己变成了新人。
4. zip 源码的导入、调试与发布:微信开发者工具操作全流程
4.1 正确导入 zip 项目而不是打开文件
拿到 zip 后大多数人会直接双击解压,然后用微信开发者工具的“导入项目”按钮去选择根目录。这里有个容易忽略的细节:如果项目是原生小程序,根目录必须有 project.config.json,开发者工具才能识别 appid 和项目名。导入时工具会让你填 AppID,可以选择测试号,但测试号无法使用订阅消息和大部分开放能力,所以正式开发建议注册自己的小程序账号拿到真实 AppID。
如果你拿到的是 uniapp 工程的 mp-weixin 产物,目录里只有 app.js 和 app.json 而没有 project.config.json,导入时会提示“无法识别”。此时不要强行导入,回到 HBuilderX 里打开源码工程重新编译生成,工具会自动补全 project.config.json。zip 包是可以下载的,微信小程序本地文件目录 wx.env.USER_DATA_PATH 也可以用来存放下载的 zip 文件并解压读取,但这属于程序运行时的文件操作,和开发者工具的导入不是一回事。
4.2 修改刚进入的加载页面与顶部导航栏高度
微信小程序的启动加载页是系统级的,开发者无法自定义那个带 logo 的载入界面,但可以用自己的启动页模拟“刚进入的加载页面”的过程。把 splash 页面作为 pages 数组第一项,里面放一张铺满屏幕的封面图,onLoad 里预取请柬数据和音乐资源,2 秒后 redirectTo 进主页,视觉上就是自定义了冷启动体验。
导航栏的定制是另一个高频需求,热词里的“右上角三个点和圆圈怎么关闭”指的就是胶囊按钮。胶囊按钮不能关闭,但你可以让导航栏消失,把整个页面变成沉浸式。做法是在页面的 json 里设置 navigationStyle 为 custom,然后通过 wx.getMenuButtonBoundingClientRect 拿到胶囊按钮的位置,在页面顶部手动排版自定义标题栏。
{ "navigationStyle": "custom", "navigationBarTextStyle": "white" }设置 custom 后,默认导航栏高度变成 0,页面内容从屏幕顶部开始渲染。此时必须自己计算安全区域:胶囊按钮的底部就是内容区可放置的最高点,顶部 statusBarHeight 可以通过 wx.getSystemInfoSync 获取。这段逻辑建议封装成一个工具函数,所有自定义导航栏页面复用,避免每页重复计算导致上下不一。
4.3 微信小程序登录、订阅消息与分享参数
婚礼邀请函的登录可以做得非常轻,不需要强制授权手机号。常见做法是 wx.login 拿到 code,后端换 openid,把 openid 作为留言身份标识。这样用户进来不需要点任何授权弹窗,体验接近零门槛。如果新人想看谁浏览过请柬,可以加一个 open-data 组件展示用户头像昵称,但不要依赖这个接口做业务主键。
订阅消息是“提醒新人查收祝福”的关键。wx.requestSubscribeMessage 需要用户主动触发,并且一次订阅只能推送一条消息。合理策略是:用户点击“送出祝福”按钮时同时弹出订阅授权,授权成功后留言入库,新人收到新祝福模板消息。注意模板消息的点击跳转路径要指向留言页,否则用户收到通知后落在一个空白首页,转化链路就断了。
wx.requestSubscribeMessage({ tmplIds: ['模板ID_1'], success(res) { if (res['模板ID_1'] === 'accept') { submitMessage(); } } });submitMessage 要放在订阅成功回调里而不是外面,原因在于订阅请求是异步的,直接调用会拿不到授权状态。模板 ID 在小程序后台申请,一个类目对应一套模板,婚庆类目下可以选择“祝福送达通知”等预设模板,也可以自定义模板内容。
4.4 用 Charles 抓包电脑端微信小程序请求
开发者工具里的 Network 面板能看到大部分请求,但真机上的请求问题只有抓包才能定位。charles 抓包电脑端微信小程序和手机端微信小程序的逻辑一致:电脑上安装 Charles,开启 SSL Proxying 并安装根证书,手机和电脑连同一局域网,手机网络设置为电脑 IP 的 HTTP 代理,然后从手机上打开小程序,Charles 里就能看到完整的 HTTPS 请求。
需要说明的是,微信小程序默认要求配置合法域名,开发阶段可以在开发者工具的“详情 – 本地设置”里勾选“不校验合法域名、web-view(业务域名)、TLS 版本以及 HTTPS 证书”。抓包时如果看到请求返回 “fail url not in domain list”,说明域名没配置或校验没关。抓包的价值在于确认接口返回的 JSON 结构,以及图片资源的 CDN 是否生效,而不是绕过任何访问限制,这是安全调试的基础认知。
4.5 实战中容易踩的 4 个坑
| 报错或现象 | 原因 | 处理方式 |
|---|---|---|
| 真机无法播放音乐 | iOS 自动播放限制 | 首次点击时调用 audio.play() |
| 地图位置偏移 300 米 | 坐标类型用了 wgs84 | 改成 gcj02 并开启 isHighAccuracy |
| 图片不显示且 request 失败 | 网络图片域名未配置白名单 | 后台添加 downloadFile 合法域名 |
| 页面底部被遮挡 | 没有适配 iPhone 底部安全区 | 使用 env(safe-area-inset-bottom) |
最后这个底部安全区问题在婚礼请柬里特别明显,因为页面设计普遍是浅色底加大按钮,iPhone 的 Home Indicator 会压在“送出祝福”按钮上。处理方式在 wxss 里给按钮加一个 padding-bottom: calc(30rpx + env(safe-area-inset-bottom)),让背景延伸进安全区,按钮主体浮在安全区上方。
5. 让邀请函更显质感的三个进阶技巧
5.1 用 webview 与 H5 页面通信扩展互动玩法
uni-app 微信小程序 webview 如何像 H5 通信,是很多人在邀请函里做互动页面的核心诉求。场景是:请柬主流程是原生小程序,但新人的恋爱故事是一个动态 H5 页面,需要从小程序传入新人名字,H5 再把用户的祝福带回小程序。这个场景用 web-view 组件承载 H5,用 postMessage 完成双向传递。
web-view 唯一的小程序向 H5 传参方式是把参数拼接在 src 后面,比如 https://h5.example.com/story?name=张明%26莉莉。H5 拿到参数后渲染页面,需要把数据传回小程序时,调用 wx.miniProgram.postMessage,小程序端通过 bindmessage 事件接收。注意 postMessage 的消息在特定时机才能触发,比如页面分享或后退时才会派发,实时性要求高的场景要配合 URL 参数轮询来做补偿。
5.2 防止照片被一键提取:图片防盗链与反编译的边界
微信小程序一键反编译下载是真实存在的风险,代码包可以被解密拉取,图片资源也能被爬虫批量抓取。婚礼照片属于私人信息,必须做基础防护。最有效的手段是照片不走静态 CDN,而是通过接口鉴权后返回临时签名 URL,签名带过期时间,过期后图片不可访问。
// 获取带签名的照片列表 wx.request({ url: 'https://api.example.com/photos', header: { authorization: 'Bearer ' + token }, success(res) { this.setData({ photos: res.data.map(item => { return { ...item, url: item.signedUrl // 已拼接过期参数 }; }) }); } });这里的要点是签名 URL 由后端生成,绑定当前用户身份和过期时间,前端拿到的地址即使被提取,别人直接访问也无权限。二次防御是给图片加透明度水印,即使截图传播也有归属标识。反编译拿到前端代码是无法绕过签名鉴权的,因为密钥不在前端,这也是“前端可破解、安全靠后端”这句话在实践中的体现。
5.3 weixin://dl/business 链接从生成到触发的全流程避坑
如果要把邀请函发到短信或微信外部渠道,生成一个 weixin://dl/business 链接是最常见的跳转方案。这类链接可以从生成到触发形成完整闭环:在微信公众平台后台或者通过服务端接口生成带 path 和 query 参数的链接,把链接嵌入短信、邮件或二维码。用户点击后先拉起微信,微信内部校验合法性,再跳转到指定小程序页面,整个过程微信会弹一个中间确认页,这是系统行为,无法去掉。
生成链接时要特别注意 path 参数必须和 app.json 里注册的页面完全一致,query 里的中文参数要 encodeURIComponent,否则跳转后页面读取到乱码。触发链路里最常见的失败是链接生成后修改了页面路径或删除了参数,导致用户点击后白屏。排查方式是打开开发者工具的“普通链接二维码”模拟测试,把链接贴进去看是否命中正确的页面和参数。
最后给一个检验跳转数据是否生效的小技巧:在目标页面的 onLoad 里打印 options,用微信扫一扫打开生成的二维码,真机上观察 console 输出的 path 参数。这一行输出能验证从生成、触达到解析的全链路是否通畅,比反复点短信链接高效得多。做完这步,邀请函的投放闭环就完整了。
本文还有配套的精品资源,点击获取