做嵌入式开发这些年，从51到AVR再到ARM，控制类的板子做过不少，但像这套一样把电子密码锁、指纹识别、WiFi远程视频、手机APP控制、红外测温、液晶显示、密码错误蜂鸣报警全压在一块STM32上的项目，还是头一回碰。整套系统做完之后，我自己回过头来梳理，发现它其实很适合作为智能门禁类项目的样板：功能齐全、模块化清晰、技术覆盖面广，既能应付课程设计和毕业设计，也能作为产品原型继续往深做。下面我把从方案选型到代码调通的完整过程整理出来，给准备碰类似项目的朋友一个参考。
1. 项目整体设计与思路拆解
1.1 核心需求解析：先把功能拆成四层
很多人一看到“密码锁+指纹+WiFi+视频+测温+报警”这一串功能就头大，觉得工作量爆炸。其实拆开看，这套系统本质上是四个层次，各层之间是并列加联动的关系，不是互相纠缠的一团乱麻。
第一层是本地开锁逻辑：密码输入正确、指纹比对通过，就驱动门锁执行机构开门，这是门禁系统最基础的能力。第二层是安全告警逻辑：密码错误时蜂鸣器报警提醒，同时限制单日错误次数，防止暴力破解。第三层是远程控制层：通过WiFi联网，手机APP能查看门锁状态、远程下发开门指令，视频画面实时回传，相当于把门禁装进了手机。第四层是环境感知层：红外测温模块测出访客体温，在液晶屏上显示，适合公共场所门禁或家庭访客体温筛查这类场景。
把这四层分开理解之后，整个项目的开发顺序也就出来了：先跑通本地开锁，再加上告警，接着做WiFi和视频，最后挂测温显示。我最常跟人说的一句话是，先分层，再联调。如果一上来就把全部功能糅在一起调，出了问题你连是硬件故障还是软件逻辑错误都分不清楚。
1.2 主控选型：为什么一颗STM32就够了
这套系统用STM32做主控，几乎是没有悬念的选择。STM32F103系列，尤其是C8T6这颗芯片，在类似的智能门锁项目中出镜率极高。它的价格稳定、货源充足，外设接口也完全覆盖这套系统的需求：指纹模块走一个UART，WiFi模块走一个UART，调试串口再占一个；红外测温模块走I2C；液晶屏如果选TFT彩屏可以用SPI，选LCD1602就直接用GPIO模拟时序。再加上若干普通GPIO控制继电器、蜂鸣器、电磁锁，整个IO资源用下来依然留有富余。
更重要的是STM32的中断系统和定时器能力。门锁这种项目对实时性有要求，指纹比对虽然模块内部自己完成，但指令交互要快速响应；WiFi数据处理也容易阻塞主循环。正确做法是把耗时的操作放到中断或定时器里去处理，主循环只做状态判断和UI刷新。STM32的NVIC嵌套向量中断控制器和多路定时器提供了足够的资源来做这种非阻塞架构。相比51单片机，STM32的代码执行速度和内存容量也更能承载一套完整的业务逻辑，而不是只跑一个外设驱动。
1.3 方案设计里的两个红线原则
做这类门禁系统，有两件事必须在设计阶段就定下来，否则后期改起来非常痛苦。
第一，本地开锁必须优先于远程开锁。无论WiFi模块是断网、卡死还是连不上服务器，本地密码和指纹一定要能正常开门。也就是说，远程控制只是锦上添花，本地认证才是核心逻辑。很多项目死在把远程指令和本地逻辑混在一起，结果断网之后整个锁变得不可用，这在真实场景里是不可接受的。
第二，报警逻辑必须独立推动。密码错误报警不能依赖WiFi或APP，因为攻击者可能直接物理接触设备。蜂鸣器和控制逻辑由STM32本地判断，错误次数达到阈值就锁定输入并持续报警一段时间，这个流程要写在主控本地，而不是等服务器回复。把这条红线守住，整个系统的可靠性和安全性都会上一个台阶，评审和答辩时也更好解释。
2. 硬件模块选型与关键参数解析
2.1 指纹识别模块怎么选：光学指纹头的取舍
指纹模块是这套系统的核心生物识别部件，市面上最常见的方案是光学指纹头和半导体电容指纹头两大类。我建议优先选光学指纹模块，比如常见的R307、AS608这类，原因很实际：成本低、寿命长、对静电和汗液不敏感，适合门锁这种可能暴露在室外环境的使用场景。半导体指纹头体积更小、识别精度更高，但价格贵，而且手指沾水或油腻时容易拒识，在门锁场景反而不如光学模块稳定。
选模块时重点看几个参数：指纹模板容量（普通模块一般在200到1000枚，家庭场景50枚足够）、比对速度（通常小于1秒）、串口电平（务必确认是3.3V还是5V，STM32 GPIO大多是3.3V，接错电平会烧模块）。R307这类模块自带DSP处理器，负责图像采集、特征提取和比对，主控只需要通过串口发指令。它的指令集非常固定，包括获取图像、生成特征、搜索指纹、合成模板、存储模板等，通信协议格式一般是包头+芯片地址+包标识+指令码+参数+校验和+包尾。调试的时候用串口助手逐条指令发，很容易就能跑通。
2.2 WiFi模块与视频方案：串口WiFi加独立摄像头的组合
WiFi远程控制这块，方案选择比较多，但核心矛盾是：STM32作为主控，既要处理业务逻辑，又要处理视频流，压力很大。如果让STM32直接去解码视频流，基本不现实，内存和CPU都不够。
所以我的方案是让主控专注控制，视频走独立链路。WiFi模块选用串口透传型模块（比如ESP8266刷AT固件，或者更稳定的串口WiFi模块），STM32通过UART发AT指令连接路由器，再建立TCP连接或者MQTT连接，用JSON格式收发控制指令。视频部分单独用一个带有WiFi能力的串口/网口摄像头模块，摄像头自己连网，通过MJPEG格式把视频流推给APP端拉取，STM32完全不碰视频数据。
这套架构看起来绕，其实是最省心的。摄像头模块自己处理编码和网络协议栈，APP端直接用模块厂商的SDK或者通用RTSP/MJPEG播放器拉流，稳定性和开发效率都比STM32硬解视频强太多。有人问为什么不用ESP32直接搞定WiFi和视频，确实可以，但开发复杂度和调试成本会明显上升，对毕设来说性价比不高。
2.3 红外测温模块与液晶显示搭配
红外测温模块我选的是MLX90614，这是目前最主流的非接触式测温芯片，I2C接口，出厂校准过。它的测量范围分为两种模式：工业模式从-40℃到125℃，人体模式从0℃到50℃左右。门禁测温场景当然选人体模式，精度标称±0.3℃，分辨率0.02℃，读取响应时间几十毫秒，满足门禁场景完全够用。
MLX90614的I2C地址默认是0x5A，读取内部RAM地址0x07就能得到物体温度，0x06是环境温度。实际使用时有个关键点：传感器镜片前方不能有遮挡物，而且测量距离一般控制在3到10厘米，太远温度偏低。这个物理限制必须在结构设计时就考虑进去，不然装到门禁外壳里，前面贴了块玻璃，温度读数直接报废。
显示部分，LCD1602是最省事的方案，成本低、接线少，但只能显示两行字符，温度、状态、门锁信息要按屏页切换。如果想让显示效果更好，我建议上1.8寸TFT彩屏，SPI接口，分辨率160x128，能直接显示中文、图标和数值，APP风格界面的观感会好很多。显示屏的刷新逻辑要注意用定时器控制，每200毫秒刷新一次就够了，不要死循环刷屏，浪费CPU还给WiFi数据处理添乱。
2.4 执行机构、报警电路与电源设计
门锁执行机构有两种常见方案：电磁锁和舵机。电磁锁优点是吸合力大、安装简单，但需要较大电流，一般要12V供电，而且持续吸合会发热，不适合长时间通电开锁。舵机方案用9g舵机推动锁舌，5V供电，主控PWM控制角度，适合改造普通门锁，但扭矩小，安装精度要求高。我做的这套选的是电磁锁加继电器控制，开锁时给一个脉冲，锁吸合2秒后自动断开，既完成开门又避免发热。
蜂鸣器报警用有源蜂鸣器最简单，给高电平就响，不需要额外的振荡电路。接线时注意两点：STM32GPIO驱动能力不足，不要直接接蜂鸣器，要加一个NPN三极管（S8050）做驱动；有源蜂鸣器是感性负载，断开瞬间会产生反电动势，建议在蜂鸣器两端并联一个续流二极管，不然容易干扰MCU复位。
电源是整个系统最容易被低估的部分。STM32核心板用5V供电，但指纹模块、继电器、蜂鸣器、WiFi模块同时工作时峰值电流能到1A以上，如果直接用USB线供电，电压跌落会非常明显。我的做法是：5V/2A适配器进板，先接一个大容量电解电容（470uF以上），再分两路，一路给锁驱动和蜂鸣器，一路经过AMS1117-3.3给主控和外设。实测下来，WiFi模块发射和继电器吸合瞬间都很难把3.3V电压拉出明显纹波，系统稳定性好很多。
3. 系统软件架构与核心功能实现
3.1 状态机主循环：门锁软件的骨架
这套系统功能多、事件多，如果用多个标志变量到处乱跳，代码很快会变成一团乱麻。我强烈建议用状态机来组织主循环，把门锁系统划分成几个稳定状态，每个状态只处理自己该处理的事，状态之间通过事件触发跳转。
我设计的几个核心状态包括：待机态、密码输入态、指纹验证态、远程控制态、开门态、报警锁定态。主循环做的动作非常简单：扫描按键、判断当前状态、执行当前状态对应处理函数、处理超时定时器。开机默认进入待机态，按下按键切到密码输入态，指纹模块触摸有效直接进入指纹验证态，WiFi收到远程开门指令进入远程控制态，开门动作完成后延时2秒回待机态。密码错误累计三次强制进入报警锁定态，蜂鸣器响、输入锁定30秒，时间到了自动复位。
状态机的优势在于每个状态的入口和出口都非常清晰，不容易出现“按了按键没反应”这种逻辑bug。就算出了bug，只要打印当前状态值，很快就能定位问题出在哪一环。对于功能复杂度到了门锁这个级别的项目，状态机不是要不要用的问题，而是必须用。
3.2 密码与指纹双认证逻辑的细节
密码认证这部分，看似简单，最容易踩坑的地方在密码存储和比较方式。正式项目里肯定不会用明文密码硬编码在代码里，但很多毕业设计就是这样做的，一旦固件被读取，密码直接暴露。比较好的做法是存哈希值，在密码设置时用摘要算法算一遍存在Flash里，校验时再对输入算一遍做比对。芯片资源有限，算法要轻量，比如用CRC32或者自定义异或加盐的散列方式也够用。
输入逻辑上用矩阵键盘或者独立按键。我这块用的是4x4矩阵键盘加“#”确认、“”取消。按键扫描要处理消抖和长按，消抖延时一般20毫秒。密码输入过程要显示“”占位符而不是明文，这个细节能体现出产品思维。密码错误时变量累计，达到阈值触发报警锁定，同时清空输入缓存。
指纹认证逻辑相对独立，主控只负责与指纹模块通信。注册指纹的流程是：录入第一次图像、生成特征模组一；录入第二次、生成特征模组二；调用合成模板指令得到特征模板，再存储到指定ID位置。比对时直接调用搜索指令，模块会在所有模板中找匹配项并返回ID和得分。指纹和密码的关系建议用“或”逻辑，任一通过即可开门，这样用户习惯不容易被打破。也可以做成组合逻辑即两者都必须通过，但日常使用体验会差很多，除非是房间安全要求特别高的场景。
3.3 红外测温读取与LCD显示流程
MLX90614的读取用I2C即可，STM32的硬件I2C有时会遇到总线锁死的问题，建议直接用GPIO模拟I2C，稳定性更高，代码也好移植。读温度时先发器件地址加写位，然后写寄存器地址0x07，再重新发起读操作，连续读两个字节，拼出一个16位数据，乘上0.02摄氏度就是实际温度值。注意读取的时候要连续读两帧取平均，因为传感器对环境的瞬时变化比较敏感，单次读数跳动可能比较大。
LCD显示界面我分了几个区块：左上角显示温度数值，右上角显示WiFi连接状态图标，中间显示门锁状态（关闭/开启），底部显示当前时间或日期。温度值刷新频率200ms一次，超过设定阈值（比如37.3℃）时，除了数值变红还可以联动蜂鸣器短鸣提示。这里有个小技巧：蜂鸣器短鸣和密码错误报警的长鸣要区分开，用不同的延时和频率，否则用户体验会非常困惑。
3.4 WiFi通信协议与远程视频链路设计
WiFi模块与STM32之间的通信协议不推荐用裸的HEX指令，维护成本太高。我用的是JSON字符串加换行符作为消息边界，比如远程开关门指令是{"cmd":"open","token":"xxxx"}，状态上报是{"status":"locked","temp":36.5}。STM32接收到完整的一行JSON后，用一个轻量级解析器提取字段。JSON解析在STM32上做要比PC上麻烦得多，所以协议字段一定要精简，不要嵌套，控制在两层以内。
远程开门的安全设计是另一个重点。APP下发开门指令带着token，STM32收到后校验token再执行。token的生成逻辑可以预设在配置阶段：手机APP先连接WiFi模块的配置热点，发送管理员密码，STM32生成一个随机token保存下来，后续APP连上网络后必须带这个token才能控制。这样即使局域网内有人抓包，缺少token也没法直接解码执行，算是一个基本的防伪机制。
视频链路就走摄像头模块自己的协议。摄像头连接路由器后，通过UDP把MJPEG帧推到对应的IP和端口，手机APP端直接播放视频流。STM32只在需要时通过串口对摄像头模块发送休眠/唤醒指令，省电同时也避免长时间占用网络带宽。
3.5 手机APP功能与交互设计要点
APP端如果从零开发，工作量会上来，可以用一种更快的方式：基于开源物联网平台或者开源门禁APP模板改。把这些功能列清楚：扫码或输IP添加设备、查看门锁开关状态、温度实时曲线、远程开门按钮、视频画面窗口、开门记录列表。核心交互就那几个按钮，APP开发的重心应该放在控制逻辑和消息推送上。
APP与STM32的通信我建议走本地局域网TCP长连接，再加一个MQTT中转，这样在外网也能控制。MQTT的好处是异步、轻量、掉线自动重连，但前提是有个公网服务器或者内网穿透方案。如果不想搭服务器，只做局域网示范，TCP直连就够用。视频画面和门锁控制在APP内分开显示，开门按钮按下后，APP先发指令再等STM32回执，回执成功才更新状态，避免“按了没反应”的心理落差。
4. 实操过程与关键步骤实录
4.1 硬件接线清单与引脚分配参考
接线是整个项目最基础也最容易翻车的部分。我给出当时调通的引脚分配，你在自己的板子上可以按需调整，关键是不要外设之间共用同一个UART或I2C引脚。
| 外设模块 | 接口类型 | STM32引脚 | 备注 |
|---|---|---|---|
| 指纹模块 | UART1 | PA9(TX), PA10(RX) | 3.3V电平，注意模块电平匹配 |
| WiFi模块 | UART2 | PA2(TX), PA3(RX) | 透传或AT指令模式 |
| 调试串口 | UART3 | PB10(TX), PB11(RX) | 用于printf输出定位 |
| MLX90614 | I2C模拟 | PB0(SCL), PB1(SDA) | 模拟I2C更稳定 |
| TFT屏幕 | SPI1 | PA5(SCK), PA7(MOSI), PA4(CS), PA6(DC) | 加背光控制脚 |
| 继电器 | GPIO | PC13 | 控制电磁锁，低电平触发 |
| 蜂鸣器 | GPIO | PC14 | 三极管驱动，高电平鸣叫 |
| 矩阵键盘 | GPIO | PE0-PE7 | 4行4列，按下为低电平 |
接线后第一件事不是通电，而是用万用表通断档测一遍电源和地有没有短路，尤其是3.3V和GND之间、5V和GND之间。很多板子一上电就冒烟，基本都是在没测短路的情况下直接怼了适配器。
4.2 开发环境搭建与工程配置要点
工具链我用的STM32CubeMX加Keil MDK，也可以直接用STM32CubeIDE，免费而且不需要破解。在CubeMX里选定芯片型号后，把用到的UART、SPI、I2C、GPIO全部配置好，生成初始化代码，然后在用户代码区填业务逻辑。这里有个使用习惯要养成：不要在CubeMX生成的/* USER CODE BEGIN */注释之外写自己的代码，否则下次重新生成代码时会被覆盖掉。
配置时钟时，外部晶振如果用的是8MHz，在CubeMX里把HSE设成8MHz，系统时钟尽量拉到72MHz最高主频。调试别用SysTick做延时，它被HAL库占用了，自己在软件里实现一个基于定时器2（TIM2）的ms级节拍，给状态机和超时管理提供时间基准。这个节拍函数是整个系统非阻塞运行的基础。
4.3 指纹模块调试步骤：先通指令，再谈业务
指纹模块的调试是这套系统里需要耐心的部分。先把模块通过USB转TTL接到电脑，用串口助手发指令调通协议，确认能获取图像、生成特征、搜索指纹，再接回STM32。很多模块在STM32上指令无响应，最后发现是模块和主控的TX/RX接反了，次序颠倒是指纹调试最常见的老大难。
指令调试通了之后，再写固件里的注册和比对流程。我建议把每个指令封装成一个函数，返回成功失败状态码，业务逻辑里根据状态码决定下一步。比如注册指纹时，第一次按下手指成像失败就提示“请重按”，第二次收集的特征和第一次差异太大就提示“请保持同一姿势”。用户体验的差距往往就在这些细节里。
实测下来，R307模块识别一次的时间大约在0.3到0.6秒，完全满足门锁场景。指纹注册和识别都要求手指干燥且指纹清晰，手指出汗或者有灰时拒识率会升高。这时候不是代码bug，是物理原因，可以考虑在门锁旁边配一块干布或加一个风干组件，产品化时值得考虑进去。
4.4 WiFi与手机APP联调步骤
WiFi模块的联调我建议分三步走，不要一上来就接STM32。
第一步，USB转TTL接WiFi模块，用串口助手发AT指令测试模块能不能连上路由器，能不能建立TCP连接。第二步，用网络调试助手监听指定端口，让模块往调试助手发数据，验证双向通信。第三步，再把模块接回STM32，用STM32的代码自动完成连接流程。
接回STM32后，最实用的联调手段是printf打印状态日志，通过调试串口观察模块的连接状态机和收到的原始数据。我遇到过很多次模块连接一切正常，但STM32解析JSON失败，原因就是数据里混了AT模块的回显字符。解决方法是把WiFi模块设为透传模式，关掉AT回显，再从代码层面做数据缓冲和帧边界检测。
APP联调时，建议先用手机连同一路由器，用网络调试助手模拟APP端收发消息，确认指令格式和回执逻辑都没问题，再接APP界面。这样出现问题就能定位：要么STM32的问题，要么纯网络的问题，不会两边互相甩锅。
4.5 整机装配与上下电稳定性检查
硬件全接好后，不能直接跑完整业务逻辑。我习惯按“最小系统”方式逐级上电：先只接STM32核心板和屏幕，确认系统启动和显示正常；然后接指纹模块，确认注册和比对通路；再接WiFi模块，确认联网和收发指令；最后才接继电器、电磁锁和蜂鸣器。每加一级外设，就测试一次系统整体是否仍然稳定，之前调通的功能有没有被新外设干扰。
上下电测试尤其重要。电磁锁是感性负载，断电瞬间会产生反向电动势，如果不做续流措施，可能把这个短时高压灌进电源线，导致主控复位甚至损坏。除了之前提到的继电器侧续流二极管，主控板的复位引脚对地可以加一个0.1uF电容，能有效滤掉部分高频干扰，降低复位概率。电池或者电源适配器刚插上的一瞬间，如果代码里没有做初始化保护，继电器可能因为IO口默认状态误触发，一定要在继电器控制引脚上加下拉电阻，并让初始化代码先置默认电平再延时启动其他外设。
5. 常见问题与排查技巧实录
5.1 指纹识别误识率和拒识率高怎么办
指纹识别的两率问题，大多数情况下不是代码故障，而是使用习惯和录入质量的问题。录入指纹时应尽量覆盖手指中心区域，每个手指录入两次，保持按压力度均匀。如果某个手指经常识别失败，最好的解决办法不是调阈值，而是重新注册一遍这个手指的指纹模板。
模块本身对干手指不友好，冬季手干容易拒识，可以对着手指哈口气，或者用指尖按压更重一些。误识别即别人的指纹也能开锁，在R307这类模块上比较少见，但如果注册的模板质量太差，特征点提取不够，确实会出现误开。发现误识别时第一时间删掉该ID重新录入，而不是凑合着用，安全类项目凑合不得。
5.2 WiFi视频卡顿与丢包如何排查
视频卡顿的原因多为三方面：带宽不足、路由器信号差、摄像头模块与路由器距离过远。用同一局域网测试时，先把摄像头模块紧贴路由器，确认流畅度；再逐步拉开距离观察卡顿拐点。如果APP画面频繁断帧，重点检查手机是否连了5GHz频段而摄像头连了2.4GHz频段，有些设备跨频段通信时延迟会明显偏高。把所有无线设备统一到2.4GHz频段能解决一大部分“视频卡顿”的奇怪问题。
WiFi控制指令有时发送失败另一个常见原因是STM32缓冲区溢出。WiFi数据是异步到达的，如果主循环还在处理指纹比对，缓冲区里的用户数据可能被覆盖。我用的做法是环形缓冲区加中断接收，配合超时机制解析完整的一帧，每接收一个字节就进中断存进缓冲，主循环空余时再处理。
5.3 红外测温误差大、刷新慢
MLX90614测出来的温度如果跟水银温度计对不上，先别急着怪芯片。这个模块有个物理特性是容易受环境温度影响，环境温度变化大的时候，物体温度读数也会跟着波动。最简单的补偿方式是先测同一物体的环境温度，再根据传感器的出厂偏移量做个线性修正，在代码里加一个校准参数，比如calibrated_temp = raw_temp + offset。
刷新慢的瓶颈大多在I2C读取频率。MLX90614最快大约能做到10Hz输出，如果加了两帧平均和LCD刷新，整体体验基本是实时的。要是觉得卡顿，把读取频率提到10Hz，显示方面用200ms刷新一次就够了，数据放到内存里做滑动平均再显示，数值会更平滑。
5.4 主控偶发死机和复位问题
STM32的偶发复位，十有八九是电源问题，其次才是代码问题。做门禁这类带继电器的系统，务必用示波器捕捉继电器切换瞬间的电源波形。如果看到明显的毛刺，就在主控供电处加一个磁珠或者小电感，配合10uF和0.1uF的双电容滤波。还有一个非常简单却被很多人忽略的点：复位引脚不要悬空，接一个10K上拉电阻和0.1uF对地电容，ST官方手册里就推荐这么设计。
如果只在长时间运行后才死机，可以把独立看门狗打开。用定时器2做喂狗操作，主循环每跑一圈喂一次，死机超过1秒自动复位。注意喂狗的位置不要在中断里，不然主循环卡死照样喂狗，起不到故障恢复效果。
5.5 门锁执行机构不回位的现象
电磁锁开锁后如果一直吸合不回位，大多是继电器控制逻辑没有做延时复位。我遇到的情况是开锁后手动开门，但代码里只发了一次吸合指令，锁舌没有自动退回。正确的处理是开门状态只保持2秒，超时后强制断开继电器并让电磁锁断电，无论用户有没有推门。如果电磁锁本身机械卡滞，那就得检查锁体和锁扣的安装位置是否对齐了，这不是电气问题。
5.6 故障速查表
把调试过程中高频出现的问题整理成一个速查表，后续排查会快很多。
| 故障现象 | 可能原因 | 排查与解决办法 |
|---|---|---|
| 指纹模块无响应 | TX/RX接反、供电不足 | 核对引脚接法，单独给模块供3.3V |
| 指纹识别总失败 | 手指干湿不均衡、模板质量差 | 重新录入，注意按压位置和力度 |
| WiFi连不上路由 | SSID或密码配置错误、信号弱 | 先USB转TTL单独用AT指令测试 |
| APP收不到门锁状态 | JSON格式不对、端口错误 | 用网络调试助手监听，比对收发帧 |
| 红外测温偏差大 | 距离过远、镜片遮挡、环境干扰 | 控制测量距离，加校准偏移 |
| 继电器吸合后主控复位 | 电源毛刺、继电器无续流 | 加续流二极管，主控电源加强滤波 |
| 蜂鸣器不响 | GPIO配置错误、三极管接反 | 检查GPIO输出模式，单独写测试代码 |
| LCD显示乱码 | 电平不匹配、SPI速率过高 | 降低SPI时钟频率，检查电压转换 |
6. 这套系统还能怎么扩展
如果后续还要继续升级，几个方向可以参考：一是把指纹识别升级成半导体指纹模块，体积更小，适合做嵌入式门锁而不是外挂式门禁机。二是加NFC刷卡模块，兼容门禁卡和手机NFC，适合办公楼场景。三是把视频链路从MJPEG换成H.264硬编码的摄像头模块，画质更好且带宽占用更低。四是加入离线人脸识别模块，比如一些支持人脸检测和比对的AI芯片，这就完全是另一个量级的产品了。
我个人实际做完这套项目之后最大的感受是，硬件做起来并没有想象中那么难，难的是怎么把这么多模块组合在一起还不打架。每加一个外设，就要重新审视之前的外设是否还稳定运行。如果你也准备做类似门禁项目，我给的建议非常直接：先按本文的步骤，把本地密码和指纹调通，再上WiFi，最后再加视频和测温，每一步稳住了再往下走。不要急着从头到尾烧一遍完整工程，那种调试方式只会让你在问题出现时根本不知道该查哪里。按照我这里整理的分层调试思路踩一遍坑，你大概率能比我预想更快地把这套智能电子密码锁系统跑起来。
