解决什么问题
学完 CBS 后，很容易把“更平滑”误解成“确定性已经完成”。整形确实能减少突发、保护一部分类别带宽，但它通常不回答“这帧必须在第几个微秒窗口发送”。
本节解决的是机制边界。CBS 更像节流阀，Qbv 更像时间表。两者都能改善抖动，但控制对象不同。
背景与直觉
如果把网络想成车流，整形是在入口控制车流速度，避免一下子涌入；Qbv 是给某些车安排特定绿灯窗口。入口限流能减少拥堵，但不能保证某辆车一定在某个绿灯通过所有路口。
这就是为什么很多 TSN 系统会组合机制。先用分类和整形让流量更可控，再用 Qbv 给最关键流量安排时间窗口。
怎么解决
判断是否需要 Qbv，可以看需求是否包含硬时间点和多跳接力。
| 需求类型 | 整形是否可能足够 | 为什么 |
|---|---|---|
| 降低音视频抖动 | 可能 | 平滑和带宽保护很有价值 |
| 限制某类流突发 | 可能 | CBS 正好处理发送节奏 |
| 500 us 内必须到达 | 不一定 | 需要最坏情况证明 |
| 多跳窗口接力 | 不够 | 需要共同时间和路径调度 |
| 故障下仍连续 | 不够 | 需要 FRER 和验证 |
所以整形不是低级机制，而是不同工具。它适合把输入流量变得更温和，但当业务要求精确窗口和严格 deadline 时，必须继续进入 Qbv、Qcc 和验证。
带来了什么新问题
整形会引入参数选择问题。带宽留太少，关键流自身会被限制；留太多，又可能挤压其他流。不同设备对 shaper 参数和队列行为的实现细节也可能影响结果。
同时，整形后的延迟边界仍然要证明。你不能只说“流量已经平滑”，还要说明在背景压力、最大帧长和多跳路径下，最坏延迟是否满足需求。
检查点
- CBS 和 Qbv 都能降低抖动，它们分别控制什么变量？
- 一个需求写着“每 1 ms 周期，deadline 200 us”，为什么通常不能只靠整形回答？