专注毕业设计软硬件结合方向，技术栈包括
Qt、SpringBoot、Vue、Web、APP、小程序，以及树莓派、ESP32、STM32、Arduino 等平台。

可提供：系统功能设计、软硬件架构设计、关键电路参考、核心代码讲解、测试方案设计、项目文档整理、开题/中期/论文/答辩学习辅导。

《微信小程序蓝牙门锁毕设：ESP32 控锁、小程序控权限，难度与分工怎么估？》讨论的是这个题目值不值得做，《微信小程序蓝牙门锁：从系统架构与硬件接线看控制端和执行端怎么配合》展示的是整套系统长什么样。本文只盯住其中一条线：从用户在手机上的一次操作，到门锁那一端继电器真正动作，中间的判定与执行是怎么串起来的。

本文把答案放在设计思路、判定步骤和环节拆解里，重点回答四个问题：两端如何分工、蓝牙连接是怎么建立的、三种模式的权限判定发生在哪一步、以及指令最后怎么落到继电器上。文中不给具体的服务标识与报文细节，也不逐条展开实现层参数，只看这条链路本身。

一、要解决的具体技术问题

门锁系统是一个**"权限判定"与"物理动作"强耦合**的对象。一次开锁，既是一次身份判断，也必须落到一次电平输出上——只有判定没有动作，门不会开；只有动作没有判定，门锁对谁都响应。这个耦合决定了两件事必须同时成立，缺一不可。

把它拆开，具体有四个问题：

1. 权限怎么表达并可撤销。管理员要能临时放行一个人，人走了权限要能收回；不能只有"开放"和"关闭"两种极端状态。
2. 两端怎么分工。手机和门锁之间，谁主动、谁应答，决定了排错方向和权限的强度。
3. 指令怎么从"点击"走到"继电器通断"。中间要经过连接、校验、下发几个环节，任一环节没有对齐，动作就不会发生。
4. 状态怎么反馈，异常怎么兜底。锁端执行完要能告诉界面结果，连不上或校验不过时要有明确表现。

本项目对这几个问题的回应是：以低功耗蓝牙作为唯一通道，由手机侧主动发起连接与指令；模式与临时密钥作为控制端的权限表达，锁端在收到指令后做身份校验再执行。 下面几节依次说明这条链路上的每一段。

二、整体设计思路：两端的分工

这套设计把系统分成两个子系统：控制端负责交互与权限表达，执行端负责应答与动作。理解这条链路，先要接受一个前提——锁端是被动的一方，它不主动寻找手机。

角色	承载	主要职责
控制端	微信小程序（逻辑层 JavaScript、视图层 WXML 与 WXSS）	登录与状态展示、模式切换、临时密钥设置、发起蓝牙连接、下发指令
执行端	ESP32（低功耗蓝牙 Host 与 Controller）	广播、被连接、接收指令、身份校验、驱动继电器、回传状态
驱动	松乐单刀双掷继电器模块	以主控的弱电信号切换锁具供电通路
执行机构	12V 电磁锁	把通断电转换成锁的机械状态

蓝牙这一层内部又分两级：ESP32 的低功耗蓝牙协议栈由 BLE Host 与 BLE Controller 组成，Host 处理上层的 GAP（通用访问规范）、GATT（通用属性框架）与各类 Profile，Controller 处理下层的链路层、逻辑链路控制与适配层以及物理层。换句话说，权限这套逻辑跑在协议栈的上层，物理连接建立在下层，两者是分开的。

图示一次开锁从控制端判定、经蓝牙链路、到锁端校验与动作的完整路径。

三、BLE 的连接建立与角色转换

蓝牙连接是这条链路的入口。设计里采用的是 GAP（通用访问规范）接口来组织使用流程，GAP 定义了四类角色：

