不能。Workerman本身不提供硬件驱动能力，无法直接调用身份证阅读器或摄像头，仅负责接收前端设备上报的结构化核验结果，不做图像处理或加密解密。
Workerman 能不能直接做身份证读取和人脸比对？
不能。Workerman 本身不提供硬件驱动能力，它无法直接调用身份证阅读器或摄像头。所谓“身份比对”在自助机里是分层实现的：前端设备（如鹿马自助机）完成证件芯片读取、OCR识别、活体人脸采集与比对，并把结果（如 {"id_number":"110101199001011234","face_match":true}）通过 HTTP 或自定义 TCP 协议上报给后端服务。Workerman 在这里只负责接收这个结构化结果，不做图像处理或加密解密。
常见错误是试图在 Workerman 进程里加载 libusb 或调用 opencv_php 扩展——这既不可靠（多数政务/酒店终端禁装扩展），也违背其轻量定位。正确做法是让嵌入式 Linux 系统上的独立服务（如 C++ 写的本地 agent）完成硬件交互，再通过 file_get_contents("http://127.0.0.1:8080/api/capture") 或 Unix socket 向 Workerman 推送数据。
如何用 Workerman 同步触发 PMS 房态更新与门锁授权？
关键不是“同时发请求”，而是保证事务边界清晰、失败可追溯。PMS 和门锁系统通常使用不同协议（HTTP REST / TCP 私有协议 / MQTT），且响应延迟差异大（PMS 可能 200ms，门锁网关可能 800ms）。Workerman 的 onMessage 回调里必须拆成异步任务链，而不是阻塞等待：
- 收到核验成功消息后，立即向 PMS 发起
/api/v1/checkin请求（带重试+超时）； - 在 PMS 返回
{"status":"success","room_id":"308"}后，再触发门锁指令下发（例如调用lock_api::issue_key($room_id, $expire_ts)）； - 任一环节失败，必须写入本地
failed_tasks表，并启动后台轮询补偿，不能丢弃或仅打日志。
漏掉补偿逻辑是上线后最常出问题的地方——比如门锁网关临时断连，Workerman 连接超时后直接返回错误，前台却显示“入住成功”，导致客人到房间开不了门。
为什么不能用 Workerman 直接生成房卡密钥？
密钥生成必须由可信环境完成，Workerman 进程不具备安全隔离能力。真实部署中，房卡密钥（尤其是 NFC 卡密钥或动态二维码签名）需由专用密钥服务（如 HSM 模块或酒店自建 KMS）生成，Workerman 只负责转发请求和缓存授权结果。
典型流程是：Workerman 收到核验结果 → 调用 https://kms.example.com/v1/key?room=308&valid_hours=24 → KMS 返回加密后的 key_blob 和有效期 → Workerman 将其透传给自助机前端或推送到手机 App。若跳过 KMS 直接用 openssl_encrypt() 在 PHP 里算密钥，一旦服务器被渗透，所有门锁密钥即刻失效。
另外注意：门锁系统往往要求指令带时间戳和一次性 nonce，Workerman 必须确保每条指令的 nonce 全局唯一且防重放，不能简单用 microtime(true) 拼接。
Workerman 连接断开时，房卡发放状态怎么兜底？
自助机前端必须自带离线能力：当检测到与 Workerman 后端连接中断，应启用本地缓存的最近一次成功授权记录（含房间号、有效期、密钥摘要），允许有限次数的“无网络发卡”，同时在界面上明确提示“已离线办理，联网后自动同步公安与PMS”。
Workerman 侧则需配合实现：在恢复连接后，主动拉取未确认的核验事件（通过 /api/v1/pending?since=1748299200），并重放关键操作。不要依赖前端“重试上传”，因为前端可能已被重启或断电。
这个离线-重连闭环最容易被忽略，但恰恰是酒店场景的刚需——很多酒店弱网环境（地下室、老建筑）下，PMS 和门锁网关都可能短暂失联，系统必须能扛住分钟级断连而不丢业务状态。
