微信小程序来访预约审批系统源码解析：从表单到二维码生成

简介：面向小程序开发与毕业设计场景的来访预约审批系统完整源码及文档说明，属于高分项目，评审分98分，适合计算机相关专业正在做期末大作业、毕业设计，或需要项目实战练习的学习者。资源共480个文件，包含183个js逻辑脚本、82个wxml页面结构、102个wxss样式表、76个json配置，并附带docx安装使用手册与md说明文档，压缩包体积仅2.26MB，结构清晰便于按模块学习。已有45人学习下载。源码均经过本地编译与严格调试，可直接运行；其中还包含qrcode_lib、wxcharts-min、page_helper、db_util等工具模块，覆盖二维码生成、图表展示、页面辅助与数据操作等功能，可帮助理解预约审批业务流程与小程序的完整实现思路，是课设和毕设的实用参考。

1. 小程序预约审批系统，先从一套能跑的源码开始

访客预约审批这个场景，很多团队都在做，但做成微信小程序形态的并不多。常见的实现方式要么是管理员在后台手动核对访客信息，要么用第三方表单工具收集预约再人工审批，两种方式都存在信息不同步、审批链路长的问题。这套基于微信小程序的来访预约审批系统，核心就是把访客登记、二维码生成、审批流管理全部搬到微信生态内，访客在小程序端提交预约，管理员在后台完成审核，审核通过后自动生成二维码供门岗核验。源码包内不仅有完整的页面和逻辑代码，还附带安装使用手册文档说明，对正在做毕业设计或期末大作业的计算机专业学生来说，省去了从零搭建框架的时间，可以更专注在业务逻辑和功能调试上。

这套系统的代码风格比较规整，工具函数、页面逻辑、数据层做了初步分离。资源包里能看到 faker_lib.js、qrcode_lib.js、wxcharts-min.js、page_helper.js、db_util.js 这五个核心文件，它们分别负责模拟数据、二维码生成、图表绘制、页面辅助函数和数据层操作。下面先拆一下工程结构，再讲怎么把系统跑起来，最后深入到每个模块的实现细节和参数调优。

2. 工程结构与运行环境：把这些文件放进开发者工具就能跑

拿到源码包后，先别急着双击打开手册，我建议先用微信开发者工具把项目跑起来，再对照文档看代码，这样理解会快很多。微信小程序和传统 Web 项目最大的区别在于运行环境不同，小程序运行在微信客户端内，有一套独立的生命周期和 API 体系，页面文件由 wxml、wxss、js、json 四件套组成，数据绑定和事件处理机制也自成一套。

2.1 项目文件分类与职责划分

先看一下整个工程的文件布局，这套系统的结构虽然简单，但分层意识已经有了雏形。根目录下除了常规的 app.js、app.json、app.wxss 之外，还单独拆出了 utils 目录和 pages 目录，从文件名可以看出这是一个按功能模块组织的工程。

这里值得说明的是 db_util.js，它不是真正意义上的数据库连接层，而是一个基于 wx.setStorageSync 和 wx.getStorageSync 封装的存储工具。用本地缓存模拟数据库，是很多小程序毕业设计项目的常见做法，优点是不需要搭建服务器，数据持久化直接依赖微信客户端的本地存储能力。缺点也很明显，不同设备之间的数据不互通，换一台手机登录就看不到之前的预约记录了。理解这一点，后面看数据操作代码时就不会产生困惑。

2.2 开发者工具导入与 AppID 配置

微信小程序开发工具的下载和安装不做赘述，直接讲导入步骤。打开微信开发者工具，选择“导入项目”，在目录中选择源码包的根目录。这里有两个容易出问题的地方：第一个是 AppID，如果只有源码没有自己的 AppID，就选择“测试号”，测试号可以正常编译预览，但部分 API 如 wx.login 的返回值会有差异；第二个是项目名称，工具会自动读取 project.config.json 中的配置，如果没识别出来就手动填一个。

{ "appid": "touristappid", "projectname": "visitor-reservation-system", "setting": { "urlCheck": true, "es6": true, "postcss": true, "minified": true }, "compileType": "miniprogram" }

