凌晨两点，产线停了。
手持终端扫不了工单二维码。班长翻出白天的群，最新一条是“这个也能装”。文件名没有版本号。工程师远程一看：那是下午实验用的调试包，没走完产线回归。
工业 IoT 手持终端的配套 App 往往连着仓库、工单和扫码枪底座。它不是给一个人试用的玩具。群文件却把它当成一张表情包在传。
群里的“最新”对产线没有意义
白天，研发可能连发三个包：修崩溃的、试新扫码库的、准备明天验证的。群成员凭感觉点最后一个。夜班没有人知道哪个通过了产线用例。
调试包还可能打开额外日志、连着测试服务器、关掉签名校验。它不该出现在工位上。
工业现场还有第二个约束：同一条产线的几十台终端，必须停在同一个构建。谁先装谁后装，不能靠谁先点开群文件。
产线只认一个当班入口
-
1. 研发实验包走邀请或密码，不进产线码。
-
2. 产线码固定到当班验证过的版本，而不是自动追逐每一次上传。
-
3. 换班验证通过后，再把产线入口切到新构建，并留下可回退的旧版链接。
-
4. 页面写清终端型号、安卓版本和是否允许未知来源。
方法的核心是：传包的人和装包的人，不再共用同一个聊天窗口当版本库。
蒲公英用来分开实验和产线，不是用来代替产线验收
根据文档，同一应用可生成多个渠道短链。渠道能自动同步最新，也能指定版本。产线渠道应固定到验证构建；研发渠道可以跟随最新实验包，并用密码或邀请限制访问。
应用默认内测模式，下载次数受限。产线几十台设备集中安装前，要在目标账号查看额度，必要时申请分发模式。审核通过前，不要假设夜班还能继续装。
同一应用短地址指向最新版。若产线码误用了应用级短地址，下午随手上的实验包会在夜里变成“官方最新”。产线必须用指定版本的渠道链接或历史版本的固定链接。
Android 同包名不同签名无法覆盖安装。产线终端上午装了正式签名，夜里再装调试签名，会直接失败。iOS 工业平板若使用 Ad Hoc，每台设备 UDID 都要进描述文件。
Webhook 和成员通知可以把新版本推给研发，但不能代替“产线用例已通过”这一闸门。上传成功也不等于发布完成，自动化接入时应按文档轮询结果。
下一班开工前
-
• 群里是否还在传产线包；
-
• 产线码是否固定到当班版本；
-
• 实验包是否被密码挡住；
-
• 回退链接有没有人知道。
工业手持终端不怕油污。
它怕的是，版本真相住在一个会刷屏的群里。
