婚礼请柬小程序全栈源码：前后端+数据库设计实战-平芜编程栈

简介：这是一套开箱即用的婚礼请柬邀请函微信小程序完整源码，面向前端开发者、全栈初学者及婚庆类轻应用创业者，解决电子请柬快速定制、后台管理与多端分发的核心需求。资源包含后台管理系统、小程序前端页面及配套数据库，覆盖模板配置、用户认证、通知推送与响应式适配等生产级功能。压缩包共1136个文件，以307个Java后端逻辑文件、175个XML配置与布局文件、143个JS交互脚本、155个HTML/WXML页面结构及31个WXSS样式文件为主干，辅以PNG/GIF图片资源、JSON配置与SQL建表语句，整体体积7.78MB，结构清晰、模块解耦。已有508人学习下载，可直接部署运行，获得含管理员后台、新人编辑界面、宾客H5预览页及微信消息提醒在内的全流程实现方案，特别适合理解小程序前后端协同开发范式与婚庆SaaS类轻应用架构设计。做婚礼请柬小程序这个需求，我前后给朋友和客户做过几版，从最开始只是把图片和文字堆到一个H5页面里，到后来做成现在这套“婚礼请柬邀请函小程序源码（后台+前端+数据库）”的完整闭环，中间踩过的坑、改过的结构还挺多的。今天干脆把这套源码拆开，从项目定位、技术选型、前端页面、后台管理、数据库设计一路讲到部署上线和问题排查。如果你正准备用这套代码自己改一版，或者给客户交一套能直接用的婚礼邀请函产品，这篇内容应该能帮你省下不少摸索时间。

先把这个项目说清楚：它不是一个单纯的展示页面，而是小程序端、管理后台、服务端接口、数据存储四个部分一起跑的完整系统。新人点开你发的微信小程序链接，看到的是请柬封面、婚宴信息、婚礼地点导航、祝福墙、回执登记这些页面；你和策划团队打开管理后台，能改请柬上的日期和地址、看到谁回复了“到场”、统计总人数和桌数、导出一份宾客名单Excel。前后端的数据通过接口串起来，所有信息最终落到数据库里。这套结构适合三种人参考：一是想省外包费、自己动手做婚礼请柬的新人，二是接婚庆类小程序单子的开发，三是想练手全栈项目、把前端面试里那些接口规范和数据设计落到实处的学习者。

1. 项目定位与整体架构

1.1 先搞清楚：为什么请柬还需要一个后台

很多人第一次接触婚礼请柬的“源码”，想的是“不就是一个HTML页面吗，做完发个链接不就完了”。这个理解放在三五年前还能成立，放在现在不行。真实婚礼场景里有几个硬需求是静态页面解决不了的。

第一个是信息变更。婚礼日期改了、酒店换了、接亲时间提前了，这些信息在请柬发出之后随时可能要改。静态页面改一次要重新打包、重新上传、重新发链接；有后台的话，我只需要在管理端改一条数据，所有用户重新进入小程序时拿到就是新内容。

第二个是数据回收。请柬不只是你看我，我还要看你的反馈。谁来、来几个人、带不带小孩、有没有忌口，这些东西光靠一句“请在评论区回复”根本不可靠，必须有一个表单提交到后端，存进数据库，后台再按条件统计。

第三个是互动记录。祝福墙、电子相册、婚礼倒计时这些模块看起来是“锦上添花”，但如果只有前端展示，后台看不到任何用户行为，那这个项目的复购和口碑就撑不起来。做了后台之后，你能看到多少人打开了请柬、多少人填了回执、多少人留了祝福，这些数据对婚庆策划团队来说非常值钱。

所以一套完整的婚礼请柬小程序源码，核心就是“前端展示 + 后端服务 + 数据存储”三个环节都齐全，缺哪个都会在真实使用中露馅。

1.2 技术选型：原生小程序还是跨端框架

我在不同版本里试过好几种方案，这里直接说结论。