这段是 project.config.json 的关键配置，appid 字段如果填的是 touristappid，表示以游客模式运行，不需要注册小程序账号；urlCheck 控制是否校验后台接口域名合法性，本地调试阶段可以关闭，但真机预览时如果调用了 request 接口，就必须在微信公众平台配置合法域名，否则请求会被拦截。es6 和 postcss 都开启，保证 ES6 语法能够被正确转译，样式文件自动补全浏览器前缀。

2.3 编译预览与常见启动错误

点编译按钮后，如果控制台没有报错，模拟器里应该能看到首页的访客预约表单和最近的预约列表。常见的启动错误集中在三个方面：第一个是找不到 app.json，这通常是导入项目时目录选错，选到了内层目录，解决方法是回到源码包的根目录重新导入；第二个是 sitemap.json 索引失败，文件不存在时在 app.json 里删除 sitemapLocation 字段即可；第三个是 wxcharts-min.js 报错，这个压缩过的图表库对 ES6 语法比较敏感，检查 project.config.json 里 es6 转译是否开启。

提示：如果页面样式错乱，先检查是否有自定义组件或第三方 UI 库的依赖没有安装。这套系统的页面样式大部分是原生 wxss 编写的，理论上不依赖 npm 包，但个别页面可能引用了 iconfont 字体。

跑通之后，你会发现首页的信息流里已经有预约数据了，这就是 faker_lib.js 在起作用。它会批量生成模拟的访客预约记录写入本地存储，让你在没有真实业务数据的情况下依然能完整体验审批流程。这也解释了一个问题：为什么这套源码拿到手就能直接看到有数据展示，而不是空页面。

3. 数据层与工具库剖析：db_util、faker_lib 和 page_helper 的设计思路

小程序的页面交互离不开数据支撑，而这套系统的数据层设计走的是“模拟数据先行 + 本地缓存持久化”的轻量路线。对于毕业设计来说，这种设计既简化了后端复杂度，又能把前端展示和交互逻辑完整呈现。深入看 db_util.js 和 faker_lib.js 的实现，能学到不少小程序数据管理的实用技巧。

3.1 db_util.js 的缓存封装与同步策略

db_util.js 对外开放的方法不多，核心是 get、set、remove 和 clear 这四个静态方法，内部通过 wx.getStorageSync 和 wx.setStorageSync 操作本地缓存。这里有一个容易被忽略的设计细节：它把所有的存储键名都集中管理，而不是分散在业务代码里。这样做的直接好处是后期需要统一调整存储结构时，只需要改一个文件。

// utils/db_util.js const STORAGE_KEYS = { VISITOR_LIST: 'visitor_list', APPROVAL_LIST: 'approval_list', USER_INFO: 'user_info', PENDING_SYNC: 'pending_sync' }; function get(key) { try { return wx.getStorageSync(key) || null; } catch (e) { console.error(`[db_util] 读取失败: ${key}`, e); return null; } } function set(key, value) { try { wx.setStorageSync(key, value); return true; } catch (e) { console.error(`[db_util] 写入失败: ${key}`, e); return false; } } function updateVisitorByNo(visitorNo, patch) { const list = get(STORAGE_KEYS.VISITOR_LIST) || []; const index = list.findIndex(item => item.visitorNo === visitorNo); if (index !== -1) { list[index] = { ...list[index], ...patch }; set(STORAGE_KEYS.VISITOR_LIST, list); return list[index]; } return null; } module.exports = { STORAGE_KEYS, get, set, updateVisitorByNo };

这段代码里值得关注的是 updateVisitorByNo 这个函数，它在更新预约记录时用了先读全量列表、再定位目标记录、最后写回全量列表的方式。在小程序本地存储场景下，数据量通常只有几百条，这种全量读写的性能损耗可以忽略，但换来的是逻辑上的直观和安全。如果未来要接入云端数据库，只需要把 get 和 set 内部的实现替换成 wx.cloud.database() 的调用即可，业务层的调用方式完全不用变，这是封装带来的最大价值。

3.2 faker_lib.js 的模拟数据生成规则

faker_lib.js 负责生成贴近真实场景的模拟数据，这个模块在处理演示项目时非常实用。它生成的访客数据包括姓名、手机号、来访事由、预约时间、被访人、状态等字段，生成规则上做了几层考量：手机号通过随机前缀加 8 位数字拼接，来访事由从一个预设数组里随机取，预约时间在当前时间前后浮动，状态则按照“待审批 / 已通过 / 已拒绝 / 已过期”四种状态按权重分配。

