两块中控平板同时操作，怎样确认谁的场景最终生效

两台同权限平板的冲突需要一条服务端仲裁规则。可以使用独占租约，也可以使用带版本号的条件更新；不能靠两台平板各自的最后点击时间判断最终场景。

适用条件与证据边界

演示采用场景版本号：两台平板都从版本7出发，服务端串行接受第一条匹配版本的请求，并将版本升到8。实际项目若采用管理员优先或独占控制权，应替换规则后再测。

本文交付可执行的测试方法、合成演示和空白记录表；未连接现场硬件，未取得设备实测、现场照片或稳定性结论。规范定义与示例判据分别说明，示例数值不能用作设备参数。

按这个顺序核对

1. 先记录平板A、B看到的当前场景及版本，确认两者权限相同；权限拒绝与并发冲突应有不同提示。

2. 让A提交场景讲解、B提交场景闭馆，交换到达顺序各做一轮。以主机接收和提交时间为准，不用两台时钟直接相减。

3. 让落败平板刷新状态，检查它显示已生效场景和冲突原因；不得仍把自己的按钮显示为完成。

4. 再测试控制权持有人断网、租约到期、长任务执行中抢占。抢占必须定义正在运行任务是取消、排队还是拒绝。

输入与期望结果（合成演示）

到达次序	来源	携带版本	结果
1	A	7	接受并生成版本8
2	B	7	冲突；刷新后再决定
3	B	8	新操作可参与下一次仲裁

夹具的期望是A胜出、B收到冲突，最终版本为8。交换列表顺序后赢家应相应变化；如果合同规定固定角色优先，就不应使用本示例的先提交规则。

下载夹具并复用

下载本题JSON夹具与空白工作表。文件中的“演示输入”用于先核对判断逻辑，“现场空白记录”供复制后填写；原演示数据请保留，实测数据另存一份并标注型号、版本和采集时间。可先用 python -m json.tool fixture.json 检查结构，再按上表逐行核对输入与预期。

把控制权规则写进交付说明：操作区范围、持有者、取得时间、过期条件以及人工接管入口。大展厅可以按展区分开租约，但全局闭馆必须明确是否越过分区锁。测试日志要保留获胜和落败请求，单独保留成功日志无法解释另一台平板为何没生效。

容易误判的边界

“最后一次到达覆盖”不等于错误，但要避免前一个场景仍在执行、后一个已覆盖界面的混合状态。界面颜色一致也不能证明设备最终一致，最后还须回读设备。

继续核对

基础说明见展厅中控权限与多角色管理；还可核对中控按钮连点后场景执行两遍：怎样验收去重与幂等。相关资料可从中控场景可靠性专题继续查找；需要核对项目实现时，按SoftControl 设备联动需求列出具体接口与验收条件。

一级依据

• RFC 9110 §13.1.1：If-Match条件更新与丢失更新

核对日期：2026-10-23。引用版本用于界定本文方法，实际设备支持范围仍须与对应型号手册核对。本文的任务编号、仲裁、检查点与恢复判据属于应用设计建议，引用的网络或设备协议不自动提供这些保证。