微信小程序婚礼请柬源码：电子请柬、流程管理与座位查询完整实现

简介：这份资源是一套可直接运行的微信小程序婚礼项目源码，面向想快速搭建线上婚礼页面、学习小程序开发的初学者与个人开发者，帮助解决从零搭建电子喜帖、祝福互动与婚礼信息展示的难题。压缩包共43个文件，约5.69MB，以png、jpg图片与gif动图作为视觉素材，配合js逻辑脚本、json配置、wxml页面结构与wxss样式文件，另有mp4视频用于婚礼影像展示，整体构成完整的小程序工程目录。目前已有4855人学习下载，说明其参考价值受到一定认可。项目覆盖欢迎页、新人介绍、祝福墙、电子喜帖、视频播放、地图导航与宾客信息等模块，读者可据此理解页面结构组织、数据交互与音视频嵌入的实现方式，并在此基础上替换图片、文案与配色，快速改造成个性化婚礼小程序，也可作为小程序入门练手案例。

1. 婚礼小程序：一份能直接跑起来的请柬与流程管理源码

朋友婚礼前一周，新郎在群里发了个二维码，扫码进去是电子请柬、婚礼流程、地图导航、座位查询，还能在线留言祝福。当时我以为他花钱买了模板，结果他说是自己改的源码，核心就是一个微信小程序。这件事让我意识到，婚礼类小程序的需求其实很集中：请柬展示、时间地点、流程安排、宾客互动，功能不复杂，但自己从零写一遍也要折腾好几天。这份婚礼小程序源码就是把这些高频功能打包好了，适合准备结婚的开发者自己改，也适合想练手小程序完整项目的新手拿来拆。它不依赖后端服务也能跑起来，数据先写在前端配置里，改起来门槛低，下面按「能干什么、怎么跑、怎么改」的顺序拆一遍。

2. 项目定位与技术选型：为什么用原生小程序而不是框架

2.1 这个项目解决的是什么场景问题

婚礼类小程序的使用周期很短，通常从发请柬到婚礼结束也就一两个月，但它对「打开速度」和「分享传播」的要求很高。宾客大多是通过微信群或朋友圈点进来，网络环境参差不齐，如果首屏加载慢，很多人直接就退了。这份源码选择微信小程序原生开发，而不是用跨端框架再编译，核心考虑就是包体积和启动速度。原生小程序的逻辑层和视图层分离，页面按需加载，首屏只加载请柬页需要的资源，对婚礼这种「一次性高并发分享」的场景比较友好。

从功能范围看，项目覆盖了婚礼小程序最常见的几个模块：电子请柬首页、婚礼流程时间轴、酒店地图与导航、宾客祝福留言、以及一个简单的座位或桌号查询。这些模块之间耦合度低，每个页面基本独立，改一个页面不会影响其他页面，这对二次开发很友好。你完全可以把不需要的页面删掉，只保留请柬和地图，包体积还能再小一圈。

2.2 技术栈与目录结构

项目用的是微信小程序原生技术栈，没有引入第三方 UI 库，样式全部手写 WXSS，好处是依赖少、编译快，坏处是组件复用要靠自己抽。数据层没有接云开发，也没有接自建后端，而是把婚礼信息、流程、座位数据放在一个统一的配置模块里，页面通过require引入。这种做法的取舍很明确：婚礼信息在筹备期会反复改，放在前端配置里改完重新上传即可，不需要维护服务器；缺点是祝福留言这类需要持久化的数据只能先存本地缓存，或者后续自己接云开发。

目录结构大致如下，这是原生小程序的标准布局，熟悉小程序的读者一眼就能对上：

wedding-miniprogram/ ├── app.js # 全局逻辑，初始化缓存 ├── app.json # 页面注册、窗口配置 ├── app.wxss # 全局样式变量 ├── config/ │ └── wedding.js # 婚礼信息、流程、座位数据配置 ├── pages/ │ ├── invite/ # 电子请柬首页 │ ├── schedule/ # 婚礼流程时间轴 │ ├── map/ # 酒店地图与导航 │ ├── blessing/ # 祝福留言 │ └── seat/ # 座位查询 ├── components/ │ └── timeline/ # 时间轴自定义组件 └── utils/ └── format.js # 日期格式化等工具函数