// utils/faker_lib.js const MOCK_VISITORS = (count = 20) => { const reasons = ['商务洽谈', '技术交流', '面试', '快递配送', '维修保养', '客户拜访']; const statuses = [ { status: 'pending', weight: 0.4 }, { status: 'approved', weight: 0.35 }, { status: 'rejected', weight: 0.15 }, { status: 'expired', weight: 0.1 } ]; const pickByWeight = (arr) => { const totalWeight = arr.reduce((sum, item) => sum + item.weight, 0); let random = Math.random() * totalWeight; for (let item of arr) { random -= item.weight; if (random <= 0) return item; } return arr[arr.length - 1]; }; return Array.from({ length: count }, (_, index) => { const statusObj = pickByWeight(statuses); const baseTime = Date.now() - Math.floor(Math.random() * 7 * 24 * 3600 * 1000); return { visitorNo: `V${Date.now().toString(36)}${index}`, name: `访客_${index + 1}`, phone: `138${String(Math.floor(Math.random() * 100000000)).padStart(8, '0')}`, reason: reasons[Math.floor(Math.random() * reasons.length)], visitTime: new Date(baseTime).toISOString(), status: statusObj.status, createTime: new Date(baseTime - 3600 * 1000).toISOString() }; }); };

注意 pickByWeight 这个函数，它实现了按权重随机选择状态的功能。很多人生成模拟数据时习惯用 Math.random() 直接等概率选取，但现实中预约审批的状态分布是不均匀的，等概率会让待审批数据占比过高或过低。权重机制让演示数据更接近真实业务形态，前端页面在展示时也会更自然。使用这套数据时要注意一点：模拟数据生成的手机号虽然有 11 位，但只是格式合法，并非真实存在的号码，调试时不要用这些号码去匹配业务系统的用户数据。

3.3 page_helper.js 的页面辅助能力

page_helper.js 把页面中重复的逻辑抽成了公共函数，比如日期格式化、状态文本映射、表单校验规则等。状态映射函数是这里比较有看点的部分，它将数值状态码转换为不同含义的文案，同时返回对应的 class 名称，用于控制标签的颜色展示。

// utils/page_helper.js const STATUS_MAP = { pending: { text: '待审批', className: 'tag-pending' }, approved: { text: '已通过', className: 'tag-approved' }, rejected: { text: '已拒绝', className: 'tag-rejected' }, expired: { text: '已过期', className: 'tag-expired' }, cancelled: { text: '已取消', className: 'tag-cancelled' } }; function formatStatus(status) { return STATUS_MAP[status] || { text: '未知', className: 'tag-unknown' }; } function isValidPhone(phone) { return /^1[3-9]\d{9}$/.test(phone); } function isValidVisitTime(timeStr, minLeadMinutes = 30) { const visitTime = new Date(timeStr).getTime(); const now = Date.now(); return visitTime - now >= minLeadMinutes * 60 * 1000; } module.exports = { formatStatus, isValidPhone, isValidVisitTime };

form 表单提交时会同时调用 isValidPhone 和 isValidVisitTime 做前置校验，前者用正则校验手机号格式，后者校验预约时间至少比当前时间晚 30 分钟。这个 30 分钟的提前量设计是有业务考虑的，如果访客提交预约后立即生成二维码，可能出现访客还没到门岗、二维码已经过期或管理员来不及审批的情况。预留一段时间缓冲，既给审批留出操作窗口，也避免访客在预约时间前过早到达造成门岗核验失败。

4. 核心业务流程实现：从预约提交、二维码生成到审批状态机

本章是整套系统的业务核心，前面铺垫了工具函数和数据层，现在把它们串起来看完整的业务链路。用户打开小程序提交预约、管理员审批、访客出示二维码核验，这三个环节构成了系统的主干。源码里对应的页面逻辑和工具函数协作方式，是本章分析的重点。

4.1 预约表单的提交与级联校验

预约表单页是访客进入系统的第一道界面。表单字段包括访客姓名、手机号、来访事由、被访人、预约时间。提交时先走前端校验，再组装成完整预约记录写入本地缓存。

