Brotli补丁对解压性能有何影响?

安全补丁上线后，解压吞吐的细微变化往往比漏洞本身更早被业务侧感知。Brotli 解码器的越界写入修复属于内存安全类改动，这类补丁的性能代价并不固定，关键取决于校验逻辑被放在了解码路径的哪一层。

补丁位置决定开销量级

Brotli 解码是 CPU 密集型过程，上下文建模与静态字典查找使其单位数据的算力消耗高于 gzip。正因如此，任何插入热循环的逻辑都更容易被放大。若边界检查落在每次位流读取处，每个压缩块都要承担额外分支判断，稳态吞吐可能被拖低；若校验被安排在流初始化、块边界或字典加载阶段，则属于一次性成本，对持续解压的影响有限。

这也解释了为什么不能笼统断言打补丁必然掉性能。同一漏洞在不同发行版和语言运行时中的修复实现可能不同，实际开销随之分化。对多数业务而言，真正需要警惕的不是平均耗时的小幅波动，而是解码路径上新增的重复校验或状态维护是否随并发量线性叠加。

用验证清单捕捉退化

原文的平滑更新验证清单提供了可操作的观察面：回归测试标准压缩流、向解码函数输入截断或损坏数据、监控各语言 Worker 进程的 RSS 波动。最后一项尤其值得重视——补丁若引入额外状态缓存或校验结构，内存驻留集的变化往往比吞吐指标更早暴露异常。同时应确认异常数据触发的是常规解析错误（如 Z_DATA_ERROR），而非段错误或进程退出码 139，后者说明修复并未真正生效。

把性能退化纳入回滚判断

原文的回滚预案把吞吐量骤降与跨平台 ABI 兼容性并列为触发条件，并给出在网关流量阻断维持开启的前提下快速执行 rollout undo 的路径。这实际上承认了一个现实：安全补丁的性能影响有时需要与稳定性权衡，而不是默认接受。

判断补丁是否值得保留，不应只看单次解压耗时。更可靠的信号是延迟分位数的变化、RSS 趋势以及 libbrotli 加载进程的异常崩溃重启事件。若这些指标在升级后同步恶化，回滚比继续观察更稳妥；若仅平均耗时轻微上升而分位数稳定，则更可能是测量噪声而非补丁本身的代价。