config/wedding.js是整个项目的数据中心，改婚礼信息基本只动这一个文件。pages下每个目录对应一个页面，页面内的.js管逻辑、.wxml管结构、.wxss管样式、.json管页面级配置。components/timeline是把流程时间轴抽出来的自定义组件，因为流程页和请柬页都可能用到时间轴展示，抽组件避免重复写。utils/format.js放一些纯函数，比如把2024-05-20 12:00格式化成「5月20日 中午12点」这种更适合请柬展示的写法。

提示：如果你打算接云开发存祝福留言，建议新建一个cloudfunctions目录，不要直接改pages/blessing里的逻辑，保持页面层和数据层分离，后面换存储方案时改动面更小。

3. 跑起来：从导入项目到真机预览的完整步骤

3.1 环境准备与项目导入

跑这个项目只需要微信开发者工具，不需要 Node 环境，也不需要装依赖，因为项目没有 npm 包。下载源码后解压，打开微信开发者工具，选择「导入项目」，目录指向解压后的根目录，AppID 填你自己的小程序 AppID，如果没有可以先选「测试号」。测试号能跑大部分功能，但真机预览和分享相关的能力会受限，正式调试建议还是注册一个个人小程序账号。

导入后工具会自动编译，如果app.json里注册的页面路径和实际目录对不上，控制台会直接报「page not found」，这时候检查app.json的pages数组，第一项必须是启动页，通常就是pages/invite/invite。项目默认没有配置tabBar，所有页面跳转靠navigateTo，这样请柬页可以作为唯一入口，符合婚礼小程序「一个链接发出去」的使用习惯。

3.2 修改婚礼基础信息

跑通之前先把config/wedding.js里的占位信息换成自己的，否则页面显示的是示例数据。这个文件导出一个对象，结构大致如下：

// config/wedding.js module.exports = { // 新人信息，请柬首页展示 couple: { groom: '张先生', bride: '李女士', weddingDate: '2024-05-20 12:00', avatar: '/assets/avatar.jpg' }, // 酒店信息，地图页使用 venue: { name: '某酒店宴会厅', address: '某市某区某路 88 号', latitude: 31.2304, longitude: 121.4737 }, // 婚礼流程，时间轴组件消费 schedule: [ { time: '11:00', title: '宾客签到', desc: '一楼大厅签到台' }, { time: '12:00', title: '婚礼仪式', desc: '宴会厅主舞台' }, { time: '12:30', title: '午宴开始', desc: '按桌号入座' } ], // 座位数据，key 为宾客姓名，value 为桌号 seats: { '王先生': '3 号桌', '赵女士': '5 号桌' } }

couple.weddingDate用的是标准日期字符串，utils/format.js里会解析它并转成中文展示，改的时候保持YYYY-MM-DD HH:mm格式，否则格式化函数会返回原始字符串。venue.latitude和longitude是地图页wx.openLocation需要的参数，直接从高德或腾讯地图拾取坐标填进去即可，注意小程序用的是 GCJ-02 坐标系，别填成 WGS-84，否则导航会偏几十米。seats用姓名做 key 是为了座位查询页做精确匹配，如果宾客重名多，可以改成手机号后四位做 key，查询页的输入框提示文案也要跟着改。

3.3 真机预览与分享配置

在开发者工具里点「预览」生成二维码，用微信扫码就能在手机上打开。婚礼请柬通常要通过分享传播，所以pages/invite/invite.js里需要配置onShareAppMessage，否则右上角菜单里的「转发」是灰的。分享标题和封面图建议在页面里动态拼，比如带上新人名字，比默认的小程序名称更有辨识度。

// pages/invite/invite.js const wedding = require('../../config/wedding') Page({ data: { couple: {} }, onLoad() { // 把配置注入页面数据，WXML 里直接绑定 this.setData({ couple: wedding.couple }) }, onShareAppMessage() { return { title: `${wedding.couple.groom} & ${wedding.couple.bride} 的婚礼邀请`, path: '/pages/invite/invite', imageUrl: '/assets/share-cover.jpg' } } })

onShareAppMessage返回的path决定了别人点开分享卡片落在哪个页面，这里固定指向请柬首页，保证任何入口进来都是完整请柬。imageUrl建议用 5:4 的图，尺寸不对会被裁剪。如果想让分享卡片带上自定义参数，比如区分不同渠道，可以在path后面拼 query，然后在onLoad(options)里读取，但婚礼场景一般用不上，保持简单就好。

