简介这份资源是一套可直接运行的微信小程序婚礼项目源码面向想快速搭建线上婚礼页面、学习小程序开发的初学者与个人开发者帮助解决从零搭建电子喜帖、祝福互动与婚礼信息展示的难题。压缩包共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 classinvite-header image classavatar src{{couple.avatar}} modeaspectFill / view classnames{{couple.groom}} {{couple.bride}}/view /view view classcountdown wx:if{{daysLeft 0}} 距离婚礼还有 text classnum{{daysLeft}}/text 天 /view view classactions button bindtapgoSchedule查看流程/button button bindtapgoMap酒店导航/button button bindtapgoBlessing送上祝福/button /viewdaysLeft在 JS 里用婚礼时间戳减去当前时间戳再除以一天的毫秒数取整得到天数。这里有个细节如果婚礼是当天中午早上打开时daysLeft会是 0wx: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 classtimeline view classtimeline-item wx:for{{items}} wx:keytime view classdot/view view classcontent view classtime{{item.time}}/view view classtitle{{item.title}}/view view classdesc{{item.desc}}/view /view /view /viewwx:keytime用时间做 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去重防止同一个人刷屏。数据持久化如果不想开云开发也可以用一个简单的表格服务做中转但要注意小程序请求域名必须在小程序后台配置否则真机请求会被拦截。验证方法很直接改完数据后先在开发者工具里把「不校验合法域名」关掉模拟真实网络环境跑一遍再真机预览走一遍完整链路——扫码进请柬、点流程、点导航、留言、查座位。我一般会在婚礼前一周把二维码发给两三个朋友让他们用自己的手机走一遍重点看弱网下首屏多久出来、分享卡片长什么样这两点是自己测试时最容易忽略的。从那以后我每次交付这类短周期小程序都强制让非开发的朋友先扫一遍他们遇到的卡点往往才是真实宾客会遇到的。希望这份拆解能帮你少走点弯路把请柬顺顺利利发出去。本文还有配套的精品资源点击获取
_kaic)
