enablegzip=true未生效的三大原因：一是gzipminlength默认仅20字节，小响应不压缩；二是includedmethods默认仅get，post等需显式添加；三是必须同时满足enablegzip为true、响应长度≥阈值、请求方法匹配三条件。
EnableGzip = true 之后为什么没生效
常见现象是配置了 EnableGzip = true，但响应头里看不到 Content-Encoding: gzip，或用 curl -H "Accept-Encoding: gzip" 测试仍返回未压缩内容。
根本原因不是配置没读取，而是 Beego 的 Gzip 压缩有三个硬性前置条件，缺一不可：
-
EnableGzip必须为true（INI 中写成enablegzip = true，注意全小写） - 响应体原始长度必须 ≥
gzipminlength阈值（默认仅 20 字节，但实际常被忽略） - 请求方法必须在
includedmethods列表中（默认只含get，post不生效）
典型错误配置：enablegzip = true 单独开启，其余用默认值 → 小 HTML 模板（如 15 字节的 "OK"）或 POST 接口必然不压缩。
gzipminlength 和 includedmethods 怎么设才合理
这两个参数直接影响压缩覆盖率和兼容性，不能只看文档默认值。
gzipminlength 建议设为 256 或 1024：低于 256 字节的文本压缩后反而可能更大，且多数 API 响应、HTML 片段都超过这个长度；设太小（如 1）会徒增 CPU 开销。
includedmethods 若需对 API 响应压缩，必须显式加上 post，例如：includedmethods = get;post;head。注意分号分隔、无空格，大小写敏感（POST 无效）。
示例 INI 片段：
[prod] enablegzip = true gzipminlength = 1024 includedmethods = get;post;head
压缩级别 gzipCompressLevel 影响什么
gzipCompressLevel 控制 zlib 压缩时的 CPU/体积权衡，默认未设置时走 Go 标准库的 zlib.BestSpeed（即等级 1），而非最高压缩比（9）。
实测对比（10KB JSON 响应）：
- 等级 1：压缩耗时 ~0.02ms，输出 ~3.2KB
- 等级 6：压缩耗时 ~0.15ms，输出 ~2.8KB
- 等级 9：压缩耗时 ~0.8ms，输出 ~2.7KB
对 Web 服务而言，等级 6 是性价比拐点；等级 9 仅在带宽极端受限且 QPS 很低时考虑。Beego 不校验该值范围，填 10 会静默降级为 9，填负数则 panic。
EnableGzip 在 dev 模式下容易被忽略的副作用
开发阶段常开 runmode = dev，此时 EnableErrorsRender = true 默认开启错误页面渲染 —— 这些页面由模板生成，内容长度极小（常 gzipminlength = 256 也压不到。
更隐蔽的问题是：dev 模式下 Beego 会注入调试脚本、行号注释等非生产内容，导致响应体结构松散，压缩率显著下降。上线前务必在 prod 段验证 Gzip 行为，不能依赖 dev 环境测试结果。
另外，AutoRender = true 时模板输出走 Beego 内置流程，Gzip 生效；若手动 ctx.ResponseWriter.Write() 输出，需自行调用 gzip.Writer，Beego 不接管。