4. 核心模块拆解：请柬、时间轴与地图导航的实现细节

4.1 请柬首页的布局与数据绑定

请柬首页是整个项目的门面，结构上分三块：顶部新人头像和姓名、中间婚礼日期倒计时、底部跳转按钮组。WXML 用wx:if控制倒计时只在婚礼日期未到时显示，避免婚礼结束后还显示「还有 0 天」的尴尬。倒计时的计算放在onLoad里做一次，不需要实时刷新，因为婚礼请柬没人会盯着看秒数变化。

<!-- pages/invite/invite.wxml --> <view class="invite-header"> <image class="avatar" src="{{couple.avatar}}" mode="aspectFill" /> <view class="names">{{couple.groom}} & {{couple.bride}}</view> </view> <view class="countdown" wx:if="{{daysLeft > 0}}"> 距离婚礼还有 <text class="num">{{daysLeft}}</text> 天 </view> <view class="actions"> <button bindtap="goSchedule">查看流程</button> <button bindtap="goMap">酒店导航</button> <button bindtap="goBlessing">送上祝福</button> </view>

daysLeft在 JS 里用婚礼时间戳减去当前时间戳再除以一天的毫秒数，取整得到天数。这里有个细节：如果婚礼是当天中午，早上打开时daysLeft会是 0，wx:if判断> 0就不显示了，符合预期。按钮组用bindtap绑定跳转方法，方法里统一用wx.navigateTo，页面栈深度控制在 5 层以内，婚礼小程序页面少，不会触发栈上限。

4.2 时间轴组件的属性设计

流程时间轴抽成了自定义组件components/timeline，组件只负责渲染，数据通过 properties 传入，这样流程页和请柬页可以复用同一套展示逻辑。组件的 properties 设计成接收一个数组，每项包含time、title、desc，组件内部用wx:for渲染，左侧圆点和竖线用伪元素画，不额外引入图标资源。

// components/timeline/timeline.js Component({ properties: { // 流程数据，结构 [{ time, title, desc }] items: { type: Array, value: [] } } })

<!-- components/timeline/timeline.wxml --> <view class="timeline"> <view class="timeline-item" wx:for="{{items}}" wx:key="time"> <view class="dot"></view> <view class="content"> <view class="time">{{item.time}}</view> <view class="title">{{item.title}}</view> <view class="desc">{{item.desc}}</view> </view> </view> </view>

wx:key="time"用时间做 key，因为同一场婚礼流程时间不会重复，比用 index 更稳，列表更新时不会错位。组件的样式写在timeline.wxss里，默认样式作用域是隔离的，父页面想覆盖圆点颜色需要通过externalClasses或者直接改组件样式，项目里没做主题定制，改颜色直接改组件 wxss 最省事。如果流程项很多，比如超过 10 条，建议在组件里加个折叠，默认只展示前 5 条，点「展开全部」再看，避免请柬页被撑得太长。

4.3 地图导航与座位查询的落地写法

地图页的核心是调起微信内置地图，用wx.openLocation传入经纬度和名称，用户点一下就能跳转到地图 App 导航。这个 API 不需要引入地图 SDK，也不需要配置域名，是婚礼小程序里性价比最高的导航方案。座位查询页则是一个输入框加一个结果展示，输入姓名后从config/wedding.js的seats对象里查，查到就显示桌号，查不到给个友好提示。

// pages/map/map.js const wedding = require('../../config/wedding') Page({ openMap() { const { latitude, longitude, name, address } = wedding.venue wx.openLocation({ latitude, longitude, name, address, scale: 18 // 缩放级别，18 适合看清酒店门口 }) } })

// pages/seat/seat.js const wedding = require('../../config/wedding') Page({ data: { keyword: '', result: '' }, onInput(e) { this.setData({ keyword: e.detail.value.trim() }) }, query() { const seat = wedding.seats[this.data.keyword] this.setData({ result: seat ? `您的座位是：${seat}` : '未查询到座位，请联系签到台' }) } })

wx.openLocation的scale参数控制地图缩放，18 是街道级别，能看清酒店入口，填太大反而看不到周边参照物。座位查询用对象直接取值，时间复杂度 O(1)，宾客数量在几百人以内完全够用。如果座位数据量大到上千条，可以考虑改成数组加find，但婚礼场景没必要过度设计。查询结果里「未查询到」的文案要写得温和，别让宾客以为是自己名字打错了，引导去签到台人工核对更稳妥。

