连接质量下降需被显式告知而非静默降级
别名: 降级提示 · 连接状态显式化 · 静默降级问题
概念解释
网络变差时，协作系统通常会静默降级：消息延迟到达、对方的更新变慢、视频清晰度悄悄下降——功能还在运转，只是质量滑坡，而界面一言不发。用户于是拿着「一切正常」的假象继续工作：以为对方没回是没看见、以为内容没变是真的没变、以为对方卡住是人的问题。连接质量下降必须显式告知：哪里在降级、降到了什么程度、此刻的操作还能不能信。判据不是技术指标，而是用户决策依赖——只要降级会改变「接下来该怎么做」的正确答案，就必须说。
机制
静默降级的伤害在于归因错误。用户看不到网络层，只能从表现倒推原因：对方消息来得慢→「他在忙」；我的修改没出现在共享文档→「我操作错了」；画面定格→「对方停止了操作」。每个错误归因都引发错误行动——催促、重复操作、重新输入，这些行动本身又加重网络负担，形成恶性循环。更隐蔽的是信任的错位消耗：用户把网络问题记在协作者头上（「这人总掉链子」）或系统头上（「这软件不可靠」），而两者都不是可修正的原因——不知道是网络，就无法通过换地方、换网络、错峰来自救。显式告知把归因通道接到正确的对象上：标出「连接不稳定」，用户立刻知道该等、该重试还是该切换网络，也知道此刻看到的状态可能是滞后的，不会拿它当最新事实做决定。
边界
告知的强度要与降级的决策相关性匹配，不是越显眼越好。毫秒级的抖动用户无感也无从行动，提示了只添噪声；应该提示的是改变行动正确性的那几档：同步出现数秒以上滞后（「对方可能未看到最新」）、上行失败正在重试（「你的修改尚未送达」）、连接中断进入离线模式（「编辑保存在本地，恢复后同步」）。提示形态也有约束——它必须持续可查（状态栏常驻），因为降级的影响是持续性的，闪现一次的提示等于没说。另外告知只解决知情，不解决恢复；告知必须配上用户可行动的选项（重试、切换、转离线），否则只是把焦虑转正。
怎么落地
- 顶栏常驻连接状态（正常/迟缓/离线），降级发生时切换并说明影响：「同步延迟中，他人可能看不到你的最新修改」。
- 具体对象级的状态分层：每条消息标记送达状态，共享文档标记最后同步时间，把「我看到的有多旧」变成可查的事实。
- 离线切换给显式模式提示与行动入口（继续本地编辑/等待恢复），恢复时告知同步结果。
- 提示分级：决策相关的降级用持续可见的状态条，无感的抖动不打扰。
- 验证：弱网注入测试（限速、丢包、断续）走查每一档降级路径，检查是否都有对应的显式状态；对比降级期间的用户行为——重复发送率与误催促量在提示上线后应显著下降。