一个手持终端拣货流程从后端收到了目标字段，但当该字段使用约定的星号哨兵值时，页面不显示目标，暂存和确认按钮也无法通过必填校验。

普通目标值一直正常，因此最初看起来像是接口偶发缺字段。沿着响应、页面状态和提交参数逐层检查后，问题被定位到客户端的一段“规范化”逻辑。

证据

后端响应中存在字面星号，数据模型也允许字符串原样保存。客户端在把字段写入页面状态前，却主动将星号转换成空串。

这个转换影响的不只是显示文本。同一个规范化结果还被用于：

• 商品卡片和确认弹窗回填；
• 目标字段的必填判断；
• 暂存及确认请求的目标参数。

因此一个看似只为界面清理而写的条件，同时切断了展示、校验和提交三条链路。

根因

星 …

一个使用 Gradle 6.8 和 Android Gradle Plugin 4.2 的老 Android 项目，在 extractDeepLinks 任务失败，错误提示 Java 模块没有开放 java.io。这个错误通常出现在老构建工具运行于较新的模块化 JDK 上。

奇怪的是，同一个 PowerShell 窗口执行 java -version 明明显示 JDK 8。继续围绕代码、Manifest 或 Build Tools 警告排查，很可能浪费时间。

PATH 与 JAVA_HOME 不是一回事

java -version 只说明 shell 从 PATH 中找到的 java.exe …

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

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

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

原实现把多张标签拼成一个较大的字节流，通过一次连接全部写入。这个方式代码简单，但现场链路一旦抖动，就很难判断打印机已经接收 …