企业官网建设流程全解析

蓝牙密码锁这个项目，我当年第一次做完的时候，心里就一个感觉：看似简单，实际坑不少。网上一搜“蓝牙锁”能看到一大堆方案，但真要把它做成一个稳定、安全、能落地的东西，里面涉及的东西比想象中多得多。这篇文章我就把整套设计从头到尾拆开讲一遍，包括硬件选型、BLE通讯流程、安全校验、App交互、调试踩坑，全部基于我实际做过的这套方案，资料也相对完整，你可以直接拿来当参考骨架去改。

先交代清楚这东西是干什么的。基于蓝牙的密码锁，核心就三件事：手机通过蓝牙连上锁体、App里输入密码或指令、锁体校验通过后驱动电机开锁。它能解决的问题很简单，就是传统机械锁和密码键盘锁的痛点——钥匙容易丢、密码盘容易坏、密码被人偷看。蓝牙锁的好处是无线、无钥匙、可远程下发临时密码、有开锁记录。适合谁参考？如果你是做智能家居、做共享设备管理、做储物柜租赁，或者单纯想练手嵌入式BLE开发，这套设计都值得花时间琢磨。

1. 项目概述与整体设计思路

1.1 为什么选蓝牙而不选WiFi或RFID

选无线方案的时候，我见过很多人在WiFi和蓝牙之间犹豫。我的结论很明确：做密码锁，优先BLE（蓝牙低功耗），除非你的产品有远程查看视频或者云端实时同步的硬需求。

原因有三点。第一是功耗。锁体装在门上，多半是电池供电。WiFi模块峰值电流动辄一两百毫安，待机也得几十毫安，一节电池撑不了多久。BLE在整个系统待机时可以做到微安级别，配合好一点的低功耗MCU，两节五号电池跑一年很轻松。对锁这种“平时不动、偶尔用一次”的设备，低功耗是刚需。

第二是成本。BLE模块目前国产方案非常成熟，一个模块几块钱到十几块钱，对比WiFi模块便宜一大截。而且BLE不需要路由器，不依赖家庭网络，产品形态更独立。

第三是交互体验。手机原生支持BLE，不需要额外配网，打开App就能搜到锁、连接、操作。用户心智里“蓝牙锁”就是“靠近就能开”，这个认知已经形成了。

当然，RFID（刷卡）也是一个常见方案。但RFID的问题是手机不能直接当卡刷，NFC模拟卡在iOS上又限制得很死。所以RFID适合做门禁卡、员工卡，不适合做面向全民的手机开锁。蓝牙+密码是最稳妥的组合。

1.2 系统整体框架：四层结构

整套系统我习惯拆成四层看，每层职责单一，调试和排错的时候思路清晰。

第一层是感知与输入层。对密码锁来说，输入源主要是手机App下发的指令，面板上如果还做了键盘，也需要在这一层处理。有些方案加了指纹模块、IC卡模块，也属于这一层。

第二层是主控逻辑层。核心MCU在这里跑状态机，负责密码校验、指令解析、超时管理、电机控制逻辑。这一层是整个锁的“大脑”，安全策略都在这里实现。

第三层是执行层。就是电机、离合机构、锁舌。MCU给出PWM或电平信号，驱动芯片放大电流驱动电机。这个环节很多人忽视，其实电机驱动占整个项目失败的很大比例。

第四层是能量管理层。电池输入、DC-DC稳压、电压检测、低电量告警。锁这类产品最怕电池没电打不开门，所以电量管理不是可有可无，而是核心功能。

每一层之间尽量解耦。比如逻辑层不关心App是安卓还是iOS，只关心收到的是不是合法指令。这样后面无论是换蓝牙芯片、换电机，还是把密码键盘改成指纹模块，改动都能局限在对应层。

2. 核心硬件选型与物料解析

2.1 主控芯片与蓝牙模块的三种组合方式

硬件选型上大家最常见的问题就是“主控和蓝牙到底怎么搭”。我总结下来有三种做法，各有适用场景。

第一种是BLE SoC一体方案，比如某国产低功耗蓝牙SoC，芯片内部集成MCU和射频收发。优点是成本低、功耗好、外围元器件少，PCB面积小。缺点是开发环境相对封闭，代码生态不如通用MCU那么庞大，调试工具也少。适合量产产品，后期软件稳定后综合成本最低。

第二种是通用MCU+BLE透传模块。MCU跑逻辑，蓝牙模块只干一件事：收串口数据发到手机，收手机数据通过串口发给MCU。这种方案开发最简单，MCU可以用熟悉的平台，蓝牙模块内部固件厂家已经写好，不碰射频协议栈。缺点是整机成本和功耗比SoC方案略高，串口透传还有可能成为安全瓶颈。不过对于做原型验证、DIY项目、小批量产品，这个方案最实用。

