onMessage必须校验imei、firmware_name、core_version、version四个参数，其中firmware_name需统一小写，version须语义化比对；数据库查firmware_info和device_firmware_log表，firmware_name字段须建B-tree索引；响应用text/plain格式，键值对换行分隔，显式设置Content-Type头。

Workerman作为OTA服务器接收固件版本请求时，onMessage必须校验哪些参数？

Workerman本身不处理固件逻辑，只做HTTP路由和参数解析。关键不是“能不能接”，而是“接什么才安全可靠”。onMessage里至少要提取并验证：imei（设备唯一标识）、firmware_name（区分多型号）、core_version（用于语义化比对）、version（当前固件版本号）。漏掉imei会导致所有设备共用同一响应，无法做灰度或回滚；漏掉firmware_name则可能把RDA8910的固件推给EC200U设备。

常见错误现象：设备反复收到“无新版本”响应，实际是firmware_name拼写不一致（比如LUAT_IOT_SERVER_UPDATE_Luat_RDA8910 vs luat_iot_server_update_luat_rda8910），而服务端没做大小写归一化。

• 建议在onMessage开头就做strtolower()统一处理firmware_name
• version字段不能直接字符串比较，需拆成major.minor.patch三段整数比对
• 若业务要求强校验，可额外检查dfota（是否启用差分升级）和project_key（防未授权访问）

返回固件下载地址前，Connection.php数据库查询该查哪几张表？

合宙Luat方案中，SQL/Connection.php只是MySQL连接封装，真正要查的是业务表。典型结构是两张表：firmware_info存每个firmware_name最新版本元数据（含version、url、md5、changelog），device_firmware_log记录设备每次上报的版本快照（用于分析升级失败率）。不要查users或devices主表——OTA决策只依赖固件版本关系，不依赖用户权限。

性能影响明显：如果onMessage里执行SELECT * FROM firmware_info WHERE firmware_name = ? ORDER BY id DESC LIMIT 1，且firmware_name字段没建索引，1000台设备并发查询会拖垮MySQL。

• 必须为firmware_name加B-tree索引
• 避免SELECT *，只取version、url、md5三个字段
• 若支持差分升级，还需查delta_patch表，条件是from_version = ? AND to_version = ?

Workerman返回HTTP响应时，Response对象的header和body怎么设才算合规？

设备端（如Luat模块）解析HTTP响应极简，不认Content-Type: application/json，只吃纯文本键值对。所以不能用json_encode()返回，而要用text/plain格式拼接。例如正确响应是：version=1.2.0\nurl=http://ota.example.com/firmware.bin\nmd5=abc123...。多一个空格、少一个换行，Luat的http.get回调就拿不到完整字段。

容易踩的坑：用Response::ok($body)时，默认带Content-Type: text/html，某些旧版Luat固件会因MIME类型不匹配直接丢弃响应。

• 必须显式调用->withHeader('Content-Type', 'text/plain')
• 每行结尾用\n，别用\r\n（Luat解析器不兼容CRLF）
• url值必须是绝对路径，不能是/firmware.bin这种相对地址
• 若需支持断点续传，得加Accept-Ranges: bytes头，但Luat默认不发Range请求，此头可省

为什么Workerman进程重启后，onWorkerStart里的$db全局变量会失效？

Workerman的onWorkerStart在每个子进程启动时执行一次，global $db只在当前进程有效。但onMessage回调可能被调度到任意子进程，若没在每个onMessage里重新检查$db连接状态，就会遇到Call to a member function query() on null错误——尤其在MySQL服务短暂中断又恢复后，旧连接已死，新请求却还在用失效句柄。

这不是Workerman bug，是PHP常驻进程模型的必然约束。合宙示例代码里没做连接保活，上线后大概率出问题。

• 在onMessage开头加if (!$db || !$db->connected) { $db = new \Workerman\MySQL\Connection(...); }
• 或者改用连接池（如workerman/mysql-pool），但会增加部署复杂度
• 更稳妥的做法：把数据库操作抽成独立服务（如HTTP微服务），Workerman只做协议转发，彻底解耦

真正的难点不在代码行数，而在设备端与服务端对“版本”“URL”“校验方式”的隐式契约是否完全对齐。哪怕Workerman返回了正确的url，如果固件BIN文件没按Luat要求的CRC16分块格式预处理，设备下载后校验失败，整个OTA流程就卡在最后一步。