Revel框架CompressFilter默认不生效，需同时配置results.compressed=true和results.compression.filter=true，并确保响应MIME类型在白名单内、状态码非204/304、客户端请求头含Accept-Encoding: gzip。
Revel 框架默认开启的 CompressFilter 能直接生效，但前提是响应 MIME 类型在白名单内、状态码非 204/304、且客户端请求头带 Accept-Encoding: gzip——多数情况下它“看似启用却没压缩”，问题往往出在这三处。
确认 compress.go 是否真正介入响应链
Revel 的压缩逻辑由 compress.go 中的 CompressFilter 实现，但它只在过滤器链中被显式注册后才起作用。仅设置 results.compressed = true 不足以激活它。
-
conf/app.conf中必须同时配置：results.compressed = true且results.compression.filter = true - 若使用自定义
app.Init()，需确保调用revel.InterceptMethod(app.Compress, revel.BEFORE)或等效注册 - 检查日志输出是否含
CompressFilter installed；没有则说明过滤器未加载
为什么 CSS/JS 响应头没出现 Content-Encoding: gzip
即使压缩功能启用，常见原因不是算法失效，而是 MIME 类型未匹配或响应被跳过。
-
compressableMimes默认不含application/wasm或font/woff2，这些不会压缩——这是预期行为，不是 bug - 前端构建输出的
.css文件若被http.FileServer直接服务（而非经 Revel router），会绕过CompressFilter，此时需改用revel.Static或手动包装 handler - 浏览器 DevTools 的 Network 面板中，筛选
text/css类型响应，逐个查看Response Headers；若Content-Encoding缺失但Content-Length明显变小，可能是服务端用了预压缩（如 Nginx 的gzip_static on）覆盖了 Revel 行为
gzip vs 预压缩：别让两种压缩同时生效
Go 服务层动态压缩 + 反向代理（如 Nginx）再压一次，不仅浪费 CPU，还可能因两次压缩导致浏览器解压失败或体积不降反升。
立即学习“go语言免费学习笔记（深入）”；
- Nginx 开启
gzip on时，务必关闭 Revel 的results.compressed，反之亦然 - 更推荐预压缩：用
compression-webpack-plugin构建时生成app.js.gz和style.css.gz，再配 Nginx 的gzip_static on，完全规避运行时开销 - 若坚持 Go 层压缩，禁用对已压缩文件的二次处理：在
compress.go的shouldCompress函数里加判断，跳过filepath.Ext(path) == ".gz"的请求路径
最容易被忽略的是静态资源的服务路径——用 http.FileServer 直接暴露 dist/ 目录时，Revel 的所有 filter（包括压缩、ETag、Cache-Control）全部失效；必须通过 Revel 的路由机制（如 GET /public/*filepath）接管，才能让压缩逻辑真正落地。
