配置边缘压缩，关键不是把 Brotli 排在 Gzip 前面，而是读懂客户端发来的协商信息。边缘节点压缩配置如何兼顾Brotli与Gzip兼容，取决于它是否按可接受编码、质量因子和实际支持情况作选择；不能只看请求头中编码名称的排列顺序。
先读协商字段，再决定返回编码
客户端通常通过 Accept-Encoding 声明能接收的压缩格式，例如 br、gzip，也可以为每种格式给出 q 值。q 值范围是 0 到 1，默认值为 1；q=0 表示不接受。若 br 的 q 值高于 gzip，且边缘节点能提供 Brotli，就优先选择 Brotli；若 gzip 得分更高，则返回 Gzip。
当两种编码的 q 值相同，标准并未要求所有服务器都把字段中的先后顺序当作偏好。边缘产品可能采用自身的平局策略，因此应确认其配置说明：可以设置 Brotli 优先，也可以按请求中的排列顺序打破平局。不要把“客户端先写 br”误当成跨产品通用规则。
按可执行顺序配置与验证
- 启用两种编码。在边缘服务的压缩设置中开启 Brotli 与 Gzip，并确认所选套餐、节点类型或运行环境支持相应功能；控制台选项名称会因产品而异。
- 设定协商规则。优先依据 q 值筛选可接受编码；q 值相同时，明确配置平局优先级。未声明 Accept-Encoding 时通常可按节点策略处理；若客户端明确拒绝所有压缩，则应返回未压缩内容。
- 限制压缩对象。优先处理文本类响应，例如 SVG、纯文本和常见网页资源。JPEG、WebP、MP4、ZIP 等通常已经压缩，再次压缩往往收益有限，还可能增加处理开销。动态压缩可设最小响应大小，具体阈值按资源类型、延迟预算和节点负载测试，不宜套用一个固定值。
- 正确区分缓存版本。同一资源可能有 Brotli、Gzip 和未压缩版本，响应应带对应的 Content-Encoding，并通过 Vary: Accept-Encoding 告知缓存按编码能力区分变体。检查边缘缓存键及回源规则，避免把一种编码的响应交给不支持它的客户端。
- 逐种请求验证。分别发送 Accept-Encoding: br、Accept-Encoding: gzip，以及同时列出两者并设置不同 q 值的请求；再测试 q=0、未发送该字段和明确拒绝压缩的情况。核对响应状态、Content-Encoding、缓存变体，并确认正文确实能由相应客户端解码。
静态文件与动态响应要分开考虑
对发布流程可控、内容稳定的静态资源，可提前生成 Brotli 和 Gzip 文件，边缘节点按协商结果选取，减少请求时的压缩计算。动态页面或接口响应则通常由节点实时压缩，需权衡压缩等级、CPU 占用与响应延迟。高压缩等级通常更耗计算，是否值得使用应结合文件大小和访问负载评估，而非只比较压缩率。
如果源站已经压缩，边缘节点还应避免重复压缩；若回源和客户端协商结果不同，则需确认边缘服务是否能正确解压、重新压缩或直接透传。做好这些检查，边缘节点压缩配置如何兼顾Brotli与Gzip兼容就有了清晰路径：尊重客户端可接受范围，以 q 值为主要依据，为平局设定明确规则，并保留安全回退。
常见问题
客户端只接受 Gzip，边缘节点会返回 Brotli 吗？
不应返回。节点应从客户端可接受且自身可提供的编码中选择；如果没有共同编码，就返回未压缩内容，或按服务策略处理。
Accept-Encoding 写了 br, gzip，是否一定优先 Brotli？
不一定。若两者 q 值相同，排列顺序是否作为平局依据取决于边缘产品实现；应查明其规则并通过请求验证。
启用两种编码后还需要检查缓存吗？
需要。确认响应包含正确的 Content-Encoding，并让缓存区分不同编码变体；否则可能出现客户端收到不兼容内容的情况。