前端选型上，婚礼请柬这种页面复杂度不高、交互不算深、生命周期又很短（婚礼结束基本就不更新了）的项目，原生微信小程序就够了。用 WXML + WXSS + JavaScript 写，不用引入 uni-app 或者 Taro 这类跨端框架。虽然跨端框架能让你以后多端发布，但代价是构建链路变长、调试复杂度上升、小程序性能也有轻微损耗。为一个短期项目背这个成本不划算。如果你的需求是以后还要做婚庆公司的系列产品、要同时出支付宝小程序和抖音小程序，那再考虑 uni-app 也不迟。

后端选型上，第一版我用的 Node.js + Express，后来在另一个项目里换成了 Java + Spring Boot，PHP 版也帮人维护过。我个人的建议是：如果你自己维护，Node.js 足够，生态成熟、写接口快、社区资料多；如果这个项目要交给团队长期维护，那 Spring Boot 虽然重一点，但结构更规范，后端人手好招。无论如何，不建议为了省事把逻辑全部写在小程序前端，然后直接操作数据库。那种“野路子”只在个人练习里能跑，一上真实婚礼场景就崩。

数据库方面，MySQL 是首选，免费、稳定、好备份。数据量小不代表不需要数据库设计，后面我会单独讲表结构怎么建。如果不想自己买服务器维护数据库，用微信云开发的云数据库也行，但你会失去一部分可控性，比如自定义索引、跨表查询、数据导出这类操作会受限。

管理后台这块，我建议单独做一个 Web 页面，而不是塞进小程序里。原因很简单：你不可能用手机小程序去批量改300个宾客的回执状态，管理操作必须在 PC 浏览器上做。后台页面用 Vue 或 React 都行，不挑技术栈，重点是功能完整、接口对得上。

1.3 源码目录结构应该怎么组织

一套能真正跑起来的婚礼请柬项目，代码目录至少要分成三块。我贴一个我常用的结构，你可以直接照着建：

wedding-invitation/ ├── miniprogram/ # 小程序前端 │ ├── pages/ │ │ ├── index/ # 请柬首页：封面、日期、名字 │ │ ├── story/ # 爱情故事和时间线 │ │ ├── info/ # 婚宴信息、地图导航 │ │ ├── bless/ # 祝福留言墙 │ │ └── rsvp/ # 回执表单 │ ├── components/ # 公共组件（倒计时、音乐开关等） │ ├── utils/ │ │ ├── request.js # 封装 wx.request │ │ └── config.js # 接口域名配置 │ └── app.json ├── admin/ # Web 管理后台 │ ├── src/ │ │ ├── views/ │ │ │ ├── login/ │ │ │ ├── dashboard/ # 统计面板 │ │ │ ├── guest/ # 宾客回执管理 │ │ │ ├── bless/ # 祝福内容管理 │ │ │ └── setting/ # 请柬内容设置 │ │ └── api/ # 接口请求封装 ├── server/ # 后端服务 │ ├── controllers/ # 控制器层 │ ├── services/ # 业务逻辑层 │ ├── models/ # 数据模型 │ ├── routes/ # 路由 │ └── sql/ │ └── init.sql # 建表脚本 └── docs/ # 部署文档

这个目录的核心思想是前后端分离。miniprogram是小程序端，admin是管理后台，server是接口服务，三者之间只靠 HTTP 接口通信。这样改前端不会动后端，改后台不影响小程序，中间任何环节出了问题，排查范围都清晰得多。

有一点要提醒：很多人拿到源码之后，第一件事是急着把代码跑起来，然后就开始改样式。我建议你先花30分钟把目录结构和数据表关系看懂，后面动手改的时候会快很多。你以后再换一个同类项目，也能速读结构。

2. 前端核心模块实现

2.1 请柬首页的视觉设计

首页是整套请柬的脸面，宾客点开小程序看到的第一个画面，基本决定了这个请柬“值多少钱”。我在做首页时，给出的结构是“一屏完整呈现场景标题 + 向下滚动进入正文”。顶部是全屏的婚纱照封面，中间是“新郎 & 新娘”的名字，底部放婚礼日期和一个“打开请柬”的按钮或向上滑动的提示，点击后平滑过渡到详情页。

说几个实操细节。第一，首屏图片不要直接引用本地文件，更不要用后端接口每次动态拉取，放在图床或者 CDN 上，页面加载会快很多。第二，首屏背景图尺寸至少按 750x1000 像素设计，避免在大屏机型上拉伸模糊。第三，可以加一个背景音乐开关，默认自动播放当前微信版本可能被拦截，所以建议做成“点击播放”而不是“自动播放”，否则用户在婚礼现场公共场合点开，突然放歌会很尴尬，这个体验细节很容易被忽略。

