RF 热敏打印弱网排障：逐张发送、写入边界与安全重试

一台仓库 RF 设备连续打印多张包裹标签时，经常在中途停住。相同打印机从电脑端使用基本正常，因此最初很容易把问题归因到模板、打印机缓存或 Android 代码。

真正有用的证据来自三处：应用发送日志、打印任务的张数位置，以及 RF 到打印机的网络质量。日志显示前几张标签已经完成 TCP 连接和写入，下一张却在连接阶段超时；同时 RF 侧出现明显丢包，而电脑侧连接仍然稳定。问题不是某一张标签内容损坏，而是热点链路在打印机处理任务时短暂不可连接。

为什么一次发送整批数据不可靠

原实现把多张标签拼成一个较大的字节流，通过一次连接全部写入。这个方式代码简单，但现场链路一旦抖动，就很难判断打印机已经接收了多少数据。直接重试整个字节流还可能重复打印前面已经成功的标签。

第一步改造是把每张标签构造成独立、完整的打印任务，每张分别建立连接并顺序发送。这样日志可以明确记录当前是第几张，失败也能限制在单张任务内。

不过逐张发送仍不足以解决问题。首次复测显示前几张成功，下一张的连接仍可能超时。于是需要加入重试，但重试必须有边界。

安全重试的边界

关键判断不是“是否发生异常”，而是异常发生时有没有开始向 socket 写入：

• TCP 连接尚未建立，或连接拒绝、连接超时：可以等待后重试同一张。
• 已经开始写入数据后失败：不自动重试，避免打印机实际已收到数据而客户端误判失败，造成重复标签。
• 每张标签限制最大尝试次数，超过后终止整批任务并保留明确错误。

实现中同时放慢了发送节奏：提高连接超时、在标签之间留出打印机消化时间，并在整批结束后延迟回调成功。日志增加任务序号、尝试次数、是否可重试以及是否已经写入等字段。

验证方式与安全重试结论

代码通过 Android 构建并安装到真实 RF 设备。验证不只看“弹出成功提示”，而是同时检查：

1. 日志是否按顺序出现从第一张到最后一张的任务编号；
2. 弱网时是否在同一张标签上出现连接阶段重试；
3. 已开始写入的失败是否被正确阻止重试；
4. 单张和多张打印、业务数量同步以及其他打印路径是否保持原行为。

这次排障的核心经验是：网络打印的可靠性不能只靠增加超时。先把批量任务拆成可观察的最小单元，再用“是否已经产生外部副作用”划定重试边界，才能同时兼顾连续打印成功率与防重复。