尧图网页设计 
校园出入口管理的核心矛盾在于「通行效率」与「权限约束」之间的平衡既要让持卡师生以最短的停留时间通过又要保证每一次放行都发生在有效授权之内。本系统以 STM32F103C8T6 为现场控制核心构建了刷卡与人脸两条并行的身份识别通道——前者由 MFRC522 读取校园卡唯一 UID 完成本地校验后者由 ESP32-CAM 采集现场图像上传服务端经人脸检测与特征比对完成远程核验两条通道的验证结果统一交由主控裁决再由 SG90 舵机执行门体开合LED 与蜂鸣器给出通行状态的即时反馈。权限与台账则落在 Web 管理端与微信小程序两端学生自行注册并提交开通或延期申请管理员审批后权限方才生效到期自动停用通行记录与账户变更记录全程留痕可逐条追溯。本文面向希望复现或二次开发的读者按「一、项目基本情况 → 二、系统架构设计 → 三、系统界面展示 → 四、系统视频展示 → 五、获取方法」组织其中通信报文与模块配置帧均取自实机调试记录可直接复制使用。技术栈速览层次选型说明现场控制STM32F103C8T6Cortex-M3 72 MHzKeil 5 开发硬件 SPI GPIO 串口刷卡识别MFRC52213.56 MHzSPI 接口读取校园卡唯一 UID人脸采集ESP32-CAMOV2640 Wi-Fi串口接主控独立以 HTTP POST 上传图像门体执行SG90 舵机PWMPA8控制转角通行检测对射式红外对管OUT → PB8遮挡触发通行事件反馈有源蜂鸣器 LED 指示灯PB1 / PB0声响与视觉双通道服务端JeeSite 平台 Java SpringBoot MySQLTCP Socket 服务 人脸检测识别调度前端BootstrapWeb 管理端 / 微信小程序webview 调 H5与 Web 端共享业务接口人脸算法虹软人脸 SDK人脸检测与特征比对通信采用双通道图像走 HTTP POST8889 端口/f/esp32/upload指令与状态走 TCP Socket19214 端口。一、项目基本情况校园行人出入管理长期依赖人工核验或单一识别手段。人工核验在上下课时段形成明显的通行瓶颈而仅使用校园卡识别时卡片可被转借识别结果无法确认持卡人身份仅使用人脸识别时又容易受光照、姿态与遮挡影响在逆光或快速通行场景下稳定性不足。更关键的是权限管理往往与识别环节彼此割裂——学生毕业、转专业或休学后原卡仍可能在门禁上继续有效权限的变更缺乏一条可追溯的流程与记录。本项目的设计出发点正是把「身份识别—权限判定—门体执行—记录留痕」收敛到同一条数据链路上使每一次放行都同时具备效率与可审计性。1.1 设计目标与技术路线系统的设计目标可归纳为三点。其一以刷卡与人脸构成两条并行的身份识别通道——MFRC522 通过 SPI 接口读取校园卡的唯一 UID与本地台账比对完成快速校验承担高频次、低时延的日常通行ESP32-CAM 采集现场人脸图像上传服务端由服务端的人脸检测与识别算法完成特征比对承担身份确认与防转借的职责。两条通道互为补充刷卡保证通行效率人脸保证身份真实任一条通过即形成一次完整的验证结论其二以申请—审批流程约束门禁权限——学生在小程序端自行注册账号并提交开通或延期申请申请进入管理员的待审批列表经审核通过后门禁权限方才生效并附带明确的有效期到期自动停用从根本上避免权限的无限期滞留其三以记录留痕支撑事后追溯——每一次通行都会写入一条包含姓名、卡号、通行方式、抓拍照片与终端编号的记录每一次账户状态变更同样写入操作记录使「谁在何时以何种方式通过」与「谁在何时批准了谁的权限」都有据可查。技术路线上系统采用「嵌入式控制节点 无线图像与数据通道 服务端识别与存储 Web 与小程序双端」的分层结构。现场节点以 STM32F103C8T6 为核心经 SPI 挂载 MFRC522 射频读卡模块经 GPIO 驱动红外对管、蜂鸣器、LED 与 SG90 舵机经串口接入 ESP32-CAM 图像模块使用 Keil 5 完成下位机开发各功能模块以自制 PCB 为载体互连人脸图像由 ESP32-CAM 以 RESTPOST 请求方式直接提交服务端的上传接口不经过主控中转避免了图像数据占用主控的存储空间与串口带宽卡号上报、识别结果、放行指令与参数配置等小体积数据则通过 TCP Socket 在硬件与服务端之间透传服务端基于 JeeSite 平台与 Java SpringBoot 构建以 MySQL 完成业务数据持久化并通过虹软 SDK 实现人脸检测与识别Web 管理端采用 Bootstrap 前端框架微信小程序则以 webview 控件调用 H5 页面的方式实现与 Web 端共享同一套业务接口。1.2 系统总体架构系统在纵向上划分为四个层次自下而上依次为感知执行层、边缘控制层、网络与识别层、应用层。感知执行层由 MFRC522 射频读卡模块、ESP32-CAM 图像模块、红外对管、SG90 舵机、蜂鸣器与 LED 指示灯组成分别承担身份信息采集、通行事件检测、门体动作执行与状态反馈边缘控制层由 STM32F103C8T6 承担完成校园卡 UID 的读取与人脸验证结果的判定、门体开合的时序控制、蜂鸣器与 LED 的反馈调度以及串口与 TCP Socket 的通信调度网络与识别层由 ESP32-CAM、REST 图像上传通道、TCP Socket 指令通道与服务端的人脸检测识别服务共同构成承担图像上行、特征比对与结果下行应用层由服务端、Web 管理端与微信小程序承载负责权限维护、审批流转、记录呈现与查询检索。四层之间以图像上行与指令下行两条路径耦合形成从身份识别到放行、再到记录入库的完整闭环。图 1 系统总体架构感知执行、边缘控制、网络与识别、应用四层结构1.3 系统功能构成从功能视角看系统可切分为硬件系统、软件系统与交付服务三个维度。硬件系统沿「识别—执行—反馈—通信」四条主线展开识别环节由 MFRC522 与 ESP32-CAM 组成执行环节由 SG90 舵机组成反馈环节由 LED 指示灯与蜂鸣器组成通信环节由 ESP32-CAM 的图像上行与 TCP Socket 的指令下行组成软件系统分为 Web 管理端、微信小程序与服务端三部分Web 管理端在系统管理维度提供闸机管理、参数管理与人员管理含人脸绑定、卡号绑定与启用停用在业务管理维度提供实时数据显示含远程控制、通行记录查询、账户维护记录查询与账号审批四类功能微信小程序面向持卡师生提供用户登录注册、宫格导航、通行记录查询、账户变更记录查询与个人中心含人脸绑定、账户申请与延期申请服务端承担 TCP Socket 服务、与硬件的周期性数据同步以及人脸检测与识别调度交付内容包含硬件实物、软硬件程序源码、硬件原理图与功能演示视频。图 2 系统功能结构硬件系统、软件系统与交付服务三个维度1.4 硬件构成与器件选型硬件选型遵循「接口明确、职责单一、成本可控」的原则。主控选用 STM32F103C8T6其 Cortex-M3 内核运行于 72 MHz具备充足的 GPIO 资源与硬件 SPI 接口可同时挂载射频读卡、舵机、指示灯、蜂鸣器与图像模块身份识别选用 MFRC522 射频读卡模块工作于 13.56 MHz 频段经 SPI 接口与主控通信读取校园卡的唯一 UID 用于身份判据人脸采集选用 ESP32-CAM兼具摄像头接口与 Wi-Fi 能力可在单片上完成图像获取与上传是本系统唯一具备联网能力的现场节点门体动作选用 SG90 舵机模拟其转角由 PWM 信号直接给定便于演示门体开启与闭合的完整动作通行检测选用对射式红外对管行人通过门体时红外光路被遮挡输出电平跳变构成通行事件的计数依据状态反馈由 LED 指示灯与有源蜂鸣器共同承担以视觉与听觉两条通道同时给出验证结果。各器件的具体接口对应关系如下表所示。器件型号 / 规格接口与引脚功能定位主控 MCUSTM32F103C8T6Cortex-M372 MHz—系统控制核心Keil 5 开发射频读卡MFRC522 XSWU4SPISDA→PA7SCK→PA6MOSI→PA5MISO→PA4RST→PA13.3 V读取校园卡唯一 UID作为刷卡通行通道的身份判据图像采集ESP32-CAMU10串口模块 RX→PA9模块 TX→PA105 V现场人脸图像采集经 RESTPOST上传服务端通行检测对射式红外对管U3GPIOOUT→PB85 V检测行人通过门体为通行记录提供事件触发门体执行SG90 舵机U6GPIO / PWMPWM→PA85 V执行门体的开启与闭合动作声响反馈有源蜂鸣器BUZZER2GPIO信号端→PB1验证成功、失败与异常告警的声响提示视觉反馈LED 指示灯LED23 mm 红色GPIOPB0 → 1 kΩ 限流电阻通行状态与验证结果的视觉指示供电单元5 V / 3.3 V 双路供电Micro-USB 取电5 V 供舵机、红外对管与图像模块3.3 V 供读卡模块全系统共地需要说明两条识别通道在系统里的分工刷卡通道回答的是「这张卡是否在有效名册内」属于确定性的本地比对响应时间在毫秒量级适合上下课时段的高并发通行人脸通道回答的是「站在闸机前的这个人是否与档案中的持卡人一致」属于外部算力参与的特征比对需要一次图像上传与服务端往返适合作为身份确认与防转借的补充手段。把「卡」与「人」两类身份凭据分别交由两个器件采集使主控的裁决逻辑得以简化为「任一条通道通过即放行、两条通道均未通过则拒绝」的单一判据。二、系统架构设计2.1 硬件系统结构与引脚分配硬件以 STM32F103C8T6 为中枢左侧为感知输入通道右侧为执行与反馈通道下方为供电单元。输入侧汇集 MFRC522 读卡模块、ESP32-CAM 图像模块与红外对管三路信号输出侧驱动 SG90 舵机、有源蜂鸣器与 LED 指示灯。其中 ESP32-CAM 在系统中具有「传感器」与「通信模块」的双重身份它既经串口接收主控的抓拍指令又独立承担与服务端之间的图像上传使图像数据无需占用主控的存储与串口带宽。引脚分配上MFRC522 占用主控的硬件 SPI 引脚组PA5 至 PA7与一根复位控制线PA1ESP32-CAM 与主控以串口交叉相连模块侧的 RX 接 PA9、TX 接 PA10红外对管的输出接入 PB8舵机的 PWM 信号接入 PA8蜂鸣器与 LED 分别占用 PB1 与 PB0二者之间不存在引脚复用。舵机回路属于冲击性负载其供电走线与射频读卡模块的弱信号通路分开布置避免舵机启动瞬间的电流跳变影响 SPI 时序与卡号判读。图 3 硬件系统原理框图主控、识别与检测输入、执行与反馈输出、供电单元2.2 硬件原理图原理图使用嘉立创 EDA 绘制按功能划分为 MFRC522 射频读卡单元、ESP32-CAM 图像单元、STM32F103C8T6 核心板单元、LED 指示单元、SG90 舵机单元、红外对管单元与蜂鸣器单元等功能区块。射频读卡模块采用 SPI 接口SDA、SCK、MOSI、MISO 分别接至 PA7、PA6、PA5、PA4复位线接至 PA1模块工作电压为 3.3 V其 IRQ 引脚在本系统中未使用图像模块的串口与主控交叉相连——模块的 IO3RX接 PA9模块的 IO1TX接 PA10模块由 5 V 供电其余 IO 引脚在本系统中悬空舵机的 PWM 信号接至 PA8由定时器输出脉宽可调的方波控制转角红外对管的输出接至 PB8供电取 5 VLED 指示灯串联 1 kΩ 限流电阻后接至 PB0蜂鸣器的信号端接至 PB1另一端接 GND。核心板右列的 3.3 V、5 V 与 GND 引脚为各功能模块提供统一供电各外设均就近去耦。原理图同时提供源文件、PDF 与图片等多种格式便于直接投板打样或二次修改。图 4 硬件原理图嘉立创 EDA 绘制含 STM32F103C8T6、MFRC522、ESP32-CAM、SG90 舵机、红外对管、蜂鸣器与 LED2.3 硬件实物实物按原理图在自制 PCB 上焊接完成板面以四角尼龙柱支撑各功能模块通过排针与端子连接。板面中部为 MFRC522 射频读卡模块天线圈位于模块正面卡片靠近即可完成读取右侧依次布置 SG90 舵机、有源蜂鸣器与 LED 指示灯舵机轴上加装白色摆臂以直观呈现门体的开启与闭合左侧竖直安装 ESP32-CAM 图像模块摄像头朝向通行方向下方为 STM32F103C8T6 核心板其 Micro-USB 接口兼作供电与程序下载之用左上方为红外对管的发射与接收组件。整机尺寸紧凑便于在实验室或演示环境中复现完整通行流程。图 5 硬件实物俯视全景射频读卡、核心板、图像模块、舵机、蜂鸣器与 LED 的整体布局图 6 硬件实物斜视视角模块堆叠层次与板面焊接关系2.4 通行流程与门禁控制逻辑系统的运行围绕「一次通行」的生命周期展开可拆为门禁开通与日常通行两个阶段。门禁开通阶段由申请发起学生在小程序端完成用户注册与登录在个人中心绑定人脸照片与校园卡号随后提交账户开通或延期申请申请携带申请人、班级、有效期与申请事由一并进入管理员的待审批列表管理员在 Web 端的账号审批页面逐条核验填写审批事由后选择审核通过或审核驳回审批结论与有效期随之写入该账户门禁权限自此生效。日常通行阶段由身份识别发起行人刷卡时主控经 SPI 读取卡片的 UID与有效名册比对后直接作出放行或拒绝的裁决此过程不依赖网络行人面向摄像头时主控指令 ESP32-CAM 抓拍现场图像并经 REST 方式上传服务端服务端调用人脸检测与识别算法完成特征比对把比对结果与放行指令经 TCP Socket 回传主控主控据此驱动舵机、LED 与蜂鸣器。两条通道的验证结论在记录中被明确区分为「刷卡通行」与「刷脸通行」使每一次放行的依据都可回溯。运行环节触发条件现场动作记录变化刷卡通行校园卡靠近 MFRC522 感应区主控读取卡片 UID 并比对有效名册舵机开启门体绿灯亮起、蜂鸣器短鸣写入通行记录通行方式标注为「刷卡通行」并留存卡号刷脸通行行人面向 ESP32-CAM 且红外对管给出到位信号抓拍现场图像上传服务端完成人脸比对比对通过后舵机开启门体写入通行记录通行方式标注为「刷脸通行」并留存抓拍照片拒绝通行卡片不在名册内、账户已停用或人脸比对未通过门体保持关闭红灯亮起、蜂鸣器告警不产生通行记录仅在现场给出声光提示账户开通学生在小程序提交开通申请并附带申请事由申请进入 Web 端待审批列表管理员核验后填写审批事由并作出结论账户状态与有效期写入同时生成一条账户操作记录账户延期账户临近有效期学生在小程序提交延期申请申请记录中标注申请变更状态为「正常」并载明申请有效期审批通过后有效期顺延按新的到期日重新计时到期停用账户有效期届至该账户的识别结果不再放行门体保持关闭账户状态由「正常」转为「停用」权限自动失效远程开闸管理员在 Web 端实时数据页面点击单次开闸服务端下发开闸指令主控驱动舵机开启门体一次计入当日通行次数统计这一流程中有两处设计值得说明。第一处是有效期作为独立字段参与权限判定而非仅由账户状态决定——系统中每个账户都带有明确的到期日实测记录中出现了 2026-04-28、2026-05-06、2027-04-28 等取值到期后权限自动失效不需要管理员逐条手工停用这直接对应了毕业、转专业与短期访客等场景下的权限回收需求。第二处是审批事由与申请事由构成一对必填字段——学生的申请需要写明缘由管理员的审批同样需要填写事由实测中若审批事由留空系统会直接弹出「审批事由不能为空请重新填写」的提示并阻止提交。把双方的理由都固化到记录里使权限的授予与收回不再是一个无法追溯的操作动作。2.5 通信协议与数据交互时序系统的通信设计采用「图像走 REST、指令走 TCP」的双通道方案。图像上传属于一次性大体积数据传送由 ESP32-CAM 以 HTTP POST 请求提交至服务端 8889 端口的上传接口服务端完成接收与落盘后调用人脸检测识别算法输出比对结论卡号上报、识别结果、放行指令与参数配置等小体积、高时效性信息则通过 TCP Socket 透传服务端监听 19214 端口保证控制指令的低延迟下发。硬件侧按预设的热点名称与口令接入局域网演示时由上位机开启热点即可完成组网需注意图像模块仅支持 2.4 GHz 频段并保持热点名称与固件配置一致。数据方向承载方式配置参数载荷内容硬件 → 服务端RESTHTTP POST 请求服务端口 8889上传接口路径 /f/esp32/upload现场抓拍的人脸图像由 ESP32-CAM 直接发起硬件 → 服务端TCP Socket 透传服务端端口 19214终端编号、校园卡号等身份信息上报服务端 → 硬件TCP Socket 透传同上人脸比对结果、门体动作指令与参数配置服务端 → Web 端业务数据接口—实时状态、通行记录、账户与权限数据、审批流转服务端 → 小程序业务数据接口—本人的通行记录、账户变更记录与申请提交结果2.5.1 报文样例取自实机串口调试记录可直接复制上行报文为「Client 终端编号 card 卡号 end」形式以分隔字段、以#结束ClientZDBH01card0516096168end#下行指令为「C 终端编号 _ 指令字 参数 #」形式指令字K与F分别对应门体的两种动作状态CZDBH01_K000000# CZDBH01_F00000#指令面板中另有两条与系统相关的交互帧Clientphotoend#为手动触发抓拍、883xswsoftbs20262026end#为服务端鉴权字段Clientphotoend# 883xswsoftbs20262026end#报文采用定界符切分的纯文本格式单片机上无需引入编解码库用串口调试助手即可直接观察链路状态。从通信调试记录可以直接观察到这套协议的组织形式。上行报文形如「Client 终端编号 card 卡号 end」实测样例为 ClientZDBH01card0516096168end即终端 ZDBH01 上报了一次卡号为 0516096168 的刷卡事件下行指令形如「C 终端编号 指令字 参数 #」实测样例中出现了 CZDBH01_K00000 与 CZDBH01_F00000 两种形式其中指令字 K 与 F 分别对应门体的两种动作状态。报文以「#」作为结束符以「」作为字段分隔符结构简单且便于在单片机上解析——这种以定界符切分的纯文本协议不需要额外的编解码开销也便于直接使用串口调试工具观察链路状态。说明图像模块的拍摄间隔可配置实测为 10 秒图像经 HTTP POST 提交至服务端 8889 端口的上传接口热点的默认名称与口令随源码交付文档一并提供此处不再列出。图 7 系统数据交互时序刷卡与刷脸两条识别通道、台账链路与拒绝通行链路一次完整的「识别—验证—放行—留痕」过程可分解为十个阶段身份触发行人刷卡或走近人脸识别区MFRC522 读取卡片 UID 或红外对管给出到位信号现场处理主控完成卡号与本地名册的比对或指令 ESP32-CAM 抓拍现场人脸图像图像上传ESP32-CAM 以 RESTPOST 请求把图像提交至服务端 8889 端口的上传接口人脸比对服务端调用人脸检测与识别算法与人员档案中绑定的人脸照片完成特征比对结果回传比对结论与放行指令经 TCP Socket 透传至主控现场联动舵机开启门体并延时自动闭合LED 与蜂鸣器同步给出状态反馈记录入库通行记录含姓名、卡号、终端编号 ZDBH01、通行方式、抓拍照片与时间写入数据库记录推送记录同步至 Web 端与小程序管理员可查全量记录师生仅可查本人记录账户申请学生在小程序提交账户状态变更或延期申请经 Web 端审批通过后生效参数同步账户状态、有效期与终端参数周期性同步至现场闸机。三、系统界面展示Web 管理端为系统的配置与监控入口采用「顶栏 左侧导航 右侧内容区」的经典后台布局导航区固定提供参数管理、闸机管理与用户管理系统管理以及实时数据查询、通行记录查询、账户操作记录与账号审批业务管理七个入口页面以多标签方式并存可在多个功能之间快速切换。系统以账号口令方式登录未登录用户无法访问任何业务页面。图 8 Web 管理端登录界面参数管理与闸机管理两个页面承担系统的配置职责。参数管理以「参数名称 / 类型 / 参数值 / 备注」的形式集中维护业务参数实测配置中登记了三条班级信息参数取值分别为计算机 2201、计算机 2202 与计算机 2203——把班级以参数项而非硬编码的方式管理使招生年份变化或专业调整时不需要修改任何代码闸机管理维护现场的通行终端每条记录展示终端编号、终端名称、安装地址、在线状态与更新时间实测登记的终端编号为 ZDBH01、终端名称为「闸机」、安装地址为「校园大门口」在线状态以高亮标签形式给出。该终端编号同时出现在通行记录与账户操作记录中使多终端场景下的记录归属具备可追溯性。图 9 参数管理上与闸机管理下业务参数集中维护与终端信息登记用户管理与编辑用户信息管理共同构成人员档案的维护入口。用户管理页面按行列出全部账户字段包含姓名、电话、照片路径、班级、卡号RFID、账户有效期、账户状态、更新时间与操作并支持按姓名或电话检索以及提交审核、撤销审核与新增账户。实测名册中共有 5 条记录可直接看出权限状态的分布傅浩洛17680404693计算机 2201卡号 51609618有效期至 2026-05-06状态为「正常」朱老师18033333333计算机 2201有效期至 2027-04-28状态同为「正常」而何鑫怡、朱天赫、傅洋三人的状态为「停用」——其中朱天赫仍绑定了卡号 10A0AF62、傅洋绑定了卡号 91260C15说明停用是账户状态的变更而非档案的删除历史绑定信息得以保留。照片路径字段以缩略图形式直接呈现已绑定的人脸照片未绑定照片的记录显示为占位图标一眼即可分辨档案的完整程度。图 10 用户管理上与编辑用户信息管理下账户名册与人脸 / 卡号绑定实时数据查询是系统的监控主界面。页面顶部为「实时状态」卡片区并列给出闸机状态与当日通行次数两项指标并标注数据的刷新时刻其下为「远程控制」区提供「远程开闸」入口与「单次开闸」按钮可在不接触现场设备的情况下放行一次通行。实测截图的数据刷新时刻为 2026-04-29 20:51:54受控终端为「闸机」闸机状态为「关闭」当日通行次数累计 9 次。把终端状态、通行计数与远程控制集中在同一屏使管理员无需前往现场即可判断闸机是否在线、当日通行是否正常。图 11 实时数据查询界面闸机状态、当日通行次数与远程单次开闸通行记录查询页面按时间倒序汇集全部通行事件字段覆盖了身份、时间与凭据三类要素姓名、电话、班级、卡号RFID、终端编号、终端名称、照片、处理后照片、结果、通行方式与更新时间并支持按终端编号或终端名称检索。「照片」与「处理后照片」两列直接嵌入抓拍的缩略图前者为服务端接收到的原始画面后者为经过人脸检测处理后的图像二者并置使「拍到了什么」与「识别用了什么」可以直接对照点击缩略图会弹出「查看图片」窗口展示原始尺寸的画面便于人工复核识别结果。实测记录中傅浩洛于 2026-04-29 06:45 以「刷卡通行」方式通过携带卡号 51609618该行的处理后照片显示为「暂无照片」——这正是刷卡通道的特征识别依据是卡片而非图像因此不产生人脸抓拍而朱天赫在同一时段的连续记录则以「刷脸通行」方式通过卡号字段为空照片与处理后照片两列均有内容。页面底部显示共 21 条记录、按每页 20 条分页。图 12 通行记录查询界面原始照片与处理后照片并列通行方式区分刷卡与刷脸图 13 通行记录查看图片点击缩略图后弹出的原始尺寸抓拍画面账户操作记录页面记录了每一次账户状态变更的完整轨迹字段包含姓名、电话、班级、操作类型、操作人与变更时间。操作类型覆盖了审批与变更两类动作实测记录中出现了「管理员审批已审批用户状态为正常」、「管理员审批审批不通过用户状态为停用」、「用户申请变更账户状态【正常】有效期为 2026-05-06」、「用户申请变更账户状态【停用】有效期为 2026-04-30」、「管理员手动停用」与「管理员操作启用」六种表述。把这些取值放在一起可以看到一条清晰的分工线由「用户申请」发起的记录对应学生的主动请求由「管理员审批」发起的记录对应管理员的裁决由「管理员手动」发起的记录对应无需申请的即时操作——操作人字段区分了「管理员」与「超级管理员」两种角色实测页面共 23 条记录能够完整还原一个账户在数日内的权限变化过程。图 14 账户操作记录管理界面申请、审批与手动操作的全过程留痕账号审批是权限链条的闸口。页面按行列出待处理的申请字段包含姓名、电话、照片路径、班级、卡号RFID、账户有效期、账户状态、申请变更状态、申请有效期与审批事由顶部提供「审核通过」与「审核驳回」两个操作按钮。与用户管理页面相比这里的字段多出了「申请变更状态」「申请有效期」与「审批事由」三项——它们正是申请与审批这一对动作所留下的痕迹申请方提出希望变更为什么状态、期望的有效期到哪一天审批方则填写作出结论的理由。实测截图中傅浩洛的记录显示账户状态为「正常」、申请变更状态为「停用」、申请有效期为 2026-05-06、审批事由为「离职」呈现出一条完整的待审批申请而若审批事由留空便直接提交系统会弹出「审批事由不能为空请重新填写」的提示并阻止操作把「谁基于什么理由批准了这次权限变更」固化为一条不可省略的记录。图 15 账号审批界面上与审批事由必填校验下3.1 微信小程序端微信小程序面向持卡师生以 webview 控件调用 H5 页面的方式实现与 Web 管理端共享同一套业务接口与数据源。登录页提供账号与口令输入底部附注册入口学生可自行注册账号后提交开通申请无需管理员代为建档。登录后的首页以宫格方式提供通行记录、账号延期、审批记录查询与个人中心四个入口底部以标签栏在「首页」与「个人中心」之间切换。图 16 小程序登录页左与首页功能导航右历史数据查询以卡片列表的形式呈现本人的通行记录每条记录列出人员、班级、手机号、卡号RFID、通行方式与终端并在右上角标注通行时间。卡片的字段随通行方式自适应刷卡通行会显示具体卡号如实测记录中的 51609618刷脸通行则把卡号字段显示为「---」同时在卡片右侧嵌入当次的人脸抓拍照片终端字段统一显示为「ZDBH01闸机」与 Web 端的终端登记保持一致。用户数据查询则对应账户的变更轨迹每条记录列出用户、时间、电话、班级与变更内容实测记录中出现了「管理员审批已审批用户状态为正常」、「管理员审批审批不通过用户状态为正常」与「用户申请变更账户状态【停用】有效期为 2026-05-06」三类表述。这两个页面的共同特点是只呈现与本人相关的数据与 Web 端面向管理员的全量视图形成明确的信息边界。图 17 小程序历史数据查询左与用户数据查询右本人通行记录与账户变更轨迹账户申请与个人信息两个页面是小程序端唯一的写入入口。账户申请页面分为「基本信息」与「延期申请」两段上半段以只读方式回显审批状态、姓名、电话、班级、卡号、账户有效期与账户状态实测中审批状态显示为「已审批」下半段为延期申请表单由学生自行填写期望的账户有效期、账户状态与申请事由提交后进入 Web 端的待审批列表。个人信息页面则是档案的维护入口姓名、电话、班级、卡号、账户有效期与账户状态六项均为可编辑字段下方提供图片上传区已绑定的人脸照片直接显示在上传区上方支持点击选择或拖拽上传每次上传限一张。把「改档案」与「改权限」拆成两个页面是本系统在权限设计上的一条隐含约束——学生可以修改自己的联系方式与人脸照片但账户的有效期与生效状态必须经由申请与审批流程才能变更。图 18 小程序账户申请左与个人信息右延期申请表单与人脸照片绑定入口3.2 图像模块参数配置与通信调试ESP32-CAM 的工作参数经串口配置工具下发配置项涵盖无线接入信息、服务端地址与端口、上传接口、闪光灯开关、自动拍照开关、调试模式、水平镜像与垂直反转、拍摄间隔等。实测配置中无线热点名称为 8266wifi服务器地址为本机局域网地址Socket 端口为 19214上传接口路径为 /f/esp32/upload对应服务端 8889 端口闪光灯开启垂直反转开启而水平镜像关闭——反转参数的取值由模块的实际安装方向决定拍摄间隔为 10 秒而自动拍照处于关闭状态这一点与系统的设计意图一致抓拍由主控在检测到行人到位时按需触发而非由图像模块周期性自行采集从而避免无效图像持续占用带宽与存储。配置工具同时给出串口参数端口 COM33、波特率 115200、数据位 8、无校验、停止位 1。图 19 ESP32-CAM 模块配置无线接入、服务端地址与图像输出参数链路的实际运行状态可通过串口网络调试工具直接观察。调试工具以 TCP Server 方式在本机 19214 端口监听与现场硬件建立连接后接收区按时间顺序打印出全部上报报文与下行指令。实测记录中可以看到硬件启动后先输出固件信息与运行参数ELF 校验值、Wi-Fi 名称、服务器 IP、Socket 端口、上传地址、闪光灯与拍摄间隔等随后开始周期性上报状态与刷卡事件本机作为服务端在接收到连接后向硬件下发开闸指令并得到状态回执接收计数与发送计数分别累计使链路的连通性与报文收发情况可以直观核对。在调试阶段「上行报文的字段是否完整」与「下行指令是否被硬件正确执行」这两个问题往往决定了整个系统的联调效率而把上报与下发都打印在同一屏上是一线调试中最直接有效的手段。图 20 串口网络通信调试TCP Server 监听、上报报文与下行开闸指令四、系统视频展示为便于完整呈现软硬件的联动过程项目配套录制了功能演示视频。视频以屏幕录制与实机拍摄交替切换的方式依次演示以下环节硬件上电并与服务端建立 TCP 连接Web 端实时数据页面随即显示闸机状态与当日通行次数学生在小程序端注册登录在个人信息页面绑定人脸照片与校园卡号随后提交账户开通申请管理员在 Web 端账号审批页面核验信息、填写审批事由并审核通过行人持卡靠近 MFRC522 感应区舵机开启门体、绿灯亮起、蜂鸣器短鸣Web 端通行记录页面新增一条标注为「刷卡通行」的记录行人面向 ESP32-CAM 完成人脸识别门体再次开启通行记录中新增一条标注为「刷脸通行」的记录并附带抓拍照片与处理后照片使用已停用的账户尝试通行门体保持关闭并触发红灯与告警音最后演示账户延期申请的提交与审批以及 Web 端的远程单次开闸。项目视频按用途提供多个版本供平台发布的完整演示版本、无水印版本用于二次编辑与嵌入其他材料以及适配移动端播放的压缩版本。建议的观看顺序为先观看完整演示版本建立整体印象再对照图 7 的数据交互时序图理解刷卡、刷脸与台账三条链路的关系最后结合图 3 与图 4 复核硬件连接与引脚分配。视频文件随项目资料一并提供如需对照源码调试建议同时打开图 10 与图 15 的界面截图把视频中出现的账户与审批记录同界面字段逐项比对。五、获取方法源码与技术资料获取在本文评论区留言或通过 B站 站内私信说明需求说明需要的是「源码 原理图 硬件实物」的完整套装还是其中的单项资料收到回复后按指引提供接收方式资料将由专人整理打包后发送如需环境搭建协助或二次开发支持可在联系时一并说明具体需求。交付项内容硬件实物按原理图焊接完成的整机一套含主控、MFRC522 读卡模块、ESP32-CAM、舵机、红外对管、蜂鸣器与 LED程序源码STM32 下位机工程Keil 5、服务端工程、Web 管理端工程与小程序端页面硬件原理图嘉立创 EDA 工程文件及 PCB、PDF 与图片导出演示视频功能演示视频提供完整版、无水印版与移动端适配版文档资料接线说明、图像模块参数配置说明、通信协议说明与业务流程说明源码获取、技术支持请联系微信【xswzls】微信公众号小豆豆物联网。项目的资料整理、硬件调试与技术支持由「小豆豆物联网」提供。附录 A ESP32-CAM 模块配置帧可直接复制模块工作参数经串口配置工具一次性下发帧以config开头、以#结束字段顺序为热点名称、热点口令、服务器 IP、Socket 端口、上传地址、闪光灯、自动拍照、调试模式、水平镜像、垂直反转、拍摄间隔。config8266wifi123456789192.168.137.25019214http://192.168.137.250:8889/f/esp32/uploadtruefalsefalsefalsetrue10end#下发该帧后模块回传启动日志与生效参数WiFi 名称 : 8266wifi WiFi 密码 : 123456789 服务器 IP : 192.168.137.250 Socket 端口 : 19214 上传地址 : http://192.168.137.250:8889/f/esp32/upload 闪光灯 : true 自动拍照 : false 调试模式 : false 水平镜像 : false 垂直反转 : true 拍摄间隔(秒) : 10串口参数模块侧COM33 / 115200 / 8 / N / 1上位机串口网络调试助手侧COM3 / 9600 / 8 / N / 1。附录 B TCP 调试要点上位机以TCP Server方式在192.168.137.250:19214监听现场硬件作为客户端接入调试记录中连接对象为192.168.137.146:59发送计数 117、接收计数 270可据此核对链路连通性与报文收发是否成对。附录 C 素材说明配图 20 张自绘 4 张图 1 系统总体架构、图 2 系统功能结构、图 3 硬件系统原理框图、图 7 系统数据交互时序真实素材 16 张。原理图由Schematic_..._2026-04-26.pdf以 1800 宽渲染并裁白边未使用同目录下的_2026-04-15.pdf内容等价。演示视频位于01视频演示\无水印版\...-w.mp4与水印版\...m4vB站版本\为空目录且无封面图故「四、系统视频展示」写成演示环节清单形式。 校园行人出入管理系统设计与实现｜X604131
校园出入口管理的核心矛盾在于「通行效率」与「权限约束」之间的平衡既要让持卡师生以最短的停留时间通过又要保证每一次放行都发生在有效授权之内。本系统以 STM32F103C8T6 为现场控制核心构建了刷卡与人脸两条并行的身份识别通道——前者由 MFRC522 读取校园卡唯一 UID 完成本地校验后者由 ESP32-CAM 采集现场图像上传服务端经人脸检测与特征比对完成远程核验两条通道的验证结果统一交由主控裁决再由 SG90 舵机执行门体开合LED 与蜂鸣器给出通行状态的即时反馈。权限与台账则落在 Web 管理端与微信小程序两端学生自行注册并提交开通或延期申请管理员审批后权限方才生效到期自动停用通行记录与账户变更记录全程留痕可逐条追溯。本文面向希望复现或二次开发的读者按「一、项目基本情况 → 二、系统架构设计 → 三、系统界面展示 → 四、系统视频展示 → 五、获取方法」组织其中通信报文与模块配置帧均取自实机调试记录可直接复制使用。技术栈速览层次选型说明现场控制STM32F103C8T6Cortex-M3 72 MHzKeil 5 开发硬件 SPI GPIO 串口刷卡识别MFRC52213.56 MHzSPI 接口读取校园卡唯一 UID人脸采集ESP32-CAMOV2640 Wi-Fi串口接主控独立以 HTTP POST 上传图像门体执行SG90 舵机PWMPA8控制转角通行检测对射式红外对管OUT → PB8遮挡触发通行事件反馈有源蜂鸣器 LED 指示灯PB1 / PB0声响与视觉双通道服务端JeeSite 平台 Java SpringBoot MySQLTCP Socket 服务 人脸检测识别调度前端BootstrapWeb 管理端 / 微信小程序webview 调 H5与 Web 端共享业务接口人脸算法虹软人脸 SDK人脸检测与特征比对通信采用双通道图像走 HTTP POST8889 端口/f/esp32/upload指令与状态走 TCP Socket19214 端口。一、项目基本情况校园行人出入管理长期依赖人工核验或单一识别手段。人工核验在上下课时段形成明显的通行瓶颈而仅使用校园卡识别时卡片可被转借识别结果无法确认持卡人身份仅使用人脸识别时又容易受光照、姿态与遮挡影响在逆光或快速通行场景下稳定性不足。更关键的是权限管理往往与识别环节彼此割裂——学生毕业、转专业或休学后原卡仍可能在门禁上继续有效权限的变更缺乏一条可追溯的流程与记录。本项目的设计出发点正是把「身份识别—权限判定—门体执行—记录留痕」收敛到同一条数据链路上使每一次放行都同时具备效率与可审计性。1.1 设计目标与技术路线系统的设计目标可归纳为三点。其一以刷卡与人脸构成两条并行的身份识别通道——MFRC522 通过 SPI 接口读取校园卡的唯一 UID与本地台账比对完成快速校验承担高频次、低时延的日常通行ESP32-CAM 采集现场人脸图像上传服务端由服务端的人脸检测与识别算法完成特征比对承担身份确认与防转借的职责。两条通道互为补充刷卡保证通行效率人脸保证身份真实任一条通过即形成一次完整的验证结论其二以申请—审批流程约束门禁权限——学生在小程序端自行注册账号并提交开通或延期申请申请进入管理员的待审批列表经审核通过后门禁权限方才生效并附带明确的有效期到期自动停用从根本上避免权限的无限期滞留其三以记录留痕支撑事后追溯——每一次通行都会写入一条包含姓名、卡号、通行方式、抓拍照片与终端编号的记录每一次账户状态变更同样写入操作记录使「谁在何时以何种方式通过」与「谁在何时批准了谁的权限」都有据可查。技术路线上系统采用「嵌入式控制节点 无线图像与数据通道 服务端识别与存储 Web 与小程序双端」的分层结构。现场节点以 STM32F103C8T6 为核心经 SPI 挂载 MFRC522 射频读卡模块经 GPIO 驱动红外对管、蜂鸣器、LED 与 SG90 舵机经串口接入 ESP32-CAM 图像模块使用 Keil 5 完成下位机开发各功能模块以自制 PCB 为载体互连人脸图像由 ESP32-CAM 以 RESTPOST 请求方式直接提交服务端的上传接口不经过主控中转避免了图像数据占用主控的存储空间与串口带宽卡号上报、识别结果、放行指令与参数配置等小体积数据则通过 TCP Socket 在硬件与服务端之间透传服务端基于 JeeSite 平台与 Java SpringBoot 构建以 MySQL 完成业务数据持久化并通过虹软 SDK 实现人脸检测与识别Web 管理端采用 Bootstrap 前端框架微信小程序则以 webview 控件调用 H5 页面的方式实现与 Web 端共享同一套业务接口。1.2 系统总体架构系统在纵向上划分为四个层次自下而上依次为感知执行层、边缘控制层、网络与识别层、应用层。感知执行层由 MFRC522 射频读卡模块、ESP32-CAM 图像模块、红外对管、SG90 舵机、蜂鸣器与 LED 指示灯组成分别承担身份信息采集、通行事件检测、门体动作执行与状态反馈边缘控制层由 STM32F103C8T6 承担完成校园卡 UID 的读取与人脸验证结果的判定、门体开合的时序控制、蜂鸣器与 LED 的反馈调度以及串口与 TCP Socket 的通信调度网络与识别层由 ESP32-CAM、REST 图像上传通道、TCP Socket 指令通道与服务端的人脸检测识别服务共同构成承担图像上行、特征比对与结果下行应用层由服务端、Web 管理端与微信小程序承载负责权限维护、审批流转、记录呈现与查询检索。四层之间以图像上行与指令下行两条路径耦合形成从身份识别到放行、再到记录入库的完整闭环。图 1 系统总体架构感知执行、边缘控制、网络与识别、应用四层结构1.3 系统功能构成从功能视角看系统可切分为硬件系统、软件系统与交付服务三个维度。硬件系统沿「识别—执行—反馈—通信」四条主线展开识别环节由 MFRC522 与 ESP32-CAM 组成执行环节由 SG90 舵机组成反馈环节由 LED 指示灯与蜂鸣器组成通信环节由 ESP32-CAM 的图像上行与 TCP Socket 的指令下行组成软件系统分为 Web 管理端、微信小程序与服务端三部分Web 管理端在系统管理维度提供闸机管理、参数管理与人员管理含人脸绑定、卡号绑定与启用停用在业务管理维度提供实时数据显示含远程控制、通行记录查询、账户维护记录查询与账号审批四类功能微信小程序面向持卡师生提供用户登录注册、宫格导航、通行记录查询、账户变更记录查询与个人中心含人脸绑定、账户申请与延期申请服务端承担 TCP Socket 服务、与硬件的周期性数据同步以及人脸检测与识别调度交付内容包含硬件实物、软硬件程序源码、硬件原理图与功能演示视频。图 2 系统功能结构硬件系统、软件系统与交付服务三个维度1.4 硬件构成与器件选型硬件选型遵循「接口明确、职责单一、成本可控」的原则。主控选用 STM32F103C8T6其 Cortex-M3 内核运行于 72 MHz具备充足的 GPIO 资源与硬件 SPI 接口可同时挂载射频读卡、舵机、指示灯、蜂鸣器与图像模块身份识别选用 MFRC522 射频读卡模块工作于 13.56 MHz 频段经 SPI 接口与主控通信读取校园卡的唯一 UID 用于身份判据人脸采集选用 ESP32-CAM兼具摄像头接口与 Wi-Fi 能力可在单片上完成图像获取与上传是本系统唯一具备联网能力的现场节点门体动作选用 SG90 舵机模拟其转角由 PWM 信号直接给定便于演示门体开启与闭合的完整动作通行检测选用对射式红外对管行人通过门体时红外光路被遮挡输出电平跳变构成通行事件的计数依据状态反馈由 LED 指示灯与有源蜂鸣器共同承担以视觉与听觉两条通道同时给出验证结果。各器件的具体接口对应关系如下表所示。器件型号 / 规格接口与引脚功能定位主控 MCUSTM32F103C8T6Cortex-M372 MHz—系统控制核心Keil 5 开发射频读卡MFRC522 XSWU4SPISDA→PA7SCK→PA6MOSI→PA5MISO→PA4RST→PA13.3 V读取校园卡唯一 UID作为刷卡通行通道的身份判据图像采集ESP32-CAMU10串口模块 RX→PA9模块 TX→PA105 V现场人脸图像采集经 RESTPOST上传服务端通行检测对射式红外对管U3GPIOOUT→PB85 V检测行人通过门体为通行记录提供事件触发门体执行SG90 舵机U6GPIO / PWMPWM→PA85 V执行门体的开启与闭合动作声响反馈有源蜂鸣器BUZZER2GPIO信号端→PB1验证成功、失败与异常告警的声响提示视觉反馈LED 指示灯LED23 mm 红色GPIOPB0 → 1 kΩ 限流电阻通行状态与验证结果的视觉指示供电单元5 V / 3.3 V 双路供电Micro-USB 取电5 V 供舵机、红外对管与图像模块3.3 V 供读卡模块全系统共地需要说明两条识别通道在系统里的分工刷卡通道回答的是「这张卡是否在有效名册内」属于确定性的本地比对响应时间在毫秒量级适合上下课时段的高并发通行人脸通道回答的是「站在闸机前的这个人是否与档案中的持卡人一致」属于外部算力参与的特征比对需要一次图像上传与服务端往返适合作为身份确认与防转借的补充手段。把「卡」与「人」两类身份凭据分别交由两个器件采集使主控的裁决逻辑得以简化为「任一条通道通过即放行、两条通道均未通过则拒绝」的单一判据。二、系统架构设计2.1 硬件系统结构与引脚分配硬件以 STM32F103C8T6 为中枢左侧为感知输入通道右侧为执行与反馈通道下方为供电单元。输入侧汇集 MFRC522 读卡模块、ESP32-CAM 图像模块与红外对管三路信号输出侧驱动 SG90 舵机、有源蜂鸣器与 LED 指示灯。其中 ESP32-CAM 在系统中具有「传感器」与「通信模块」的双重身份它既经串口接收主控的抓拍指令又独立承担与服务端之间的图像上传使图像数据无需占用主控的存储与串口带宽。引脚分配上MFRC522 占用主控的硬件 SPI 引脚组PA5 至 PA7与一根复位控制线PA1ESP32-CAM 与主控以串口交叉相连模块侧的 RX 接 PA9、TX 接 PA10红外对管的输出接入 PB8舵机的 PWM 信号接入 PA8蜂鸣器与 LED 分别占用 PB1 与 PB0二者之间不存在引脚复用。舵机回路属于冲击性负载其供电走线与射频读卡模块的弱信号通路分开布置避免舵机启动瞬间的电流跳变影响 SPI 时序与卡号判读。图 3 硬件系统原理框图主控、识别与检测输入、执行与反馈输出、供电单元2.2 硬件原理图原理图使用嘉立创 EDA 绘制按功能划分为 MFRC522 射频读卡单元、ESP32-CAM 图像单元、STM32F103C8T6 核心板单元、LED 指示单元、SG90 舵机单元、红外对管单元与蜂鸣器单元等功能区块。射频读卡模块采用 SPI 接口SDA、SCK、MOSI、MISO 分别接至 PA7、PA6、PA5、PA4复位线接至 PA1模块工作电压为 3.3 V其 IRQ 引脚在本系统中未使用图像模块的串口与主控交叉相连——模块的 IO3RX接 PA9模块的 IO1TX接 PA10模块由 5 V 供电其余 IO 引脚在本系统中悬空舵机的 PWM 信号接至 PA8由定时器输出脉宽可调的方波控制转角红外对管的输出接至 PB8供电取 5 VLED 指示灯串联 1 kΩ 限流电阻后接至 PB0蜂鸣器的信号端接至 PB1另一端接 GND。核心板右列的 3.3 V、5 V 与 GND 引脚为各功能模块提供统一供电各外设均就近去耦。原理图同时提供源文件、PDF 与图片等多种格式便于直接投板打样或二次修改。图 4 硬件原理图嘉立创 EDA 绘制含 STM32F103C8T6、MFRC522、ESP32-CAM、SG90 舵机、红外对管、蜂鸣器与 LED2.3 硬件实物实物按原理图在自制 PCB 上焊接完成板面以四角尼龙柱支撑各功能模块通过排针与端子连接。板面中部为 MFRC522 射频读卡模块天线圈位于模块正面卡片靠近即可完成读取右侧依次布置 SG90 舵机、有源蜂鸣器与 LED 指示灯舵机轴上加装白色摆臂以直观呈现门体的开启与闭合左侧竖直安装 ESP32-CAM 图像模块摄像头朝向通行方向下方为 STM32F103C8T6 核心板其 Micro-USB 接口兼作供电与程序下载之用左上方为红外对管的发射与接收组件。整机尺寸紧凑便于在实验室或演示环境中复现完整通行流程。图 5 硬件实物俯视全景射频读卡、核心板、图像模块、舵机、蜂鸣器与 LED 的整体布局图 6 硬件实物斜视视角模块堆叠层次与板面焊接关系2.4 通行流程与门禁控制逻辑系统的运行围绕「一次通行」的生命周期展开可拆为门禁开通与日常通行两个阶段。门禁开通阶段由申请发起学生在小程序端完成用户注册与登录在个人中心绑定人脸照片与校园卡号随后提交账户开通或延期申请申请携带申请人、班级、有效期与申请事由一并进入管理员的待审批列表管理员在 Web 端的账号审批页面逐条核验填写审批事由后选择审核通过或审核驳回审批结论与有效期随之写入该账户门禁权限自此生效。日常通行阶段由身份识别发起行人刷卡时主控经 SPI 读取卡片的 UID与有效名册比对后直接作出放行或拒绝的裁决此过程不依赖网络行人面向摄像头时主控指令 ESP32-CAM 抓拍现场图像并经 REST 方式上传服务端服务端调用人脸检测与识别算法完成特征比对把比对结果与放行指令经 TCP Socket 回传主控主控据此驱动舵机、LED 与蜂鸣器。两条通道的验证结论在记录中被明确区分为「刷卡通行」与「刷脸通行」使每一次放行的依据都可回溯。运行环节触发条件现场动作记录变化刷卡通行校园卡靠近 MFRC522 感应区主控读取卡片 UID 并比对有效名册舵机开启门体绿灯亮起、蜂鸣器短鸣写入通行记录通行方式标注为「刷卡通行」并留存卡号刷脸通行行人面向 ESP32-CAM 且红外对管给出到位信号抓拍现场图像上传服务端完成人脸比对比对通过后舵机开启门体写入通行记录通行方式标注为「刷脸通行」并留存抓拍照片拒绝通行卡片不在名册内、账户已停用或人脸比对未通过门体保持关闭红灯亮起、蜂鸣器告警不产生通行记录仅在现场给出声光提示账户开通学生在小程序提交开通申请并附带申请事由申请进入 Web 端待审批列表管理员核验后填写审批事由并作出结论账户状态与有效期写入同时生成一条账户操作记录账户延期账户临近有效期学生在小程序提交延期申请申请记录中标注申请变更状态为「正常」并载明申请有效期审批通过后有效期顺延按新的到期日重新计时到期停用账户有效期届至该账户的识别结果不再放行门体保持关闭账户状态由「正常」转为「停用」权限自动失效远程开闸管理员在 Web 端实时数据页面点击单次开闸服务端下发开闸指令主控驱动舵机开启门体一次计入当日通行次数统计这一流程中有两处设计值得说明。第一处是有效期作为独立字段参与权限判定而非仅由账户状态决定——系统中每个账户都带有明确的到期日实测记录中出现了 2026-04-28、2026-05-06、2027-04-28 等取值到期后权限自动失效不需要管理员逐条手工停用这直接对应了毕业、转专业与短期访客等场景下的权限回收需求。第二处是审批事由与申请事由构成一对必填字段——学生的申请需要写明缘由管理员的审批同样需要填写事由实测中若审批事由留空系统会直接弹出「审批事由不能为空请重新填写」的提示并阻止提交。把双方的理由都固化到记录里使权限的授予与收回不再是一个无法追溯的操作动作。2.5 通信协议与数据交互时序系统的通信设计采用「图像走 REST、指令走 TCP」的双通道方案。图像上传属于一次性大体积数据传送由 ESP32-CAM 以 HTTP POST 请求提交至服务端 8889 端口的上传接口服务端完成接收与落盘后调用人脸检测识别算法输出比对结论卡号上报、识别结果、放行指令与参数配置等小体积、高时效性信息则通过 TCP Socket 透传服务端监听 19214 端口保证控制指令的低延迟下发。硬件侧按预设的热点名称与口令接入局域网演示时由上位机开启热点即可完成组网需注意图像模块仅支持 2.4 GHz 频段并保持热点名称与固件配置一致。数据方向承载方式配置参数载荷内容硬件 → 服务端RESTHTTP POST 请求服务端口 8889上传接口路径 /f/esp32/upload现场抓拍的人脸图像由 ESP32-CAM 直接发起硬件 → 服务端TCP Socket 透传服务端端口 19214终端编号、校园卡号等身份信息上报服务端 → 硬件TCP Socket 透传同上人脸比对结果、门体动作指令与参数配置服务端 → Web 端业务数据接口—实时状态、通行记录、账户与权限数据、审批流转服务端 → 小程序业务数据接口—本人的通行记录、账户变更记录与申请提交结果2.5.1 报文样例取自实机串口调试记录可直接复制上行报文为「Client 终端编号 card 卡号 end」形式以分隔字段、以#结束ClientZDBH01card0516096168end#下行指令为「C 终端编号 _ 指令字 参数 #」形式指令字K与F分别对应门体的两种动作状态CZDBH01_K000000# CZDBH01_F00000#指令面板中另有两条与系统相关的交互帧Clientphotoend#为手动触发抓拍、883xswsoftbs20262026end#为服务端鉴权字段Clientphotoend# 883xswsoftbs20262026end#报文采用定界符切分的纯文本格式单片机上无需引入编解码库用串口调试助手即可直接观察链路状态。从通信调试记录可以直接观察到这套协议的组织形式。上行报文形如「Client 终端编号 card 卡号 end」实测样例为 ClientZDBH01card0516096168end即终端 ZDBH01 上报了一次卡号为 0516096168 的刷卡事件下行指令形如「C 终端编号 指令字 参数 #」实测样例中出现了 CZDBH01_K00000 与 CZDBH01_F00000 两种形式其中指令字 K 与 F 分别对应门体的两种动作状态。报文以「#」作为结束符以「」作为字段分隔符结构简单且便于在单片机上解析——这种以定界符切分的纯文本协议不需要额外的编解码开销也便于直接使用串口调试工具观察链路状态。说明图像模块的拍摄间隔可配置实测为 10 秒图像经 HTTP POST 提交至服务端 8889 端口的上传接口热点的默认名称与口令随源码交付文档一并提供此处不再列出。图 7 系统数据交互时序刷卡与刷脸两条识别通道、台账链路与拒绝通行链路一次完整的「识别—验证—放行—留痕」过程可分解为十个阶段身份触发行人刷卡或走近人脸识别区MFRC522 读取卡片 UID 或红外对管给出到位信号现场处理主控完成卡号与本地名册的比对或指令 ESP32-CAM 抓拍现场人脸图像图像上传ESP32-CAM 以 RESTPOST 请求把图像提交至服务端 8889 端口的上传接口人脸比对服务端调用人脸检测与识别算法与人员档案中绑定的人脸照片完成特征比对结果回传比对结论与放行指令经 TCP Socket 透传至主控现场联动舵机开启门体并延时自动闭合LED 与蜂鸣器同步给出状态反馈记录入库通行记录含姓名、卡号、终端编号 ZDBH01、通行方式、抓拍照片与时间写入数据库记录推送记录同步至 Web 端与小程序管理员可查全量记录师生仅可查本人记录账户申请学生在小程序提交账户状态变更或延期申请经 Web 端审批通过后生效参数同步账户状态、有效期与终端参数周期性同步至现场闸机。三、系统界面展示Web 管理端为系统的配置与监控入口采用「顶栏 左侧导航 右侧内容区」的经典后台布局导航区固定提供参数管理、闸机管理与用户管理系统管理以及实时数据查询、通行记录查询、账户操作记录与账号审批业务管理七个入口页面以多标签方式并存可在多个功能之间快速切换。系统以账号口令方式登录未登录用户无法访问任何业务页面。图 8 Web 管理端登录界面参数管理与闸机管理两个页面承担系统的配置职责。参数管理以「参数名称 / 类型 / 参数值 / 备注」的形式集中维护业务参数实测配置中登记了三条班级信息参数取值分别为计算机 2201、计算机 2202 与计算机 2203——把班级以参数项而非硬编码的方式管理使招生年份变化或专业调整时不需要修改任何代码闸机管理维护现场的通行终端每条记录展示终端编号、终端名称、安装地址、在线状态与更新时间实测登记的终端编号为 ZDBH01、终端名称为「闸机」、安装地址为「校园大门口」在线状态以高亮标签形式给出。该终端编号同时出现在通行记录与账户操作记录中使多终端场景下的记录归属具备可追溯性。图 9 参数管理上与闸机管理下业务参数集中维护与终端信息登记用户管理与编辑用户信息管理共同构成人员档案的维护入口。用户管理页面按行列出全部账户字段包含姓名、电话、照片路径、班级、卡号RFID、账户有效期、账户状态、更新时间与操作并支持按姓名或电话检索以及提交审核、撤销审核与新增账户。实测名册中共有 5 条记录可直接看出权限状态的分布傅浩洛17680404693计算机 2201卡号 51609618有效期至 2026-05-06状态为「正常」朱老师18033333333计算机 2201有效期至 2027-04-28状态同为「正常」而何鑫怡、朱天赫、傅洋三人的状态为「停用」——其中朱天赫仍绑定了卡号 10A0AF62、傅洋绑定了卡号 91260C15说明停用是账户状态的变更而非档案的删除历史绑定信息得以保留。照片路径字段以缩略图形式直接呈现已绑定的人脸照片未绑定照片的记录显示为占位图标一眼即可分辨档案的完整程度。图 10 用户管理上与编辑用户信息管理下账户名册与人脸 / 卡号绑定实时数据查询是系统的监控主界面。页面顶部为「实时状态」卡片区并列给出闸机状态与当日通行次数两项指标并标注数据的刷新时刻其下为「远程控制」区提供「远程开闸」入口与「单次开闸」按钮可在不接触现场设备的情况下放行一次通行。实测截图的数据刷新时刻为 2026-04-29 20:51:54受控终端为「闸机」闸机状态为「关闭」当日通行次数累计 9 次。把终端状态、通行计数与远程控制集中在同一屏使管理员无需前往现场即可判断闸机是否在线、当日通行是否正常。图 11 实时数据查询界面闸机状态、当日通行次数与远程单次开闸通行记录查询页面按时间倒序汇集全部通行事件字段覆盖了身份、时间与凭据三类要素姓名、电话、班级、卡号RFID、终端编号、终端名称、照片、处理后照片、结果、通行方式与更新时间并支持按终端编号或终端名称检索。「照片」与「处理后照片」两列直接嵌入抓拍的缩略图前者为服务端接收到的原始画面后者为经过人脸检测处理后的图像二者并置使「拍到了什么」与「识别用了什么」可以直接对照点击缩略图会弹出「查看图片」窗口展示原始尺寸的画面便于人工复核识别结果。实测记录中傅浩洛于 2026-04-29 06:45 以「刷卡通行」方式通过携带卡号 51609618该行的处理后照片显示为「暂无照片」——这正是刷卡通道的特征识别依据是卡片而非图像因此不产生人脸抓拍而朱天赫在同一时段的连续记录则以「刷脸通行」方式通过卡号字段为空照片与处理后照片两列均有内容。页面底部显示共 21 条记录、按每页 20 条分页。图 12 通行记录查询界面原始照片与处理后照片并列通行方式区分刷卡与刷脸图 13 通行记录查看图片点击缩略图后弹出的原始尺寸抓拍画面账户操作记录页面记录了每一次账户状态变更的完整轨迹字段包含姓名、电话、班级、操作类型、操作人与变更时间。操作类型覆盖了审批与变更两类动作实测记录中出现了「管理员审批已审批用户状态为正常」、「管理员审批审批不通过用户状态为停用」、「用户申请变更账户状态【正常】有效期为 2026-05-06」、「用户申请变更账户状态【停用】有效期为 2026-04-30」、「管理员手动停用」与「管理员操作启用」六种表述。把这些取值放在一起可以看到一条清晰的分工线由「用户申请」发起的记录对应学生的主动请求由「管理员审批」发起的记录对应管理员的裁决由「管理员手动」发起的记录对应无需申请的即时操作——操作人字段区分了「管理员」与「超级管理员」两种角色实测页面共 23 条记录能够完整还原一个账户在数日内的权限变化过程。图 14 账户操作记录管理界面申请、审批与手动操作的全过程留痕账号审批是权限链条的闸口。页面按行列出待处理的申请字段包含姓名、电话、照片路径、班级、卡号RFID、账户有效期、账户状态、申请变更状态、申请有效期与审批事由顶部提供「审核通过」与「审核驳回」两个操作按钮。与用户管理页面相比这里的字段多出了「申请变更状态」「申请有效期」与「审批事由」三项——它们正是申请与审批这一对动作所留下的痕迹申请方提出希望变更为什么状态、期望的有效期到哪一天审批方则填写作出结论的理由。实测截图中傅浩洛的记录显示账户状态为「正常」、申请变更状态为「停用」、申请有效期为 2026-05-06、审批事由为「离职」呈现出一条完整的待审批申请而若审批事由留空便直接提交系统会弹出「审批事由不能为空请重新填写」的提示并阻止操作把「谁基于什么理由批准了这次权限变更」固化为一条不可省略的记录。图 15 账号审批界面上与审批事由必填校验下3.1 微信小程序端微信小程序面向持卡师生以 webview 控件调用 H5 页面的方式实现与 Web 管理端共享同一套业务接口与数据源。登录页提供账号与口令输入底部附注册入口学生可自行注册账号后提交开通申请无需管理员代为建档。登录后的首页以宫格方式提供通行记录、账号延期、审批记录查询与个人中心四个入口底部以标签栏在「首页」与「个人中心」之间切换。图 16 小程序登录页左与首页功能导航右历史数据查询以卡片列表的形式呈现本人的通行记录每条记录列出人员、班级、手机号、卡号RFID、通行方式与终端并在右上角标注通行时间。卡片的字段随通行方式自适应刷卡通行会显示具体卡号如实测记录中的 51609618刷脸通行则把卡号字段显示为「---」同时在卡片右侧嵌入当次的人脸抓拍照片终端字段统一显示为「ZDBH01闸机」与 Web 端的终端登记保持一致。用户数据查询则对应账户的变更轨迹每条记录列出用户、时间、电话、班级与变更内容实测记录中出现了「管理员审批已审批用户状态为正常」、「管理员审批审批不通过用户状态为正常」与「用户申请变更账户状态【停用】有效期为 2026-05-06」三类表述。这两个页面的共同特点是只呈现与本人相关的数据与 Web 端面向管理员的全量视图形成明确的信息边界。图 17 小程序历史数据查询左与用户数据查询右本人通行记录与账户变更轨迹账户申请与个人信息两个页面是小程序端唯一的写入入口。账户申请页面分为「基本信息」与「延期申请」两段上半段以只读方式回显审批状态、姓名、电话、班级、卡号、账户有效期与账户状态实测中审批状态显示为「已审批」下半段为延期申请表单由学生自行填写期望的账户有效期、账户状态与申请事由提交后进入 Web 端的待审批列表。个人信息页面则是档案的维护入口姓名、电话、班级、卡号、账户有效期与账户状态六项均为可编辑字段下方提供图片上传区已绑定的人脸照片直接显示在上传区上方支持点击选择或拖拽上传每次上传限一张。把「改档案」与「改权限」拆成两个页面是本系统在权限设计上的一条隐含约束——学生可以修改自己的联系方式与人脸照片但账户的有效期与生效状态必须经由申请与审批流程才能变更。图 18 小程序账户申请左与个人信息右延期申请表单与人脸照片绑定入口3.2 图像模块参数配置与通信调试ESP32-CAM 的工作参数经串口配置工具下发配置项涵盖无线接入信息、服务端地址与端口、上传接口、闪光灯开关、自动拍照开关、调试模式、水平镜像与垂直反转、拍摄间隔等。实测配置中无线热点名称为 8266wifi服务器地址为本机局域网地址Socket 端口为 19214上传接口路径为 /f/esp32/upload对应服务端 8889 端口闪光灯开启垂直反转开启而水平镜像关闭——反转参数的取值由模块的实际安装方向决定拍摄间隔为 10 秒而自动拍照处于关闭状态这一点与系统的设计意图一致抓拍由主控在检测到行人到位时按需触发而非由图像模块周期性自行采集从而避免无效图像持续占用带宽与存储。配置工具同时给出串口参数端口 COM33、波特率 115200、数据位 8、无校验、停止位 1。图 19 ESP32-CAM 模块配置无线接入、服务端地址与图像输出参数链路的实际运行状态可通过串口网络调试工具直接观察。调试工具以 TCP Server 方式在本机 19214 端口监听与现场硬件建立连接后接收区按时间顺序打印出全部上报报文与下行指令。实测记录中可以看到硬件启动后先输出固件信息与运行参数ELF 校验值、Wi-Fi 名称、服务器 IP、Socket 端口、上传地址、闪光灯与拍摄间隔等随后开始周期性上报状态与刷卡事件本机作为服务端在接收到连接后向硬件下发开闸指令并得到状态回执接收计数与发送计数分别累计使链路的连通性与报文收发情况可以直观核对。在调试阶段「上行报文的字段是否完整」与「下行指令是否被硬件正确执行」这两个问题往往决定了整个系统的联调效率而把上报与下发都打印在同一屏上是一线调试中最直接有效的手段。图 20 串口网络通信调试TCP Server 监听、上报报文与下行开闸指令四、系统视频展示为便于完整呈现软硬件的联动过程项目配套录制了功能演示视频。视频以屏幕录制与实机拍摄交替切换的方式依次演示以下环节硬件上电并与服务端建立 TCP 连接Web 端实时数据页面随即显示闸机状态与当日通行次数学生在小程序端注册登录在个人信息页面绑定人脸照片与校园卡号随后提交账户开通申请管理员在 Web 端账号审批页面核验信息、填写审批事由并审核通过行人持卡靠近 MFRC522 感应区舵机开启门体、绿灯亮起、蜂鸣器短鸣Web 端通行记录页面新增一条标注为「刷卡通行」的记录行人面向 ESP32-CAM 完成人脸识别门体再次开启通行记录中新增一条标注为「刷脸通行」的记录并附带抓拍照片与处理后照片使用已停用的账户尝试通行门体保持关闭并触发红灯与告警音最后演示账户延期申请的提交与审批以及 Web 端的远程单次开闸。项目视频按用途提供多个版本供平台发布的完整演示版本、无水印版本用于二次编辑与嵌入其他材料以及适配移动端播放的压缩版本。建议的观看顺序为先观看完整演示版本建立整体印象再对照图 7 的数据交互时序图理解刷卡、刷脸与台账三条链路的关系最后结合图 3 与图 4 复核硬件连接与引脚分配。视频文件随项目资料一并提供如需对照源码调试建议同时打开图 10 与图 15 的界面截图把视频中出现的账户与审批记录同界面字段逐项比对。五、获取方法源码与技术资料获取在本文评论区留言或通过 B站 站内私信说明需求说明需要的是「源码 原理图 硬件实物」的完整套装还是其中的单项资料收到回复后按指引提供接收方式资料将由专人整理打包后发送如需环境搭建协助或二次开发支持可在联系时一并说明具体需求。交付项内容硬件实物按原理图焊接完成的整机一套含主控、MFRC522 读卡模块、ESP32-CAM、舵机、红外对管、蜂鸣器与 LED程序源码STM32 下位机工程Keil 5、服务端工程、Web 管理端工程与小程序端页面硬件原理图嘉立创 EDA 工程文件及 PCB、PDF 与图片导出演示视频功能演示视频提供完整版、无水印版与移动端适配版文档资料接线说明、图像模块参数配置说明、通信协议说明与业务流程说明源码获取、技术支持请联系微信【xswzls】微信公众号小豆豆物联网。项目的资料整理、硬件调试与技术支持由「小豆豆物联网」提供。附录 A ESP32-CAM 模块配置帧可直接复制模块工作参数经串口配置工具一次性下发帧以config开头、以#结束字段顺序为热点名称、热点口令、服务器 IP、Socket 端口、上传地址、闪光灯、自动拍照、调试模式、水平镜像、垂直反转、拍摄间隔。config8266wifi123456789192.168.137.25019214http://192.168.137.250:8889/f/esp32/uploadtruefalsefalsefalsetrue10end#下发该帧后模块回传启动日志与生效参数WiFi 名称 : 8266wifi WiFi 密码 : 123456789 服务器 IP : 192.168.137.250 Socket 端口 : 19214 上传地址 : http://192.168.137.250:8889/f/esp32/upload 闪光灯 : true 自动拍照 : false 调试模式 : false 水平镜像 : false 垂直反转 : true 拍摄间隔(秒) : 10串口参数模块侧COM33 / 115200 / 8 / N / 1上位机串口网络调试助手侧COM3 / 9600 / 8 / N / 1。附录 B TCP 调试要点上位机以TCP Server方式在192.168.137.250:19214监听现场硬件作为客户端接入调试记录中连接对象为192.168.137.146:59发送计数 117、接收计数 270可据此核对链路连通性与报文收发是否成对。附录 C 素材说明配图 20 张自绘 4 张图 1 系统总体架构、图 2 系统功能结构、图 3 硬件系统原理框图、图 7 系统数据交互时序真实素材 16 张。原理图由Schematic_..._2026-04-26.pdf以 1800 宽渲染并裁白边未使用同目录下的_2026-04-15.pdf内容等价。演示视频位于01视频演示\无水印版\...-w.mp4与水印版\...m4vB站版本\为空目录且无封面图故「四、系统视频展示」写成演示环节清单形式。