GAP 角色	行为	能否被连接
广播者 Broadcaster	通过发送广播让自己被发现	只能发广播，不能被连接
观察者 Observer	接收广播事件并发送扫描请求	只能发扫描请求，不能被连接
外围设备 Peripheral	广播者接受连接请求后进入，在链路中作为从设备	可被连接
中央设备 Central	观察者主动初始化并建立物理链路后进入，在链路中作为主设备	主动连接

这四类角色对应到本设计里很清楚：手机作为连接发起方，走的是观察者到中央设备的路径；ESP32 作为被连接的一方，走的是广播者到外围设备的路径。 设备在广播、扫描、发起、连接几个状态之间转换，转换关系可以用下面的状态图描述。

图示设备在待机、广播、扫描、发起与连接之间的转换关系。

从这张图可以看出，连接不是一次配对后永久保持的。BLE 链路建立之后会回到待机、再重新进入广播，手机每次使用都要重新走一遍"发现—发起—连接"。这解释了一个常见现象：上一次明明连上了，隔一段时间再操作又搜不到——不是模块坏了，而是锁端回到了广播甚至待机状态，需要重新发起连接。

四、三种模式的权限判定链路

权限这件事，在控制端用三种模式来表达。它们的判定条件与结果如下：

模式	使用者的判定	判定条件	结果
自由模式	管理员	登录并通过管理员信息验证	可执行开锁与关锁
锁定模式	任意用户	无论身份如何	一律不产生动作
访客模式	临时访客	输入管理员设置并分享的临时密钥，且校验通过	可执行开锁与关锁

把三种模式放进同一条链路，判定发生在两个位置：控制端先决定"当前模式允许谁操作"，锁端再对收到的指令做一次身份校验。锁定模式是在控制端这一层就把操作拦掉的——门锁处于锁定时，任何用户都无法操作；访客模式则是在放行之后，由持有临时密钥的人才能走到下发指令这一步。

图示锁定、自由、访客三种模式在同一判定链路上的分支与汇合。

这里有一个值得注意的设计特征：判定所依赖的"依据"——模式与临时密钥——都集中在控制端设置，锁端只负责对收到的指令做校验并执行。 这带来两个直接后果。其一，临时权限的撤销是通过切换模式实现的，管理员把访客模式切回自由或锁定，原临时密钥就不再有效，这条链路是闭合的。其二，权限的强度在很大程度上取决于控制端本身不被绕过，以及锁端校验这一关是否足够严格——只要锁端对"看起来正确的指令"照做，控制端就成了唯一防线。

五、指令传输与执行端的动作

数据交互的内容，设计里归纳为蓝牙用户的鉴别授权、双方握手、开锁命令与信息应答几类，环节上包括连接建立、身份验证、指令传输、状态反馈和数据加密传输。把它们按发起方列出来，链路更清楚：

环节	内容	发起方
连接建立	手机扫描并发起连接，与锁端建立链路	手机侧主动发起
身份验证	校验操作者身份，访客模式下校验临时密钥	由指令携带、锁端校验
指令传输	下发开锁或关锁命令	手机侧
状态反馈	锁端把执行结果回传	锁端
数据加密传输	设计中被列为环节之一	未展开具体方式

链路走通之后，最后一步是执行端的动作。设计里给继电器设定的触发关系是明确的：当继电器输入端收到主控给出的低电平，常开端与公共端闭合，锁具供电通路接通，电磁锁随之动作。 这一步不是代码层面的复杂逻辑，而是一段"电平—触点—通断"的物理过程，把它写成流程如下。

控制端                        执行端
点击开锁 ──► 下发开锁指令 ──► 接收指令
                              ├─ 身份校验不通过 ──► 忽略，不动作
                              └─ 校验通过 ──► 继电器 IN 收到低电平
                                              └─ NO 与 COM 闭合
                                                 └─ 电磁锁供电接通，动作
锁端回传状态 ◄──────────────── 回传执行结果
界面更新显示

可以看出，一次成功的开锁需要"指令正确下发"和"校验通过"同时成立。任何一环缺失，链路都停在原地：指令没发出去，锁端等不到；校验没过，锁端不动。这也决定了排错时要能分别确认这两段的状态。