5. 避坑与常见问题：上线前容易翻车的几个点

5.1 图片资源过大导致首屏白屏

现象是扫码打开请柬页，头像和背景图要等两三秒才出来，弱网下甚至一直白屏。原因是assets目录里的图片直接用了相机原图，单张好几 MB，小程序包体积上限是 2MB，超了要么传不上去，要么首屏加载极慢。解决办法是把请柬用图统一压到 200KB 以内，头像裁成正方形 200x200，背景图用 WebP 或者高质量 JPG，压缩工具用常见的图片压缩站点就行。血泪经验是别等到上传时才看包体积，开发阶段就在开发者工具「详情」里盯着包大小，超过 1.5MB 就开始压。

5.2 分享卡片不显示自定义封面

现象是转发出去的小程序卡片还是默认灰色图标，imageUrl配了也不生效。原因通常是图片路径写成了网络地址，或者图片尺寸比例不对被微信裁掉。onShareAppMessage的imageUrl只支持本地路径或已配置的合法域名，婚礼项目一般用本地图，路径从根目录写起，比如/assets/share-cover.jpg，别写成相对路径../../assets/...。另外图片建议 5:4，小于 32KB 更容易加载出来。

5.3 地图导航坐标偏移

现象是点导航后地图定位到酒店隔壁街区。原因是填的经纬度是 WGS-84 坐标系，而wx.openLocation需要 GCJ-02。从国内地图平台拾取的坐标一般是 GCJ-02，直接填没问题；如果是从 GPS 设备或某些开源地图拿的坐标，需要先做坐标转换。排查方法是把经纬度贴到地图平台的反查工具里看落点，偏了就换坐标系重新拾取，别硬调数值。

5.4 祝福留言刷新后丢失

现象是宾客留言后能看到，退出再进就没了。原因是留言只存在页面data里，没有持久化。项目默认用wx.setStorageSync存本地缓存，但本地缓存只存在当前用户手机上，换个人看还是空的。如果只是自己婚礼用、不要求所有人看到彼此的祝福，本地缓存够用；如果要公开展示，就得接云开发数据库，在pages/blessing里把读写换成云函数调用，注意云开发需要在小程序后台开通，且要处理并发写入的权限问题。

5.5 页面路径大小写不一致

现象是开发者工具里能跑，真机预览点按钮跳转报错。原因是app.json里注册的路径和实际目录大小写不一致，Windows 文件系统不区分大小写，工具不报错，但真机是区分大小写的。排查方法是把app.json的pages数组和navigateTo里的 url 逐条对一遍，统一用小写加中划线命名，比如pages/blessing/blessing，别混用驼峰。

6. 二次开发：把通用模板改成自己婚礼的专属请柬

拿到这份源码后，最省力的改法是「先删后加」：把pages下用不上的页面删掉，同步删app.json里的注册项和请柬页的跳转按钮，包体积立刻降下来。然后改config/wedding.js的数据，这一步能覆盖 80% 的定制需求。真正需要写代码的地方通常是三块：请柬视觉、互动玩法、数据持久化。

视觉上，请柬页的配色集中在app.wxss的 CSS 变量里，把主色改成婚礼主题色，圆点、按钮、倒计时数字会一起变，不用逐个页面改。互动玩法可以加一个「祝福墙」，把pages/blessing的本地缓存改成云开发集合，读的时候按时间倒序取前 50 条，写的时候加一个openid去重，防止同一个人刷屏。数据持久化如果不想开云开发，也可以用一个简单的表格服务做中转，但要注意小程序请求域名必须在小程序后台配置，否则真机请求会被拦截。

验证方法很直接：改完数据后先在开发者工具里把「不校验合法域名」关掉，模拟真实网络环境跑一遍，再真机预览走一遍完整链路——扫码进请柬、点流程、点导航、留言、查座位。我一般会在婚礼前一周把二维码发给两三个朋友，让他们用自己的手机走一遍，重点看弱网下首屏多久出来、分享卡片长什么样，这两点是自己测试时最容易忽略的。从那以后我每次交付这类短周期小程序，都强制让非开发的朋友先扫一遍，他们遇到的卡点往往才是真实宾客会遇到的。希望这份拆解能帮你少走点弯路，把请柬顺顺利利发出去。

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