为什么验证要单独成章
TSN 的学习如果停在“会配置”，会留下一个很大的空洞：你不知道配置是否真的成立。管理界面显示 Qbv 已启用，不代表关键帧按窗口通过；某次控制消息准时到达，不代表高负载下仍然准时；FRER 副本都到了，不代表断链后仍然满足 deadline。
确定性网络的关键词不是“看起来更稳”，而是“边界可解释、可测量、可复现”。验证成章的原因就在这里：它把前面所有机制转成证据链。共同时间要有同步状态证据，Qbv 要有窗口命中证据，抢占要有最坏阻塞证据，Qcc 要有配置一致性证据，FRER 要有故障连续性证据。
本章小节怎么读
先读可观测性计划、最坏情况指标和时间同步证据，建立验证的基本证据链：测试输入、测量方法和统计指标都要能支撑边界结论。
再读故障注入设计和调试手册，学习当 Qbv、Qcc、FRER 出现迟到、丢包、重复或配置漂移时，如何按证据链收敛。
最后读可复现报告和论文阅读入口。工程报告训练的是证据意识，这套方法可以继续迁移到论文里的模型、baseline、实验和结论边界判断。
证据链而不是截图
一份 TSN 验证报告至少要回答四类问题。
| 问题 | 证据例子 | 缺失后的风险 |
|---|---|---|
| 输入是什么 | 拓扑、设备版本、流量模型、配置快照 | 无法复现测试条件 |
| 网络做了什么 | GCL、队列映射、同步状态、FRER 状态 | 不知道机制是否生效 |
| 结果是什么 | 抓包时间戳、延迟分布、丢包、重复消除统计 | 只剩口头结论 |
| 边界在哪里 | 背景压力、故障注入、样本数量、测量精度 | 结论被过度推广 |
本章的核心结论
TSN 的完整学习闭环是：理解问题，选择机制，配置路径，测量结果，解释误差，留下证据，再进入更复杂的模型和研究。没有验证意识，前面的所有协议都容易停留在概念层；有了验证意识，你才能判断一篇论文、一个产品白皮书或一个设备 demo 到底证明了多少。
检查点
- 为什么“ping 通”和“关键流满足 500 us deadline”不是同一种证据？
- 一份只给平均延迟的报告，缺少哪些对 TSN 更关键的信息？
- 如果要证明 FRER 在单链路故障下仍然成立，你至少要记录哪些输入、故障动作和结果？