六、安全与一致性上的几个观察

把这条链路完整看一遍，会发现几处需要留意的地方，它们都属于"设计这么写、但细节没跟上"的类型。

第一，驱动与锁状态的口径不一致。 驱动部分描述的是"继电器收到低电平、常开端与公共端闭合即开锁"，而锁具部分描述的是"通电时线圈产生磁场吸附铁块，达到门锁的目的"——按后者，通电对应的是锁定而不是开锁。两处对同一个电气动作给出的机械结果相反。复刻时必须先确定继电器的常开/常闭接法与锁具的电气特性，再决定控制极性，否则会出现"程序说开锁、实际却锁上"的情况。

第二，加密传输没有落到具体方案。 数据交互被归纳为包含"数据加密传输"的若干环节，但用什么方式加密、密钥怎么产生与分发，都没有给出。只要加密这一环没有具体方案，它就更接近一个待补的设计项，而不是已经具备的能力。

第三，临时密钥的策略偏弱。 密钥由管理员手工设置、可以任意修改、并非系统随机生成，也没有明确的有效期与使用次数限制。这意味着只要密钥被旁人看到，就能在权限未撤销前使用；安全性依赖于管理员及时切回模式的自觉。

第四，广播与连接层的风险没有讨论。 低功耗蓝牙的广播本身就是"愿意被谁发现"的信号，连接也可以被反复尝试。设计里没有提到配对、绑定或白名单一类的限制，因此"谁可以尝试连接锁端"这件事并没有被约束。这一条和上一条叠加，会放大权限被绕过的可能。

这几个观察不是否定这套设计，而是说明这条链路在从"能跑通"走向"考虑周全"之间，还有明确的改进空间。它们也正好是可以直接写进论文的改进讨论。

七、复盘：联调顺序与改进点

1. 联调顺序建议

这条链路牵涉两套开发环境，按下面的顺序推进，每个阶段都确认预期现象再往下走：

1. 执行端上电并广播：确认用手机的蓝牙调试工具或系统设置能发现锁端设备；
2. 建立连接：确认手机能连上，连接后链路不立即断开；
3. 收发一条数据：确认锁端能收到一条自定义信息并作出可观察的响应；
4. 单条指令驱动继电器：先不接锁具，只验证"给控制信号、继电器是否动作"；
5. 接入三种模式判定：在控制端加入自由、锁定、访客的分支，验证每种模式下指令是否按预期被拦或放行；
6. 补上反馈与异常：确认状态能回传、断连时有明确表现。

顺序上不要跳过第 3、4 步直接做模式判定。链路没通就调权限，出了问题会分不清是"判定错了"还是"根本没送到"。

2. 几个可以继续改进的点

• 对齐驱动极性：把继电器触发极性与电磁锁的通断电状态统一成一张对照表，明确"高电平对应开还是关"，避免第六节提到的口径冲突。
• 补上加密方案：为指令选定一种具体的加密与校验方式，并说明密钥从哪来、怎么换。
• 强化临时密钥：给密钥加上有效期与使用次数上限，让"临时"有明确边界。
• 约束连接对象：通过绑定或白名单限制可连接的手机，减少广播被随意连接的可能。
• 统一供电口径：把主控、继电器线圈与锁具的取电电压与分路方式写清楚，减少接线阶段的返工。

动手前先理清一个边界：权限判定要"严"到什么程度，是只做在控制端，还是锁端也承担一部分判断。这个边界一旦定了，两端的职责和后面的改进方向都会跟着清楚。

如果正在复刻这条链路，可以在评论区说明用的是哪款主控、继电器是高电平还是低电平触发，以及目前卡在连接建立、校验判定还是驱动动作这几步中的哪一步；后续还可以围绕临时密钥策略、锁状态反馈一致性和连接层约束这几个细节继续展开。