第三种是双MCU方案，一颗负责低功耗待机，一颗负责蓝牙和逻辑。一般只有对功耗和运行效率都极致要求的商用产品才这么做。普通项目不推荐，调试复杂度翻倍。

我个人建议：如果你做的是学习项目或原型Demo，选第二种，MCU选你熟悉的，蓝牙模块选市面上出货量大的透传模组；如果你要跑量量产，第一批也先用第二种，等软件算法和结构验证差不多了再换SoC，降低综合风险。

2.2 电机驱动与离合机构：不光是“转一下”那么简单

锁体执行器常见有三种：直流减速电机、电磁铁、步进电机。绝大多数家用智能锁用的是“电机+离合”的结构。电机本体很便宜，但驱动它“转到位”、“不堵转”、“不反弹”才是技术活。

电机驱动芯片上，我推荐用带电流限制和正反转控制的H桥驱动芯片，比如常见型号。原因很简单：锁舌运动有死点，电机堵转时电流会激增，如果没有限流，轻则电池电压被拉崩，重则烧驱动芯片。用H桥芯片的电流限制功能，把堵转电流设到电机额定电流的1.5倍左右，既能提供足够扭矩，又能保护电路。软件里也要配合，检测到堵转超过几百毫秒就主动断电，避免长期大电流。

离合机构方面，我踩过一个很深的坑：减速电机的输出轴和锁舌之间的传动，如果用的是塑料齿轮，长时间使用磨损后会产生空转，表现为“电机转半天，锁舌没动”。后来换了金属齿轮才稳定。这个经验就是提醒大家，单片机端的逻辑再完美，结构件不过关，锁最后还是打不开。

2.3 电源管理与低电量检测怎么做

密码锁的电源方案我比较推荐两节或四节五号电池。因为消费者换电池成本最低，而且锂电池方案还要做充电管理、过放保护、运输认证，复杂度上升很多。

主控和蓝牙模块的工作电压一般3.3V，电池电压从新电池的3.2V（两节串联）一路降到2.0V左右，中间的压差需要DC-DC或者LDO来处理。低功耗待机的关键是选静态电流小的LDO，最好在几微安以下。另外，MCU和蓝牙模块都要有Sleep模式，状态机跑完一轮就立刻睡，这也是功耗控制的核心。

低电量检测我放在ADC采样上，实时测电池电压，低于阈值就在App端告警，同时锁体本地亮红灯。这里有个细节：不要在电机转动的时候去采样电压，电机一启动电压会被拉低很多，这时候读到的数值是假的，容易误报。正确做法是电机停转稳定后再采样。这个坑我当年就掉过，刚开始做的时候看到电压波动就报警，后来才意识到是采样时机的问题。

3. 蓝牙协议选型与通讯流程拆解

3.1 GATT服务怎么设计才够用又安全

BLE的通讯模型是GATT（通用属性协议）。你需要做的事情，本质就是设计几个自定义的Characteristic（特征值）。

密码锁的核心服务我建议这样设计：一个服务UUID，下面挂三个Characteristic。第一个是写指令特征，App往里面写数据，锁体这边收到通知；第二个是通知特征，锁体主动给App发数据，比如开锁结果、状态上报；第三个是读特征，App读取锁体当前状态，比如电量、锁舌位置。

为什么不能让App直接写电机控制引脚对应的数据？因为直接写裸数据意味着任何人只要能连上锁就可以控制电机，这等于没有安全。真正安全的设计是App写入的指令一定是一个经过加密和鉴权的封包，锁体收到后在主控侧做完整校验，校验通过之后才去执行。也就是说，蓝牙模块只是“传话筒”，做决策的是主控。

还要注意连接参数。BLE有个概念叫Connection Interval（连接间隔），决定手机和锁体之间多久同步一次数据。密码锁是低频交互设备，连接间隔可以设长一点，比如30ms到50ms，省电。但如果你的锁需要响应很快，可以设到7.5ms，代价是功耗上升。这里要做取舍，我建议根据实际使用场景来定。柜锁、门锁这类场景，点完开锁等一两秒很自然，不差那几十毫秒。

3.2 密码下发与安全鉴权：防重放攻击是底线

密码锁最忌讳的事情是什么？不是密码被猜，而是指令被截获重放。蓝牙数据在空中是明文传输可以被嗅探的，如果App每次都是发同一串“开锁指令”，攻击者抓包之后反复发送就能开门，这就叫重放攻击。