页面结构上，我的建议是首页用scroll-view做整页滚动，而不是多个页面跳转。因为请柬是一个长页面叙事，从上往下依次是封面、婚礼信息、照片、地图、祝福、回执入口，用户往下滑就自然走完整个流程。跳转页面反而打断了情感节奏。滚动到每个部分用scroll-into-view或IntersectionObserver做进场动画，比如标题淡入、图片上浮、卡片展开，都是低成本高感知的动效。

这部分如果你用的是现成源码，改动重点就两个：图片换成真实婚礼素材、把标题文案和日期改对。但千万不要忽略首屏性能，婚礼请柬会发到几百人的微信群，很多人是在手机流量下打开的，首屏超过3秒基本就被划走了。

2.2 婚宴信息、地图导航与场地指引

婚宴信息页是最容易做又最容易被忽略的模块。我见过不少请柬，写了酒店名字就完了，结果宾客到了酒店门口找不到宴会厅。所以这个模块我固定放四个元素：婚礼地点名称、详细地址、宴会厅/楼层信息、地图导航按钮。

地图导航有两条实现路线。第一种是用小程序自带能力，页面上放一个按钮，点击跳转地图 App。代码很简单，核心就是wx.openLocation，传入经纬度和地点名。经纬度怎么来？你可以在腾讯位置服务里选好婚礼酒店，拿到精确经纬度填进去。这个方法的好处是没有页面渲染负担、不需要引入额外地图组件。

第二种是在请柬内直接内嵌一个地图小窗口，用map组件渲染。它的优点是用户在请柬内就能看到位置，不用跳出去。缺点是 map 组件在部分低端安卓机上会出现卡顿，而且需要你申请地图服务的 key。如果你只是做一场婚礼，我建议用第一种，简单可靠；如果是给婚庆公司做长期产品，可以两种都做，在小程序里加一个“预览地图”开关。

做这一块时有一个高频细节：文案上不要只写“XX酒店”，要写清楚“XX市XX区XX路XX号 + 宴会厅名称 + 停车动线”。宾客里面一定有外地来的朋友，地址写得越具体，你婚礼当天接到的问路电话就越少。

2.3 回执表单与数据提交

回执模块是后台和数据库价值体现最直接的地方。它的典型字段是：姓名、联系电话、是否到场（单选框）、随行人数（选择器或输入框）、备注（说明忌口或需要帮助的事）。

这里说一个和热搜词“微信小程序单选框”相关的实操经验。小程序的radio-group+radio做是否到场是够用的，但要注意radio的value是字符串，不是布尔值。很多人写value="{{true}}"，提交后拿到的是字符串"true"，后端强转容易出错。另外每个radio外层包一层label，可以扩大点击区域，移动端体验会好很多。

更重要的一点是回执提交时的防重处理。婚礼请柬发出去之后，很多人会重复打开、多次点击“提交”。如果后端不做防重，数据库里会出现同一个人多条记录，统计人数的时候直接翻倍。我采用的做法是“前端本地标记 + 后端唯一索引”双保险。前端提交成功后把“已提交”状态存到本地缓存，页面再次打开就显示“您已填写回执”；后端在 guest 表上给phone + wedding_id建联合唯一索引，就算有人绕过前端直接调接口，也没办法重复插入。这个双保险在真实婚礼里帮过大忙，有个朋友发了500份请柬，后台统计到场人数比现场备桌数少了几桌，查了下就是重复提交导致的数据失真。

表单校验也要做。最简单的办法是在提交前判断姓名是否为空、手机号是否11位、手机号格式是否合理，不要把校验依赖后端，那样会多一次网络往返，用户在信号不好的酒店里等几秒就容易放弃。

2.4 祝福墙与分享逻辑

