工业终端换上 Wi-Fi 6 就不会掉线了吗？从无线漫游到业务恢复的排查方法

仓储现场有一种常见故障：手持终端显示仍然连接 Wi-Fi，业务应用却一直转圈；走过某个货架通道后，提交操作偶尔超时；重新打开应用，又恢复正常。

遇到这类问题，首先更换支持新一代 Wi-Fi 的终端，未必能解决。无线连接、IP 网络和业务会话处于不同层次，任何一层异常，都可能表现为“掉线”。

一次业务中断，可能发生在哪一层

可以先把故障拆成四层：

无线图标只能提供有限信息。它不能证明请求已经到达服务端，更不能证明业务已经成功提交。

Wi-Fi 6 的部分机制有助于改善特定条件下的无线效率，但跨接入点移动还涉及客户端策略、网络配置与兼容性。

常被提到的三类机制分别是：

802.11k：提供无线测量及邻居信息，辅助客户端发现候选接入点；

802.11v：提供网络管理机制，其中包括接入点切换建议；

802.11r：在兼容且配置适当的条件下，减少快速切换时的部分认证开销。

这些能力需要终端与网络侧配合。支持相关标准，不意味着所有配置下都会获得相同效果。

漫游也不只是“信号弱了换一个接入点”。终端如何选择候选接入点、什么时候开始扫描，以及切换后业务是否恢复，都影响用户体验。

可以将业务中断近似拆解为：

$_{业务中断总时长 \approx 候选接入点发现耗时 + 接入点切换耗时 + 网络恢复耗时 + 应用业务恢复耗时。}$

这个表达式用于定位问题，各阶段在实际系统中可能重叠，不能当作严格互斥的计时关系。

如果接入点切换很快，但应用等待旧请求超时后才重试，用户仍会感到明显卡顿。如果服务器已经写入业务数据，而确认响应在切换期间丢失，客户端还可能出现“显示失败，实际已提交”的情况。

因此，业务设计还需要处理重复提交和结果确认。例如，使用唯一业务请求标识，由服务端识别重复请求，比简单地无限重发更可靠。

建议在获得授权的测试网络中，固定终端软件版本、网络配置和业务版本，沿实际作业路线重复测试。

同步记录：

当前接入点标识与切换时间；

无线信号及链路事件；

请求发出、服务端接收和客户端收到响应的时间；

请求标识、超时与重试次数；

地址是否发生变化。

多端日志需要统一时钟或校正时差，否则容易把时间戳偏差误判为网络延迟。

结果不宜只给平均值。可同时报告业务请求延迟的 P50、P95、P99，以及请求失败次数。平均值较低但偶发长时间中断的系统，仍然可能影响连续拣货。