投屏软件最容易给人一种错觉：只要手机能出现在墙上，主要工作就完成了。真正开始连续使用，问题才会一起冒出来。墙面会突然不动，某台主机断开后列表里像从未存在过，提示框把整个界面挡住，网络重连在日志里刷成一片，开发者想找原因却拿不到一份可以交给别人的诊断信息。
这次遇到的场景就是这样。表面看起来像程序死锁，实际上是界面事件阻塞和远端主机瞬时不可达叠加在一起。修复也没有停在“重新连上”这一步，而是继续追问：掉线时用户还能不能操作？失败是否可见？重连会不会制造新的噪声？性能有没有数字证据？诊断包会不会泄露信息？真实手机上的输入路径是否真的成立？
商用级不是把“成功连接”做得更漂亮，而是让失败、等待和恢复都变得可理解、可操作、可验证。
卡住的表面，往往不是唯一原因
当时最先看到的是墙面卡住。采样结果里，界面线程几乎一直停在一个 QLabel 的鼠标释放事件调用链上，看起来很像某个锁没有释放。但继续看启动过程，又发现另一条线：某台远端主机在启动瞬间不可达，准备阶段把它静默丢掉了。于是墙面既没有及时完成界面交互，也没有保留那台主机的失败状态。
这两件事叠在一起，用户看到的就不是“某台主机暂时连不上”，而是“整面墙像死了”。如果只盯着线程采样，很可能会把所有时间花在寻找死锁；如果只盯着网络，又会误以为重新启动连接就够了。真正的问题是，系统把两个本应分开处理的状态，压缩成了一个模糊的卡住。
我一开始也容易把“卡住”理解成一个单点故障。后来发现，商用软件不能只按异常名称修复，而要把用户感知拆开：界面是否还能响应，主机是否仍在状态里，画面是否正在恢复，提示是否会打断当前工作。不同问题要有不同的处理路径，否则一个修复很可能只是把故障从一个地方挪到另一个地方。
第一原则是让失败留在状态里
启动时连接失败，最省事的做法是把失败的主机从待处理列表里删掉。这样程序可以继续启动，日志也显得干净，但用户看不到它曾经存在，更不知道为什么设备数量少了。下次网络恢复后，系统也没有一个明确的对象可以继续恢复。
这次修复选择保留不可达主机，让它进入程序的正常状态流，界面显示“主机连不上”，同时把原因写入启动记录和日志。这个决定看起来只是多显示一张卡片，实际上改变了整个系统的责任边界：失败不再由启动器私下吞掉，而是成为产品状态的一部分。
我选择这样做，是因为投屏场景里“现在不可达”并不等于“这个主机不存在”。无线网络、隧道和远端服务都可能在几秒后恢复。把对象保留下来，程序才有机会继续等待、重连和更新；把对象丢掉，用户只能靠猜测重新启动。
如果不处理这个问题，会导致设备数量看起来随机变化，使用者会以为手机少了、配置坏了，排查时也没有明确线索。更严重的是，团队可能为了追求启动成功率，把所有失败都从统计里删掉，最后得到一个“看起来很稳定”的假象。
非阻塞不是界面技巧，而是操作权
另一个关键问题来自提示框。点击“不在某个数量的手机”后，程序使用模态消息框等待用户处理。桌面系统的模态调用会让当前事件循环停在等待状态，于是墙面和其他控件一起失去响应。提示内容也许是正确的，但它以阻塞整个产品为代价。
这里最容易误判的错误捷径，是把所有异常都做成醒目的弹框。弹框很容易被看见，所以看起来比状态栏更“负责”；但投屏墙通常是持续运行的工作界面，用户可能正在看其他设备、翻页或准备操作。一个提示不应该为了被看见，就夺走用户对其他设备的控制权。
这次把普通通知改成非阻塞窗口，用显示而不是等待执行的方式呈现；“不在的手机”则改成常驻面板，随着缺失状态变化实时刷新。只有卸载、重启、删除这类需要明确确认的动作保留确认框。这个区分很重要：通知是告诉用户发生了什么，确认是要求用户承担一个不可逆选择，两者不应使用同一种交互。
非阻塞交互的核心不是让窗口更轻，而是把继续工作的权利还给用户。
如果不这样处理，任何一条异常都可能把整面墙拖进暂停状态，用户甚至无法查看其他设备来判断故障范围。界面看似在“提醒”，实际却制造了更大的故障。一个成熟的规则是：提示可以出现，但主工作流不能因为提示而停止；只有真正需要确认的破坏性动作，才允许暂时拦住用户。
重连要有耐心，日志也要有边界
无线设备的短暂不可达很常见。最直接的重连方式是固定每 3 秒试一次，直到成功。它确实可能更快恢复，却会在网络长期不可用时持续制造连接请求和日志。多台设备同时失败时，重复信息会把真正有用的线索淹没，程序自己也在不断做无收益的工作。
这次采用逐步退避，重连间隔从 3 秒逐步拉长到 30 秒，并把同一主机下的多台失败合并成一条提示。验证时，连续观察 65 秒只留下 1 行重连日志，没有继续刷“无路由”信息。这里的目标不是让系统永远安静，而是让每一条日志都更接近一次状态变化，而不是一次徒劳的循环。
我没有选择“失败就立即停止重连”，因为投屏设备的网络恢复通常不需要用户重新配置。也没有保留固定高频重试，因为它会把瞬时故障放大成持续负担。退避是一种折中：刚断开时积极恢复，长时间失败时降低打扰，状态仍然保留，恢复机会也没有被放弃。
商用验收必须有数字和证据
“翻页感觉顺”不能作为性能结论。为了验证错开设备恢复操作是否真的有效，连续翻页恢复 12 台设备，循环执行了 52 次。结果是界面线程最长卡顿 56ms，没有一次超过 100ms；出画面时间 p90 为 0.826 秒，另一端的结果也没有变慢。之前偶发的 200–430ms 卡顿因此有了可比较的改善，而不是停在主观感受上。
诊断能力也需要验收。程序增加了诊断包导出入口，分别在两端生成并检查内容，完整序列号、授权码、家目录和无线网络地址等敏感字段都归零；连续 10 次启动退出没有崩溃。这里的“能导出”只是功能存在，“内容脱敏且反复启动稳定”才接近可交付。否则，支持人员拿到的可能是一份泄露隐私的压缩包，或者一份偶尔生成失败的半成品。
输入更不能只在模拟环境里验收。真实手机上，英文“wifi”分别通过控制通道和 adb 输入，中文“剑飞”通过剪贴板粘贴，最终都在搜索框中出现并得到结果。中间还遇到输入法首次使用的隐私协议框；在获得明确授权后只点了一次同意，其他设置、账号和设备没有改动。这个细节说明，真机测试不只是按下几个键，还要把环境前置条件、授权边界和回收动作一起记录下来。
一个功能是否商用，不看它在理想路径上能不能跑通，而看失败路径是否留下了可复核的证据。
从一次修复变成验收矩阵
这件事让我重新意识到，商用质量不是一张“功能已完成”的清单，而是一组彼此咬合的证据。我的方法是把验收拆成 6 个问题：状态是否可见，交互是否阻塞，重连是否退避，诊断是否可交付，性能是否有指标，真机路径是否成立。
每个问题都要同时写清预期行为、失败后果和验证证据。比如主机不可达，预期不是“最终连上”，而是“保留对象、显示状态、等待恢复”；非阻塞提示，预期不是“弹出来”，而是“提示出现后墙仍能操作”；诊断包，预期不是“有压缩文件”，而是“敏感字段归零、重复启动不崩溃”。这样做的好处是，开发、测试和交付讨论的是同一件事。
这套矩阵也能防止把未完成的工作误报成完成。翻页性能已经有数字，诊断包已经有脱敏和稳定性证据，输入路径已经在真实手机上跑通；但如果某条输入分支没有单独覆盖，就应该保留这个边界，而不是用相邻测试替它背书。商用级的诚实，和商用级的技术同样重要。
下次我会怎么做
下次遇到“软件卡住了，顺便做到商用级”的要求，我会先把卡顿拆成界面、网络和状态管理 3 条线，再确定每条线的可见状态和恢复策略。任何会阻塞主事件循环的提示，先问它是否真的需要用户确认；任何会被静默丢弃的连接对象，先问它恢复时还是否有身份可追踪。
然后我会在修复前就写出验收矩阵：性能用卡顿上限和 p90，网络用退避周期与日志数量，诊断用敏感字段和重复启动，输入用真实设备与具体路径。验证时把成功、失败、环境阻塞和尚未覆盖分开记录，不用一句“基本没问题”替代证据。
真正难的不是让投屏软件偶尔显示一张画面，而是让它在连接失败、操作被打断、设备恢复和用户需要求助时，仍然保持清楚。一个流程成熟的标志，不是它能在顺利时跑通一次，而是下一次遇到同类故障时，系统知道该保留什么、用户知道还能做什么、团队知道应该拿出哪份证据。