祝福墙在功能上就是一个“列表展示 + 发布”的组合。游客打开祝福模块，能看到所有已审核通过的祝福语；提交祝福时填昵称（或微信授权昵称）、头像、祝福内容，提交到后端，管理员在后台审核后公开显示。有人问为什么要审核，原因很简单，婚礼请柬是会转发到各种群里的，不做审核的话，祝福墙很容易被乱发内容的陌生人污染，婚礼当天在大屏上展示时出现意外的内容，场面会很尴尬。

关于头像昵称，微信早年可以直接通过wx.getUserInfo拿到用户头像和昵称，后来规则改了，现在默认拿到的是“微信用户”和灰色默认头像。所以在表单里，我建议干脆让用户自己填昵称，或者放一个“使用微信头像昵称”的主动授权按钮，让用户自己决定是否授权。不要用旧版的授权逻辑，不然会有一大半用户显示“微信用户”。

分享逻辑这块，很多人只做了onShareAppMessage转发的标题和图片，但没有带邀请人参数。我的做法是在转发路径里拼上邀请人的用户ID，例如/pages/index/index?inviter=U12345。这样做的实际价值是：后台能看到一个用户邀请了谁来，婚礼圈子里经常会有“亲友排行榜”这种玩法，谁拉的人多、谁最积极，在答谢环节提一嘴效果很好。当然，如果你的场景用不上这个数据，也可以不加，这个参数放那里不影响正常使用。

3. 后端接口与数据库设计

3.1 数据库表结构怎么建

我做这个项目时，核心数据表经验证最少要四张：用户基础表（如果你要记录邀请关系）、宾客回执表、祝福墙表、请柬设置表。用户表可以简单，重点是后三张。

先贴一个我实际用过的建表脚本，你拿去改改就能用：

