解决什么问题
TSN 失败时，现象可能是迟到、丢包、重复交付、窗口 miss、配置不一致或测量数据异常。如果没有排查顺序，很容易反复改配置，把现场证据覆盖掉。
本节解决调试方法问题：按证据链收敛，而不是靠猜。
背景与直觉
复杂系统调试像破案。先保护现场，再收集证据，再排除假象，最后定位根因。TSN 的“现场”包括配置、抓包、计数器、时间同步状态和流量输入。
怎么解决
推荐排查顺序如下。
| 顺序 | 问题 |
|---|---|
| 1 | 需求和 flow set 是否正确 |
| 2 | 时间同步和时间戳是否可信 |
| 3 | 队列映射和入口约束是否正确 |
| 4 | Qbv/CBS/抢占配置是否应用 |
| 5 | Qcc 目标状态和设备状态是否一致 |
| 6 | FRER 序列、重复消除和路径状态是否正常 |
| 7 | 背景流量和故障动作是否符合测试计划 |
| 8 | 统计脚本和测量误差是否引入假象 |
每一步都尽量保存证据，再做改动。改动后记录版本，避免新旧状态混在一起。
带来了什么新问题
严格排查会比“先改一下试试”慢，但它能减少来回试错。尤其是跨团队问题，只有可复盘记录才能让设备、网络、应用和测试人员讨论同一个事实。
调试手册还应随项目更新。新增机制、新增设备、新增测试工具，都可能改变排查顺序和证据类型。
检查点
- 为什么 TSN 失败时第一步不一定是改 GCL？
- 如果怀疑测量数据异常，你会检查哪些时间戳和统计环节？