基于NodeMCU与RC522的物联网门禁系统：从硬件连接到云端管理

1. 项目概述与核心思路

上周我折腾了一个挺有意思的小项目，用NodeMCU和RC522读卡器做了一个带在线管理功能的RFID门禁系统。这玩意儿说白了，就是给电子门锁加了个“大脑”和“眼睛”，让它能认卡开门，而且所有权限管理都能在网页上远程操作。你想想，无论是公司前台、小区单元门，还是自家工作室，装这么一套东西，管理员就不用再跑上跑下配钥匙、发门禁卡了，在电脑前点几下鼠标就能搞定，甚至人在外地都能临时给访客开个权限，确实方便。

核心思路其实很清晰：硬件端负责“感知”和“执行”，软件端负责“决策”和“管理”。具体来说，门口的NodeMCU开发板连着RC522读卡器，就像个哨兵。有人刷卡，它就读到卡片的唯一标识（UID），然后通过Wi-Fi把这个“身份证号”加密后发给远端的服务器。服务器就是个“指挥部”，它查一下自己的数据库（我用的是MySQL），看看这张卡有没有权限、在不在有效期内。查完了，立刻把“放行”或“拒绝”的指令发回给NodeMCU。NodeMCU收到“放行”指令，就控制一个继电器或者电磁锁吸合，门就开了。整个决策过程在云端，所以权限管理、记录查询这些功能，自然就能通过一个网页后台来实现，实时更新，一目了然。

这个方案最大的好处是“集中管理，分散执行”。门禁点可以有很多个，但权限数据库只有一个。开除一个员工，在后台把他名下所有卡的权限一关，全公司所有的门他立刻都进不去了，根本不用去每个门禁回收实体卡。对于需要灵活管理权限的场景，这种架构的优势是传统离线门禁控制器没法比的。

2. 核心硬件选型与电路设计解析

2.1 主控与读卡器：为什么是NodeMCU和RC522？

主控芯片我选了NodeMCU开发板，核心是ESP8266。选它理由很充分：第一，它自带Wi-Fi，这是实现在线管理的物理基础，而且ESP8266的Wi-Fi性能和稳定性经过多年市场检验，非常可靠；第二，它价格便宜，资源丰富，GPIO、ADC、PWM该有的都有，处理我们这个门禁逻辑绰绰有余；第三，社区支持极好，Arduino IDE和PlatformIO都能轻松开发，各种库很完善，出了问题网上能找到海量解决方案。

读卡器用的是经典的MFRC522芯片模块，支持13.56MHz频率，兼容ISO/IEC 14443 A标准。这个标准非常普遍，你手里的门禁卡、校园一卡通（ISIC）、甚至一些公交卡，很可能就是这个标准的。这意味着卡片来源很广，成本也低。RC522模块不仅能读卡的唯一ID（UID），还能读写卡片内部的存储区（一般是1K或4K字节），虽然我们这个项目主要用UID，但这个功能为未来扩展（比如在卡里存点个性化信息）留了可能。它的通信接口是SPI，和NodeMCU连接非常简单，速度也快。

2.2 电路连接与电源考量

接线方面，NodeMCU和RC522的SPI连接是固定的：

• RC522的SDA（SS）接 NodeMCU的D8(GPIO15)。这是片选引脚。
• RC522的SCK接 NodeMCU的D5(GPIO14)。
• RC522的MOSI接 NodeMCU的D7(GPIO13)。
• RC522的MISO接 NodeMCU的D6(GPIO12)。
• RC522的IRQ悬空不用，我们采用轮询方式读卡。
• RC522的GND和3.3V分别接NodeMCU的GND和3.3V。这里有个关键点：RC522必须接3.3V！接5V会烧毁模块。

门锁控制部分，NodeMCU的GPIO（比如D1）输出一个高/低电平信号，来控制一个继电器模块。继电器模块的输入端接NodeMCU的GPIO和GND，输出端相当于一个开关，串联在门锁（电磁锁或电插锁）的供电回路中。NodeMCU给出一个高电平信号（例如持续3秒），继电器吸合，锁体通电动作（开门）。为什么加继电器？因为NodeMCU的GPIO引脚驱动能力很弱（通常只能输出十几毫安电流），而电磁锁工作电流可能达到500mA甚至1A以上，必须通过继电器（或功率MOS管）来驱动。

