字段引用与表更新分开发送
HTTP/3的不同QUIC流不保证按统一顺序到达，若一个请求直接引用尚未收到的表状态，解码就必须等待。QPACK沿用静态表和动态表，却通过专门的编码器流发送插入、容量等指令，让字段区本身只引用相应状态。
解码器流反向传送确认、取消及插入计数等反馈，帮助编码端知道哪些引用已经可安全使用或释放。每个端点具有自己的编码与解码职责；这些流是连接状态协调的一部分，不是额外的HTTP业务请求。
参考：[1]
必要插入计数决定是否能解码
字段区携带Required Insert Count，说明解码需要动态表已完成多少次插入。若解码器现有计数尚未达到它，相关流就暂时阻塞；不引用动态表的字段区，其必要计数为零，不因这项依赖等待。
接收端用设置限制可能阻塞的流数量，发送端不能任意引用大量仍在途的表项。发送端可只引用已确认可用的项目来降低风险，也可在允许预算内冒一定等待风险以提高压缩率；QPACK因此不是“保证从不阻塞”的压缩方法。
参考：[1]
容量、引用存活与流量控制
动态表容量也受解码端限制，但不能只按“最旧的就删”处理：插入尚未确认，或仍受未完成引用约束的项目，可能不能淘汰。编码器需要跟踪未完成字段区的引用，直到确认或取消使相应项目可以安全释放。
表更新流本身还受QUIC流量控制。若请求等待表更新，表更新又等待请求消费后才有的额度，便可能死锁；规范据此要求发送策略考虑完整指令所需的流与连接额度。压缩状态、等待预算和传输资源必须一起设计。
参考：[1]