ESP32订阅MQTT主题异常：无法接收数据且频繁断连

核心排查方向 #

1. 连接参数一致性检查 #

• 确保两块ESP32使用的**MQTT Broker地址、端口、认证信息（用户名/密码）**完全一致。
• 客户端ID必须唯一，两块板子不能使用相同的客户端ID，否则MQTT Broker会主动踢掉先连接的设备，导致频繁断连。

2. 主题格式验证 #

• 测试将主题room 1改为无空格格式（如room_1），部分MQTT客户端库对带空格的主题解析存在兼容性问题。
• 确认订阅端订阅的主题字符串与发布端完全匹配，包括大小写、特殊字符（如果有）。

3. MQTT客户端配置优化 #

• 匹配发布端与订阅端的QoS等级：若发布端使用QoS 1/2，订阅端需设置相同或更低的QoS，避免消息传递失败。
• 订阅操作必须放在连接成功回调函数中执行，确保只有在Broker连接建立后才发起订阅请求，避免无效订阅导致的异常。
• 调整心跳间隔（keepalive）：建议设置为60秒，同时确保客户端能按时发送心跳包，防止Broker因超时判定设备离线而断开连接。

4. 网络与Broker有效性验证 #

• 确认两块ESP32连接同一WiFi网络，且网络无IP冲突、防火墙未限制MQTT端口（默认1883，加密端口8883）。
• 使用MQTT调试工具（如MQTTX）直接订阅目标主题，验证发布端的消息是否能正常到达Broker，以此区分是Broker问题还是ESP32订阅端代码问题。

5. 代码逻辑排查 #

• 检查订阅端的消息回调函数是否正确注册：以Arduino框架为例，需确保client.setCallback()在连接前调用，且回调函数参数格式符合要求（示例：void callback(char* topic, byte* payload, unsigned int length)）。
• 添加串口打印调试：输出连接状态（client.state()返回的错误码）、订阅结果、消息接收日志，定位是否存在崩溃、内存泄漏或逻辑异常。
• 排查发布端的消息发布逻辑：确认未设置错误的保留标志或重复标志，避免订阅端无法解析消息。

内容的提问来源于stack exchange，提问作者Karthikeya Sri