防止重放的方案不复杂，但必须做。我用的方法是时间戳+流水号。App每次下发开锁指令时，在封包里带上当前时间戳和一个递增的序列号，再用加密密钥做一次AES加密。锁体收到后先解密，解析出时间戳后对比本地时间，允许误差比如1分钟；再对比序列号，只接受大于上一次的序列号。这样攻击者即使抓到包，重放一两次就会被时间戳拦截，时间戳能改的话序列号也会拦截。双保险之后，这个方案就基本安全了。

密钥管理上，量产产品出厂时每把锁要烧录不同的密钥，防止一台设备的密钥泄露导致整个产品线被开。开发阶段可以先统一密钥，等产品化之前一定改成每设备唯一密钥。

这里还要多说一句：密码本身不要明文存储在锁体内。建议存的是密码的哈希值，校验的时候把输入的密码做同样的哈希再比对。这样如果有人拆了Flash，也拿不到真正的密码。别嫌麻烦，这个习惯要养成。

4. 软件实现与核心代码剖析

4.1 固件端状态机：密码锁绝不能“卡死”

固件端最忌讳的就是写成一坨顺序执行的裸代码。蓝牙连接、按键扫描、电机控制、电量检测这几件事要并发处理，但裸机环境下没有操作系统，最省心的办法就是设计一个简单状态机。

我设计的核心状态有这几个：空闲态、等待指令态、校验态、开锁态、完成态。空闲态时系统在低功耗睡眠，只有蓝牙事件或按键能唤醒。等待指令态是收到App数据但不完整，继续接收。校验态是数据收齐了，解包、解密、比对密码。开锁态是驱动电机正转，等待锁舌到位反馈。完成态是电机停转、记录日志、回到空闲态。

状态之间有超时机制：比如进入等待指令态超过5秒还没收齐数据，就重置回去。进入开锁态电机转超过3秒还没到限位，就判定异常，断电并报警。没有超时机制的话，锁一旦在某一卡住，整个系统就瘫了，这是不可接受的。

代码组织上，我习惯把BLE的数据收发放在中断或回调里，只做“把数据搬进缓冲区”这回事，不做密码比较。密码比较放在主循环的状态机里做。为什么这样？因为BLE回调里做耗时操作会抬高系统中断延迟，影响蓝牙协议栈稳定性，容易导致连接断开。这个细节学到就是赚到。

4.2 App端蓝牙交互的三件事

App端很多人觉得简单，不就是扫描、连接、写数据嘛。实际写完发现坑也不少。App和锁的交互，核心就三件事要处理好。

第一件事是扫描过滤。附近可能有一堆BLE设备在广播，你不能把所有设备都列在列表里让用户自己瞎猜。过滤条件至少有两条：广播包里的服务UUID是不是我们自定义的那个服务UUID；广播名或者广播数据里的设备标识前缀是不是我们定义的，比如“BLELOCK-”。扫描到之后，再通过RSSI信号强度来排序，把最近的锁排在最前面。

第二件事是连接后的MTU协商。BLE默认MTU通常只有23字节，扣掉协议头，实际一条数据只能装20字节。如果你的开锁封包超过20字节，就会涉及分段发送，这很容易出错。App端第一时间请求交换MTU，很多手机能支持到256字节甚至更大，这样一条指令一个包就搞定，省心很多。

第三件事是断开重连策略。用户不可能每次都手动去扫描连接，App要记录上次连接的设备地址，靠近时自动重连。这里注意：iOS系统对BLE设备的连接权限有要求，Android则需要动态申请定位权限才能扫描，这是平台限制，App层面要处理好兼容逻辑。踩过的坑是Android 12以后，只申请蓝牙权限不够，还必须申请精确定位权限，不然后台扫描直接失败。

4.3 时间校准与临时密码的应用扩展

密码锁除了固定密码，很常见的需求是“临时密码”。比如房东给保洁发一个一次性的临时代码，或者是给访客发一个只在某个时间段有效的密码。实现临时密码的逻辑从软件上看并不复杂，但有一个前提：锁体要知道当前时间。

低成本的锁方案很多不带RTC（实时时钟），也就不维护真实时间。怎么解决？两个办法。一个是加入RTC芯片，电池供电不掉时间，成本多一两块钱，但能做精确到分钟的时间窗口控制。另一个是从手机校准，每次App连接上锁，就同步一次时间戳，锁体把时间存在自己的Flash里。后者的风险是如果锁很久没连过手机，内部时间和真实时间偏差会越来越大。我的建议是，如果产品有临时密码需求，老老实实加RTC芯片，别省这个钱。

这套蓝牙密码锁其实只完成了最基础的“能开锁”，后面可以扩展的方向还有不少。接入指纹模块做生物识别，加一个摄像头做远程可视对讲，接入门磁传感器做防撬报警，甚至可以对接各类云平台做远程管理。核心结论还是那句话：先把基础链路做稳了，再谈花哨功能。