QPACK 用共享的表项压缩 HTTP 字段。字段段留在请求或响应所在的流里，动态表的更新则走独立的编码器流。这样做避免了照搬 HTTP/2 字段压缩对到达顺序的假设，却没有消除所有数据依赖。

设想编码器先插入一个新字段值，再让请求 A 的 HEADERS 引用它。如果 HEADERS 先到、表项更新后到，A 的字节虽然已经收齐，解码器仍需要等待。另一个只使用静态表或字面值、没有这个依赖的请求 B，则不需要等同一项更新。

RFC 用 Required Insert Count（所需插入计数）描述解码所需的表状态，并用 SETTINGS_QPACK_BLOCKED_STREAMS 限制可能被阻塞的流数量。把这个限制设为零，不等于完全不能用动态表：编码器仍可引用已经确认到达、不会造成这种等待的表项。

这里真正的取舍是压缩率与等待风险。尽早引用新表项，字段可能更短，但存在等更新的风险；保守地使用已确认表项或字面值，可以减少这种等待，却可能增加发送字节。观察到延迟时，需要把字段大小、表更新到达时间和连接发送额度放在一起看。