// pages/visit-form/visit-form.js const dbUtil = require('../../utils/db_util'); const helper = require('../../utils/page_helper'); Page({ data: { form: { name: '', phone: '', reason: '', host: '', visitTime: '' }, reasons: ['商务洽谈', '技术交流', '面试', '快递配送', '维修保养', '客户拜访'] }, handleSubmit() { const { form } = this.data; if (!form.name.trim()) { wx.showToast({ title: '请输入访客姓名', icon: 'none' }); return; } if (!helper.isValidPhone(form.phone)) { wx.showToast({ title: '请输入正确的手机号', icon: 'none' }); return; } if (!form.reason) { wx.showToast({ title: '请选择来访事由', icon: 'none' }); return; } if (!helper.isValidVisitTime(form.visitTime, 30)) { wx.showToast({ title: '预约时间需晚于当前时间30分钟', icon: 'none' }); return; } const visitorRecord = { visitorNo: `V${Date.now().toString(36)}${Math.random().toString(36).slice(-4)}`, ...form, status: 'pending', createTime: new Date().toISOString() }; const list = dbUtil.get(dbUtil.STORAGE_KEYS.VISITOR_LIST) || []; list.unshift(visitorRecord); dbUtil.set(dbUtil.STORAGE_KEYS.VISITOR_LIST, list); wx.redirectTo({ url: `/pages/visit-detail/visit-detail?visitorNo=${visitorRecord.visitorNo}` }); } });

这里有几个需要留意的设计点。visitorNo 的生成方式看着随意，但做了两重随机化以避免重复，时间戳转 36 进制可以在同一毫秒内生成的记录也不冲突。状态初始值固定为 pending，这是整个审批状态机的起点，后续管理员操作的每一步都围绕这个状态字段展开。前端校验之外，理论上还应该有一层后端校验兜底，但当前版本数据层是本地存储，所以前端校验就是最终校验。

4.2 二维码生成模块与参数调优

qrcode_lib.js 是本系统的一个亮点模块，它不依赖第三方云服务，在本地直接将预约单号编码为二维码。小程序 canvas 绘制二维码需要注意绘制精度和扫描识别距离的关系。

// pages/visit-detail/visit-detail.js const qrcodeLib = require('../../utils/qrcode_lib'); function generateQRCode(canvasId, codeStr) { const ctx = wx.createCanvasContext(canvasId); qrcodeLib.draw(codeStr, { ctx: ctx, width: 200, height: 200, correctLevel: qrcodeLib.QRErrorCorrectLevel.H, foreground: '#000000', background: '#ffffff', padding: 20 }); }

二维码生成的核心参数是 correctLevel。设置为 H 级别时，即使二维码有 30% 的面积被遮挡或污损，依然可以被识别。在门岗场景中，访客手机屏幕的亮度差异、贴膜反光、甚至显示区域边缘被遮挡都可能影响识别率，所以安全系数取最高档是比较稳妥的选择。当然容错率越高，二维码图案越密集，稍大尺寸的码在 200px 的屏幕区域里显示会更清晰，这也是 table 中 size 建议区间不设过小的原因。

4.3 审批状态机的流转逻辑

状态机是本系统业务逻辑的骨架。审批页的核心操作是“通过”和“拒绝”，每次操作都会改变访客记录的 status 字段，同时可以填写审批意见。为了理清状态流转规则，这里用代码来展示审批操作的实现方式：

// pages/audit-list/audit-list.js function approveRecord(visitorNo, comment) { const record = dbUtil.updateVisitorByNo(visitorNo, { status: 'approved', comment: comment || '', auditTime: new Date().toISOString() }); if (!record) { wx.showToast({ title: '记录不存在', icon: 'none' }); return; } generateQRCode('auditQRCode', visitorNo); wx.showToast({ title: '已通过', icon: 'success' }); } function rejectRecord(visitorNo, comment) { dbUtil.updateVisitorByNo(visitorNo, { status: 'rejected', comment: comment || '未说明原因', auditTime: new Date().toISOString() }); wx.showToast({ title: '已拒绝', icon: 'none' }); }

审批通过后会立刻生成二维码，这是系统设计里比较实用的一环。访客详情页会根据当前状态动态展示内容：待审批时显示进度提示，已通过时展示二维码，已拒绝时展示驳回理由。这里有一个边界情况值得注意：如果访客的预约时间已经过去，但管理员才点击“通过”，系统不会阻止这个操作，因为状态机里没有对时间维度做交叉校验。实际生产环境应该在审批时增加一步判断，预约时间已过的记录自动标记为 expired，不允许再通过审批。