注意：电源是门禁稳定的生命线。整个系统，包括NodeMCU、RC522和继电器模块，建议由一个稳定的5V/2A以上的直流电源适配器统一供电。NodeMCU板载稳压芯片会将5V转为3.3V供自身和RC522使用。电磁锁的电源应根据锁的规格（通常是12V）单独提供，但可以通过继电器的开关来控制其通断。务必确保电源功率充足，避免因锁体动作瞬间电流过大导致NodeMCU重启。

2.3 安全与冗余设计：网络与机械备份

任何在线系统都要考虑离线情况。我的设计是“网络优先，机械备份”。正常情况下，一切由云端决策。一旦网络断开（Wi-Fi故障或服务器宕机），NodeMCU会检测到无法连接服务器，此时系统可以进入一个降级模式：比如，亮起一个红灯提示“网络故障”。但门不能完全死锁。我的门锁本身带有机械钥匙孔，并且锁舌是可以通过内部把手机械操作的。这意味着，即使整套电子系统完全断电，依然可以用物理钥匙开门。这是安防系统设计的一个基本原则：电子系统提供便利和管理，但不能剥夺基本的机械逃生和访问途径。在电路设计上，确保电磁锁是“断电开锁”型（即通电上锁，断电解锁），这样在紧急断电时，门是处于可打开的状态。

3. 固件开发：NodeMCU端程序逻辑详解

NodeMCU端的程序，我称之为“哨兵固件”。它的核心职责明确：初始化、读卡、通信、执行。代码是用Arduino框架写的，逻辑清晰。

3.1 初始化与Wi-Fi连接

程序一上电，先初始化串口用于调试输出，然后连接Wi-Fi。这里我用了WiFi.begin(ssid, password)配合一个等待循环。为了提升用户体验，我加了一个状态指示灯（比如接在D4上的LED），快闪表示正在连接，常亮表示连接成功，慢闪表示连接失败。连接Wi-Fi的代码一定要有超时重试机制，并且将Wi-Fi信息（SSID、密码）放在程序开头的常量定义里，方便配置。

// 示例代码片段：Wi-Fi连接与状态指示 const char* ssid = "Your_SSID"; const char* password = "Your_PASSWORD"; const int wifiLedPin = D4; // 状态指示灯引脚 void setup() { pinMode(wifiLedPin, OUTPUT); digitalWrite(wifiLedPin, HIGH); // 先点亮，表示开始启动 Serial.begin(115200); WiFi.begin(ssid, password); int attempts = 0; while (WiFi.status() != WL_CONNECTED && attempts < 20) { // 尝试20次，约10秒 digitalWrite(wifiLedPin, !digitalRead(wifiLedPin)); // 快闪 delay(500); attempts++; Serial.print("."); } if (WiFi.status() == WL_CONNECTED) { digitalWrite(wifiLedPin, LOW); // 常亮表示成功 Serial.println("\nWiFi Connected!"); Serial.print("IP Address: "); Serial.println(WiFi.localIP()); } else { // 连接失败，进入慢闪错误模式 while(1) { digitalWrite(wifiLedPin, HIGH); delay(1000); digitalWrite(wifiLedPin, LOW); delay(1000); } } // 初始化SPI和RC522... }

3.2 卡片读取与UID处理

RC522的驱动我用了流行的MFRC522库。初始化后，固件进入主循环，不断调用mfrc522.PICC_IsNewCardPresent()和mfrc522.PICC_ReadCardSerial()来检测和读取卡片。读到的UID是一个字节数组。直接发送这个字节数组不太方便，我把它转换成了两种格式：十六进制字符串（如 “A1 B2 C3 D4”）和十进制数字字符串。数据库里我存储的是十进制的字符串，因为比较和查询起来直观。转换函数很简单：