-- 宾客回执表 CREATE TABLE `guest_rsvp` ( `id` int(11) NOT NULL AUTO_INCREMENT, `wedding_id` int(11) NOT NULL DEFAULT '1' COMMENT '婚期配置ID，默认1', `name` varchar(50) NOT NULL COMMENT '宾客姓名', `phone` varchar(20) NOT NULL COMMENT '手机号', `is_attend` tinyint(1) NOT NULL DEFAULT '0' COMMENT '是否到场 0-待定 1-到场 2-不到场', `companion_num` int(11) NOT NULL DEFAULT '0' COMMENT '随行人数', `remark` varchar(255) DEFAULT NULL COMMENT '备注需求', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_phone_wedding` (`phone`, `wedding_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 祝福墙表 CREATE TABLE `bless_message` ( `id` int(11) NOT NULL AUTO_INCREMENT, `nickname` varchar(50) NOT NULL COMMENT '昵称', `avatar` varchar(255) DEFAULT NULL COMMENT '头像URL', `content` text NOT NULL COMMENT '祝福内容', `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '0-待审核 1-已发布 2-已隐藏', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 请柬设置表 CREATE TABLE `wedding_setting` ( `id` int(11) NOT NULL AUTO_INCREMENT, `groom_name` varchar(50) NOT NULL COMMENT '新郎名', `bride_name` varchar(50) NOT NULL COMMENT '新娘名', `wedding_date` datetime NOT NULL COMMENT '婚礼时间', `address` varchar(255) NOT NULL COMMENT '详细地址', `venue` varchar(100) DEFAULT NULL COMMENT '宴会厅', `latitude` decimal(10,7) NOT NULL COMMENT '纬度', `longitude` decimal(10,7) NOT NULL COMMENT '经度', `cover_img` varchar(255) DEFAULT NULL COMMENT '封面图', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

一点设计上的建议。第一，is_attend用tinyint而不是varchar，存 0/1/2，比“yes/no/wait”这种字符串更省空间、查询更快。第二，所有文本字段选用utf8mb4字符集，因为宾客备注里可能会输 emoji 表情，用老的utf8会报错。这个坑我踩过一次，婚礼前三天发现备注里有表情的提交全部失败，排查了半天才发现是字符集问题。第三，日期时间统一用datetime标准格式，不要用时间戳字符串，否则后台导出 Excel 的时候会面对一堆乱码数字。

3.2 管理后台能干什么

管理后台的功能划分，我按“能被钱认可”的标准来设计。什么意思？就是客户愿意为哪些功能付费，后台就优先实现哪些功能。

第一是回执管理。这是核心。后台列出所有填过回执的宾客，支持按状态筛选（到场/不到场/待定）、按姓名搜索、分页展示。每一行显示姓名、手机号、随行人数、备注、提交时间。操作上最实用的按钮是“导出 Excel”，导出字段和列表一致。婚礼前一天，策划团队拿着这份 Excel 去和酒店对桌数，能省下大半天时间。

第二是数据统计。不用做花哨的可视化图表，一个面板就够。顶部三张大卡片：总邀请数（新增了多少回执）、到场人数（到场人数 + 平均随行人数）、待定人数。下面再放一个按小时统计提交数的简单柱状图，能看出什么时间段用户提交最集中。SQL 就是简单的GROUP BY，不需要上大数据组件。

第三是请柬内容管理。在后台把新郎名、新娘名、婚礼日期、地址、经纬度、封面图这些字段做成表单，保存后小程序端的getSetting接口就返回最新配置。这个功能的好处，我已经在前面讲过了，改期换酒店不用重新发版。

第四是内容审核。祝福墙的消息如果没有审核机制，迟早出事。后台给每条祝福一个状态切换按钮，默认待审核，改为已发布后小程序才展示。这个功能非常简单，但没有它，整套系统在真实运营中就是“裸奔”。

3.3 接口设计与数据返回规范

很多初学者写后端接口，逻辑能跑通但接口风格乱七八糟，前端联调的时候头疼，后来的人接手更头疼。我在这套项目里统一了接口规范，前后端联调基本不出幺蛾子。

接口路径采用资源语义化命名：GET /api/guest_rsvp/list翻页查回执、POST /api/guest_rsvp/submit提交回执、POST /api/bless_message/create发布祝福、GET /api/bless_message/list拉祝福列表、GET /api/setting/get获取请柬配置、POST /api/admin/login管理后台登录。动词不混用，能看懂就行。

响应结构统一是：

{ "code": 0, "msg": "success", "data": { "list": [], "total": 128, "page": 1, "pageSize": 10 } }

用code表示业务状态码，0 是成功，非 0 是失败，msg给前端直接弹提示用。不要用 HTTP 状态码去区分业务错误，比如手机号已登记这个场景，HTTP 200 但code返回 1001，前端拿到 1001 再提示用户“该手机号已提交过回执”。这个设计习惯在面试里也很加分，属于“一页纸就能讲清楚”的接口设计经验。

所有接口的传参统一用小驼峰，比如companionNum，数据库字段用下划线companion_num，后端在返回时做一次字段映射。这样前端拿到的数据是前端习惯的写法，后端模型保持数据库的原始命名，两边都不别扭。

分页方面，page从 1 开始，pageSize默认 10、最大 100，超出就截断。列表排序按created_at DESC，新提交的祝福排前面，刚发布的请柬配置不会因为改数据被顶到前面。

3.4 防刷与安全思路

婚礼请柬项目表面上是个小项目，但它会面向全量陌生人传播，一样要考虑安全问题。哪怕只是自己的婚礼，也不能把后台裸奔在公网上。

先说接口防刷。提交祝福和提交回执这两个写接口最容易被打。攻击者拿脚本循环调用，一分钟能给你插几千条垃圾数据。我的做法是两层限制：第一层在后端中间件里做单 IP 限流，比如同一个 IP 每分钟最多提交 5 次，超了直接返回“操作过于频繁”；第二层是在核心写接口做字段校验，比如手机号格式必须合法、内容长度必须限制在 200 字以内。这两层不需要引入 Redis，用内存 Map 就能实现，项目里加几十行代码的事。

再说数据脱敏。后台回执列表里能看到手机号没问题，但如果有同事或朋友帮忙管理后台，不要让他们看到完整号码。显示为138****8888就够用。方法很笨但有效：后端查询后统一抹掉中间四位，导出 Excel 时也做同样处理。需要联系宾客时，再给一个“点击查看完整号码”的按钮，走一次管理员操作日志。

最后是数据库备份。婚礼请柬的数据量不大，但数据本身很重要，你在婚礼前一天不可能去恢复一张被误删的表。我习惯在婚礼前一周、前一天各做一次全量备份。一条mysqldump命令就够了，存到服务器另一个目录。另外开启 binlog，万一误操作还能回滚到指定时间点。

4. 部署流程与问题排查

4.1 小程序前端怎么跑起来

先把基础流程讲清楚。拿到源码后，在微信开发者工具里导入miniprogram目录，填入自己的小程序 AppID。注意不要用自己的测试号，因为后续要发布的正式版必须绑定服务器域名，测试号的配置限制会让你卡在接口联调那里。

第二步是改接口域名配置。打开utils/config.js，把baseUrl改成你后端服务的 HTTPS 地址。这里有个最容易忽略的坑：小程序 request 的域名必须在微信公众平台后台配置为合法域名，而且必须 HTTPS。如果你只是本地调试，可以在开发者工具的“详情 -> 本地设置”里勾选“不校验合法域名”，但这个选项只对开发调试有效，真机预览时如果没配置合法域名，所有请求都会失败，报url not in domain list。

第三步就是上传体验版、提交审核、发布正式版。提审之前建议在体验版上完整跑一遍流程：打开请柬、传祝福、填回执、后台看数据。我们吃过一次教训：体验版一切正常，正式版发布后用户普遍反映首页图片加载很慢，后来排查是图片走的服务器带宽不够，几百人同时在用的时候带宽被打满了。所以线上版本建议图片全部放 CDN，后端服务器带宽不用买特别大，省下的钱买 CDN 流量更划算。

4.2 后端和数据库如何部署

后端部署我推荐两条路线，按你的实际情况选。

路线一是云服务器 + PM2 + MySQL，适合对服务器有基本操作经验的人。流程是：买一台 2核4G 的云服务器（婚礼请柬的访问量一个月不会太高，起步配置够用），装好 Node.js 或 Java 环境，把server目录上传，安装依赖，执行建表脚本，用 PM2 启动服务。然后把域名解析到服务器 IP，申请 HTTPS 证书，配置 Nginx 反向代理，把 443 端口的请求转发到后端进程监听的 3000 端口。再在微信公众平台后台配置 request 合法域名。这套流程一两个小时能完成，之后维护起来非常顺手，日志用 PM2 和 Nginx 都能看。

路线二是微信云托管或云开发，适合不想维护服务器的个人用户。代码里写好的接口逻辑可以迁到云函数，数据库用云数据库，小程序前端请求云函数。这样的好处是不用管域名、证书、备案这些问题，缺点是云开发环境边界比较多，无法直接在云数据库里跑复杂的 SQL 联表查询，数据导出也比较受限。

两条路我推荐大多数人选第一条。虽然配置麻烦一点，但一旦跑通，项目的掌控感是完全不同的。定位问题、看日志、改表、恢复数据，全部在自己手里，不用被环境卡的难受。

4.3 常见问题速查表

把我在这个项目里遇到过的高频问题整理成一张速查表，方便你踩坑时直接对号入座。

现象	可能原因	解决方案
真机上请求接口失败，报 url not in domain list	小程序后台没有配置合法域名，或域名不是 HTTPS	微信公众平台配置 request/socket 合法域名，确认证书有效
开发者工具请求正常，手机预览失败	没勾选“不校验合法域名”只影响本地，真机必须配置合法域名	同上，统一在后台配置
二维码或分享卡片打开后参数丢失	路径参数太长或含特殊字符	参数长度限制，路径参数用`encodeURIComponent`编码后拼接
提交回执提示成功，但后台查不到数据	后端日志报错，可能是字段类型或字符集问题	查看服务日志，检查表字符集是否为 utf8mb4
同一个手机号重复提交多条记录	后端缺少唯一索引或前端未做防重	加上`uk_phone_wedding`唯一索引，前端缓存提交状态
首页图片加载慢	图片体积大、后端带宽低	图片压制到 200KB 以内，放 CDN，首屏只用一张背景图
祝福墙提交内容显示乱码	数据库字符集不是 utf8mb4	建表时指定`DEFAULT CHARSET=utf8mb4`，连接串也加上字符集参数
后台导出 Excel 出现一堆科学计数法	手机号字段被 Excel 当数字处理	导出时在手机号前加`\t`或设置单元格格式为文本
小程序审核不通过	类目不符或功能不完整	根据平台提示调整类目，填好隐私保护指引，完善用户隐私协议