另外审批列表页通常使用 wxcharts-min.js 来绘制图表，展示每日预约量和审批转化率。图表的数据来源是本地缓存里的预约记录，通过日期归组和状态统计计算得出，这对管理员观察来访趋势是有参考意义的。

5. 页面交互与性能调优：setData 优化、分包加载和真机调试

系统功能跑通之后，下一个阶段就是让它在真机上也能流畅运行。很多人做完小程序后直接在开发者工具里看效果，忽略了一个事实：开发者工具的渲染环境和真机存在差异，尤其体现在性能表现和部分 API 的行为上。

5.1 避免频繁 setData 造成页面卡顿

在预约列表页中，一个常见的性能瓶颈是一次 setData 传入大量数据，或者循环中多次调用 setData。比如下拉刷新时如果一次性加载 50 条预约记录，每条记录包含 10 多个字段，这些数据都会被序列化后从逻辑层传输到渲染层，整个过程是异步且消耗性能的。

// 不推荐：循环内多次 setData for (let i = 0; i < res.length; i++) { this.setData({ [`list[${i}]`]: res[i] }); } // 推荐：一次 setData 传入完整数据 this.setData({ list: res }); // 推荐：分页加载，每次只更新增量部分 this.setData({ list: this.data.list.concat(res) });

上面的对比可以直观看出性能差异。循环内多次 setData 会触发多次视图层更新，每两次之间还有逻辑层和渲染层的通信开销，数据量大了以后页面会出现明显的掉帧。一次性的数据赋值只会触发一次渲染，性能最好。分页加载则是另一个层面的优化，每次向列表尾部追加数据，而不是重新赋值整个数组，这样也不会影响已有列表项的滚动位置。

5.2 首屏加载优化与分包策略

首屏加载速度直接影响用户对系统的第一印象。这个项目的首页依赖 faker_lib.js 生成的模拟数据来渲染列表，如果生成逻辑在启动时同步执行，可能在低端机上卡住主线程。优化方式是延后非关键数据的初始化时机。

// app.js onLaunch() { // 首屏只加载必要配置 this.initSystemInfo(); // 模拟数据延后到页面 ready 后生成 wx.nextTick(() => { const faker = require('./utils/faker_lib'); const list = dbUtil.get(dbUtil.STORAGE_KEYS.VISITOR_LIST); if (!list || list.length === 0) { dbUtil.set(dbUtil.STORAGE_KEYS.VISITOR_LIST, faker.generateVisitors(20)); } }); }

wx.nextTick 的回调会在当前同步代码执行完毕后、首帧渲染前运行，用它来推迟耗时任务不会阻塞初始渲染。另一个思路是利用小程序的按需注入特性，在 app.json 中配置 lazyCodeLoading 为 requiredComponents，这样只有页面用到的基础库组件才会注入，降低启动耗时。

首屏之外，这个项目还可以考虑分包加载。wxcharts-min.js 只在审批统计页用到，faker_lib.js 只在模拟数据初始化时用到，它们都可以放入分包，主包只保留首页和预约表单逻辑。这样主包体积可以控制在 1MB 以内，满足微信的上传限制，也减少下载耗时。

5.3 真机调试的关键检查项

开发者工具模拟器上表现正常的代码，真机上不一定能稳定运行。二维码绘制是重点检查对象，canvas 在开发者工具中显示正常不代表真机上就能正常导出或截图。常见的问题是 canvas 尺寸和 css 尺寸不一致导致生成图片模糊，解决方式是使用 canvas 的像素比自适应。

// 真机 canvas 模糊适配 const dpr = wx.getSystemInfoSync().pixelRatio; canvas.width = width * dpr; canvas.height = height * dpr; canvas.style.width = width + 'px'; canvas.style.height = height + 'px'; ctx.scale(dpr, dpr);

另外要注意 wx.getSystemInfoSync 在较新版本的基础库中属于废弃 API，建议使用 wx.getWindowInfo 和 wx.getDeviceInfo 替代，如果项目调试的基础库版本较高而代码里仍在使用旧 API，控制台会给出警告但不会影响运行。这些调整做完后，真机的流畅度和渲染效果会有明显改善，对演示和答辩环节来说也更有说服力。无论项目是用于毕业设计还是期末大作业，把系统调到能在真机上稳定演示，比停留在模拟器阶段更能体现工程实践能力。

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