解决什么问题
抢占经常被当成一个配置开关：打开以后，guard band 就能缩小。但工程上不能这样用。你必须证明链路两端真的协商成功，关键队列真的属于 express，普通队列真的可抢占，计数器和延迟表现也支持这个结论。
本节解决的是验证链路。没有验证，抢占预算只是纸面假设。
背景与直觉
想象你设计了一个更短的安全距离，因为你相信车辆都有自动刹车。如果实际某些车辆没有启用自动刹车，这个安全距离就不再安全。抢占也是同样逻辑：只有设备真实进入抢占工作模式，guard band 才能按片段级阻塞计算。
怎么解决
验证抢占至少分四步。
| 步骤 | 检查内容 | 证据 |
|---|---|---|
| 能力协商 | 链路两端是否都支持并启用 | 端口状态、日志 |
| 队列映射 | 哪些队列 express，哪些 preemptable | 配置快照 |
| 行为观测 | 是否出现片段、恢复和抢占计数 | 计数器、抓包 |
| 预算验证 | 最坏阻塞是否低于完整大帧 | 延迟统计 |
测试时要构造普通大帧持续发送，再让 express 关键帧在不同相位到达。对比抢占开启前后的最坏等待，才能说明 guard band 是否真的可以缩短。
带来了什么新问题
抢占验证很依赖设备可观测性。有的设备能提供清晰计数器，有的只能看到端口状态；有的抓包点看不到片段细节；有的实现对队列组合有限制。这些差异会影响你能留下多强的证据。
此外，抢占可能和 Qbv、CBS 组合使用。组合机制下，单独验证抢占还不够，还要证明它在调度窗口、背景压力和实际队列映射下仍然工作。
检查点
- 如果配置里启用了抢占，但端口协商失败，Qbv guard band 预算会怎样变化？
- 你会用哪些证据证明 express 帧没有等待完整普通大帧？