String getDecUid(MFRC522::Uid uid) { long decUid = 0; for (byte i = 0; i < uid.size; i++) { decUid = decUid * 256 + uid.uidByte[i]; // 将字节数组合并成一个长整型 } return String(decUid); }

实操心得：防重入与读卡间隔。一张卡放在读卡器上，会一直被反复读取。必须在代码里做“防重入”处理。我的方法是：成功读取一张卡后，记录这张卡的UID和当前时间，然后在接下来的一段时间内（比如3秒），忽略同一张卡的读取事件。这能有效防止一次刷卡触发多次网络请求。同时，两次不同卡片的读取之间，我也设置了一个最短间隔（如500毫秒），避免过快操作导致系统响应不过来。

3.3 数据加密与HTTP通信

这是安全的关键一环。绝不能明文发送“卡号+开门指令”。我采用了一个简单的“挑战-响应”式加密（或叫签名）。NodeMCU和服务器共享一个密钥（Secret Key）。发送请求时，NodeMCU将“卡号（DEC格式）+ 当前时间戳（防止重放攻击）+ 密钥”拼接成一个字符串，然后计算这个字符串的MD5哈希值（或SHA1，ESP8266硬件支持SHA1，速度更快）。将卡号、时间戳和这个哈希值一起发送给服务器。

服务器收到后，用同样的算法和共享密钥验证哈希值是否正确，并检查时间戳是否在合理的时间窗口内（比如±30秒）。这样，即使请求被截获，攻击者也无法伪造有效的请求。在代码中，我使用ESP8266的WiFiClientSecure库（如果需要HTTPS）或普通的WiFiClient库，以POST方式将数据发送到服务器的PHP API接口。

// 示例：构造带签名的请求数据 String secretKey = "Your_Shared_Secret_Key"; String cardId = getDecUid(currentUid); unsigned long timestamp = millis(); // 或从NTP获取更准确的时间 String dataToSign = cardId + String(timestamp) + secretKey; String signature = sha1(dataToSign); // 实际使用需要实现SHA1计算 String postData = "card_id=" + cardId + "×tamp=" + String(timestamp) + "&sign=" + signature; // 然后使用HTTPClient库发送POST请求

3.4 响应解析与门锁控制

服务器处理后会返回一个JSON格式的响应，例如：{"status":"success","access":"granted","message":"Welcome"}或{"status":"success","access":"denied","message":"Card not authorized"}。NodeMCU解析这个JSON。如果access字段是granted，就触发开门动作：控制继电器引脚输出高电平，启动一个定时器（比如3秒），然后引脚恢复低电平，锁重新闭合。同时，可以控制一个绿色LED亮起或蜂鸣器响一声。如果是denied，则控制红色LED亮起或蜂鸣器响三声，门锁不动。

这里必须加入网络超时和异常处理。如果HTTP请求失败（服务器无响应、网络超时），固件不能死等。我设置一个请求超时时间（如5秒），超时后按“拒绝”处理，并可通过指示灯提示网络错误。整个通信和控制逻辑必须放在非阻塞的代码结构中，避免因为一次网络卡顿导致整个系统“假死”。

4. 服务器端架构与数据库设计

服务器端是这套系统的“大脑”，我用的是经典的LAMP栈（Linux, Apache, MySQL, PHP），当然你也可以用Nginx或其他语言（如Python、Node.js）实现，原理相通。

4.1 数据库表结构设计

数据库设计追求简洁高效，主要就两张表：

1. cards表（卡片信息表）这个表存储所有已知的卡片信息。

CREATE TABLE `cards` ( `id` int(11) NOT NULL AUTO_INCREMENT, `card_uid_dec` varchar(20) NOT NULL UNIQUE COMMENT '卡片十进制UID', `card_uid_hex` varchar(20) DEFAULT NULL COMMENT '卡片十六进制UID', `owner_name` varchar(100) DEFAULT NULL COMMENT '持卡人姓名', `owner_contact` varchar(100) DEFAULT NULL COMMENT '联系方式', `is_active` tinyint(1) NOT NULL DEFAULT '1' COMMENT '是否激活(1激活，0禁用)', `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` timestamp NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_uid` (`card_uid_dec`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

2. access_logs表（门禁记录表）这个表记录每一次刷卡尝试，无论成功与否，用于审计和查询。

CREATE TABLE `access_logs` ( `id` int(11) NOT NULL AUTO_INCREMENT, `card_uid_dec` varchar(20) NOT NULL COMMENT '刷卡的十进制UID', `access_result` enum('GRANTED','DENIED') NOT NULL COMMENT '访问结果', `denial_reason` varchar(255) DEFAULT NULL COMMENT '若拒绝，记录原因(如卡未授权、已过期等)', `reader_location` varchar(50) DEFAULT 'Main Entrance' COMMENT '读卡器位置（便于多门禁点扩展）', `request_ip` varchar(45) DEFAULT NULL COMMENT 'NodeMCU的IP地址', `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_card_time` (`card_uid_dec`,`created_at`), KEY `idx_time` (`created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

设计要点：cards表用is_active字段控制权限开关，这是实现远程管理的基础。access_logs表记录了完整流水，denial_reason字段在调试和用户询问时非常有用。reader_location字段为将来扩展多个门禁点预留了位置信息。

4.2 PHP后端API接口实现

我创建了一个简单的PHP文件作为API入口，比如api/check_access.php。它处理NodeMCU发来的POST请求。

第一步：验证签名。获取POST参数card_id,timestamp,sign。用相同的密钥和算法重新计算签名，并与收到的sign比对。同时检查timestamp是否在服务器当前时间的前后一定范围内（例如±2分钟），以抵御重放攻击。任何一步验证失败，直接返回{"status":"error","message":"Invalid request"}并记录日志。

第二步：查询数据库。签名验证通过后，用card_id去cards表查询。这里有个小技巧：先用一条SQL查询卡片状态，再决定是否允许通行。

$sql = "SELECT id, owner_name, is_active FROM cards WHERE card_uid_dec = ?"; $stmt = $pdo->prepare($sql); $stmt->execute([$card_id]); $card = $stmt->fetch(PDO::FETCH_ASSOC); if (!$card) { // 卡号不存在 $result = 'DENIED'; $reason = 'Card not registered'; } elseif ($card['is_active'] != 1) { // 卡号存在但被禁用 $result = 'DENIED'; $reason = 'Card deactivated'; } else { // 验证通过 $result = 'GRANTED'; $reason = ''; }

第三步：记录日志并返回响应。无论通行与否，都将这次尝试记录到access_logs表。然后，以JSON格式返回结果给NodeMCU。

$logSql = "INSERT INTO access_logs (card_uid_dec, access_result, denial_reason, request_ip) VALUES (?, ?, ?, ?)"; $logStmt = $pdo->prepare($logSql); $logStmt->execute([$card_id, $result, $reason, $_SERVER['REMOTE_ADDR']]); header('Content-Type: application/json'); echo json_encode([ 'status' => 'success', 'access' => strtolower($result), // 'granted' or 'denied' 'message' => $reason ?: 'Access ' . $result ]);

第四步：考虑性能与扩展。对于高频率刷卡的门禁，数据库连接和查询可能成为瓶颈。可以考虑使用PDO连接池（如果环境支持），或者引入一个内存缓存（如Redis）。将活跃的、有效的卡号UID列表缓存在Redis中，API接口先查Redis，查不到再去查MySQL。这能极大降低数据库压力，将响应时间从几十毫秒降到几毫秒。对于简单的门禁系统，如果并发量不高，直接查MySQL也完全够用。

5. 网页管理后台开发要点

管理后台的目标是让管理员能直观、方便地管理卡片和查看记录。我用了HTML、CSS（Bootstrap框架让界面快速成型）、JavaScript（jQuery）和PHP来实现。

5.1 用户认证与权限控制

后台所有页面都必须先登录才能访问。我建立了一个users表，存储管理员用户名和加盐哈希后的密码。登录时，验证用户名和密码，成功后使用PHP的session机制来维持登录状态。在每个需要权限的页面开头，都检查$_SESSION['user_logged_in']是否为真，否则跳转到登录页。这是Web安全最基本也是最重要的一环。

5.2 卡片管理功能实现

卡片管理页面主要是一个表格，展示所有卡片信息（UID、持有人、状态、注册时间），并提供“添加新卡”、“编辑”、“激活/禁用”、“删除”等操作。

添加新卡：有两种方式。一种是手动输入卡片的十进制UID和持有人信息。更实用的方式是“现场录入”。我在后台页面做了一个功能，当管理员把一张新卡放在读卡器上时，NodeMCU会像正常刷卡一样发送请求到服务器。我在API里加了一个“特权模式”：如果请求来自一个特定的、已知的管理员IP地址或带有特殊的管理员密钥，那么即使这张卡在数据库里不存在，API也会返回一个特殊的响应（如{"status":"new_card", "uid":"123456"}），并在后台页面上通过AJAX弹窗提示管理员：“检测到新卡UID: 123456，是否将其添加到系统并授权？” 管理员确认后，再调用另一个PHP接口将卡片信息写入数据库。这种方式录入卡片非常便捷准确。

激活/禁用：这就是修改cards表的is_active字段。点击“禁用”按钮，通过AJAX发送请求到toggle_card.php，后端更新数据库，前端页面即时更新按钮状态和卡片行样式（如将禁用的卡片行变为灰色）。这是权限管理的核心操作，立竿见影。

5.3 实时门禁记录展示

记录查看页面需要实时显示刷卡记录。我采用AJAX轮询的方式来实现“准实时”。页面加载后，JavaScript定时器每3秒（这个间隔可根据需求调整）向服务器发送一个AJAX请求，查询最新的门禁记录（例如get_latest_logs.php?last_id=xxx）。

服务器端根据客户端传来的最后一条记录的ID，返回比这个ID更大的新记录。前端收到数据后，动态地将新记录插入到表格的顶部。这样，管理员页面不需要刷新，就能看到不断刷新的进门记录，谁、什么时候、是否成功，一目了然。

// 简化的前端轮询示例 var lastLogId = 0; function pollNewLogs() { $.ajax({ url: 'get_latest_logs.php', data: {last_id: lastLogId}, dataType: 'json', success: function(data) { if(data.logs && data.logs.length > 0) { // 将新记录添加到表格顶部 data.logs.forEach(function(log) { $('#logsTable tbody').prepend('<tr><td>'+log.time+'</td><td>'+log.uid+'</td><td>'+log.name+'</td><td>'+log.result+'</td></tr>'); }); // 更新最后一条记录的ID lastLogId = data.logs[0].id; } }, complete: function() { // 3秒后再次轮询 setTimeout(pollNewLogs, 3000); } }); } $(document).ready(function() { pollNewLogs(); });

注意事项：AJAX轮询虽然简单，但会给服务器带来持续的小压力。如果在线管理员很多，可以考虑更高效的WebSocket技术，实现真正的服务器推送。但对于一个小型门禁系统的管理后台，轮询完全足够。记得在服务器端对查询做索引优化（access_logs表的created_at和id索引非常关键），并限制每次返回的记录条数（比如最多20条），避免数据量过大。

5.4 数据导出与报表

后台还应提供简单的数据导出功能，比如按日期范围导出access_logs为CSV文件，方便存档或进一步分析。这可以通过一个PHP脚本，查询数据库后，直接生成CSV格式的文本并设置HTTP头让浏览器下载即可。

6. 系统集成、调试与故障排查实录

硬件焊接好，代码写完了，后台也搭起来了，但把它们拼在一起稳定运行，才是真正的挑战。下面是我在集成和调试过程中踩过的坑和总结的经验。

6.1 硬件联调常见问题

问题1：RC522读卡不稳定，时灵时不灵。

• 可能原因A：电源干扰。RC522对电源噪声敏感。确保其3.3V供电来自NodeMCU板载稳压器，且NodeMCU本身的5V输入电源质量良好（纹波小）。可以在RC522的VCC和GND之间并联一个10uF和0.1uF的电容，进行退耦滤波。
• 可能原因B：SPI线过长或干扰。杜邦线尽量短，并远离电源线等可能产生干扰的线路。如果必须引线较长，可以尝试降低SPI时钟速度（在MFRC522库初始化代码里可以设置）。
• 可能原因C：卡片类型。确保使用的是MIFARE Classic 1K等RC522支持的卡片。有些带有复杂加密的CPU卡，RC522可能无法读取UID。

问题2：继电器动作时，NodeMCU会重启。

• 根本原因：电流冲击。电磁锁在吸合瞬间电流很大，可能导致电源电压瞬间被拉低，触发NodeMCU的欠压重启。
• 解决方案：
  1. 电源隔离：为电磁锁单独供电，与NodeMCU的控制电路完全分开。两者之间“地”要连接，但正极独立。
  2. 续流二极管：在电磁锁线圈两端反向并联一个二极管（如1N4007），吸收断开时产生的反向电动势，保护继电器触点。
  3. 加大电源容量：使用功率更足、动态响应更好的电源适配器。
  4. 软件消抖：在控制继电器动作的代码前后加短暂延时，避免短时间内频繁开关。

6.2 网络与通信调试

问题3：NodeMCU频繁断开Wi-Fi重连。

• 可能原因A：路由器信号弱或不稳定。检查NodeMCU与路由器的距离和障碍物。可以尝试在代码中增加Wi-Fi信号强度监测，低于某个阈值时告警。
• 可能原因B：ESP8266的深度睡眠（如果用了）或电源管理问题。确保代码中没有意外进入深度睡眠模式。尝试在setup()中加入WiFi.setSleepMode(WIFI_NONE_SLEEP);来禁用Wi-Fi睡眠，以获得更稳定的连接（代价是功耗稍高）。
• 可能原因C：路由器设置。有些路由器的“无线隔离”或“AP隔离”功能会阻止设备间通信，确保NodeMCU能与服务器IP通信。

问题4：HTTP请求超时或失败。

• 排查步骤：
  1. Ping测试：在服务器上，尝试ping一下NodeMCU获取到的IP，看网络是否通畅。
  2. 本地测试：先用电脑浏览器或Postman工具，直接访问服务器的API地址（http://你的服务器IP/api/check_access.php），看是否能正常返回（可能是预设的错误信息）。这能排除服务器端PHP或Web服务器（如Apache）配置问题。
  3. 查看NodeMCU串口日志：在setup()和请求发送/接收处加入详细的串口打印，查看请求是否成功发送、服务器返回了什么状态码和内容。ESP8266的HTTPClient库返回的状态码（如200、404、500）是重要的调试信息。
  4. 检查防火墙：确保服务器防火墙（如iptables, ufw）开放了Web服务端口（通常是80或443）。

6.3 数据库与后台问题

问题5：后台添加卡片后，刷卡依然被拒绝。

• 检查流程：
  1. 核对UID格式：确认NodeMCU发送的十进制UID，与后台录入的UID完全一致（字符串比较，注意首尾空格）。最好在后台卡片列表里，显示NodeMCU最近一次发送的原始UID，用于比对。
  2. 检查卡片状态：确认后台该卡片的is_active字段是1。
  3. 查看API日志：在check_access.php中，将每次查询的SQL语句和结果记录到文件或数据库的调试表中。这是定位问题最有效的方法。
  4. 时区问题：如果API使用了时间戳防重放，确保服务器和NodeMCU的时钟基本同步。可以为NodeMCU增加NTP对时功能。

问题6：后台页面AJAX轮询不更新或很慢。

• 可能原因A：数据库查询慢。检查access_logs表是否在created_at和card_uid_dec上建立了索引。没有索引的话，随着记录增多，查询会越来越慢。使用EXPLAIN命令分析你的查询语句。
• 可能原因B：PHP会话（session）锁。默认情况下，PHP会话文件是阻塞式的。如果AJAX请求和页面其他请求共用同一个会话，可能会发生锁等待。对于纯AJAX的接口，如果不需要会话信息，可以在该PHP脚本开头调用session_write_close()尽早释放会话锁。
• 可能原因C：前端JavaScript错误。打开浏览器的开发者工具（F12），查看“控制台(Console)”是否有JS报错，“网络(Network)”标签页查看AJAX请求是否成功发出并返回。

6.4 安全加固建议

1. HTTPS：在生产环境，务必为你的Web后台和API启用HTTPS。ESP8266支持HTTPS（WiFiClientSecure），虽然会增加一些资源开销，但能防止卡号和密码在传输中被窃听或篡改。可以使用免费的Let's Encrypt证书。
2. API密钥轮换：NodeMCU与服务器共享的密钥（Secret Key）应定期更换。可以在数据库为每个NodeMCU设备（通过唯一ID或MAC地址标识）存储一个密钥，并在后台提供密钥重置功能。
3. SQL注入防护：务必使用参数化查询（如PDO的prepare和execute），如我上面的示例代码所示，绝对不要将用户输入（即使是来自NodeMCU的输入）直接拼接进SQL字符串。
4. 后台访问限制：将管理后台的访问IP限制在管理员办公室的IP段，并在路由器上设置防火墙规则，进一步减少暴露面。
5. NodeMCU固件更新：保留一个OTA（空中升级）功能，以便未来发现安全漏洞或需要增加功能时，可以远程更新固件，而无需物理接触设备。

这个项目从构思到实现，涉及了嵌入式硬件、网络通信、服务器后端和Web前端，是一个典型的物联网全栈小应用。把它调通、跑稳的过程，就是对整个系统理解不断加深的过程。最大的体会是，稳定性高于一切。门禁系统一旦部署，就要7x24小时可靠工作。因此，每一个环节——电源、信号、网络、代码异常处理——都必须考虑周全，并经过充分的长时间拷机测试。当看到刷卡、云端判断、开门、记录生成这一系列动作流畅完成时，那种把想法变成实物的成就感，正是折腾这类项目的乐趣所在。