预压缩静态文件应统一使用 gzip.newwriterlevel(f, gzip.bestcompression)，显式调用 defer gz.close()，并验证 .gz 文件完整性与 http 响应正确性。
gzip.NewWriterLevel 用于预压缩静态文件时必须指定压缩级别
预压缩不是“用默认值就行”，gzip.NewWriter 默认用 gzip.DefaultCompression（值为 6），但静态资源如 .js、.css 多为已高度结构化文本，gzip.BestCompression（9）能进一步压掉 5–10% 体积，而 CPU 成本只在构建期发生一次，值得投入。
常见错误是直接用 gzip.NewWriter(f) 而不设 level，结果压缩率偏低；更糟的是传入非法值（如 -1 或 10），会 panic，不是返回 error。
-
gzip.NoCompression（0）仅加 header，适合已压缩的二进制（如图片），对文本无效 -
gzip.BestSpeed（1）压缩快但体积大，预压缩场景下无意义 - 推荐统一用
gzip.NewWriterLevel(f, gzip.BestCompression)，并包裹在defer gz.Close()前显式调用
预压缩必须确保 .gz 文件与原始文件同名且共存
Web 服务器（如 http.FileServer）本身不会自动查找或生成 .gz 文件，它只响应请求路径。要让客户端拿到压缩版，得提前生成 main.js.gz 和 main.js 并放在同一目录——否则即使客户端发了 Accept-Encoding: gzip，服务端也无源可压。
别指望中间件动态 fallback：预压缩是离线行为，和运行时 gzip.Handler 完全无关。两者不能混用，否则容易出现 Content-Encoding: gzip 但 body 是明文的静默失败。
- 路径必须严格匹配：
/static/app.js请求对应磁盘上static/app.js和static/app.js.gz - 生成
.gz后记得os.Chmod保证读权限，尤其在 CI/CD 环境中容易因 umask 导致 403 - 不要用
filepath.Walk遍历后直接gzip.NewWriter写同名文件——需先检查目标是否已存在，避免覆盖正在被服务的文件
http.ServeFile 不识别 .gz，必须用自定义 FileServer 包装逻辑
http.ServeFile 和默认 http.FileServer 都不感知 .gz 文件，也不会根据 Accept-Encoding 自动选文件。想实现“有 .gz 就发它，没就发原文件”，得自己写一个包装器，核心是重写 http.FileSystem.Open 方法。
关键点不是“加个 if 判断”，而是要复用 Go 标准库的 http.Dir 行为，并在 Open 时优先尝试 name + ".gz"，同时正确设置 Content-Encoding: gzip 和 Content-Type（后者必须从原始文件推断，不能硬编码）。
- 不能只改
Content-Encoding头——若返回app.js.gz却设Content-Type: application/javascript，浏览器才能执行；设成application/gzip就下载了 - 必须调
stat.Size()获取.gz文件长度，填入Content-Length，否则gzip.Handler会跳过压缩（因它依赖长度判断是否值得压） - 别在 handler 里用
io.Copy手动读.gz文件——这绕过了标准http.ServeContent的 range 支持，导致视频/大文件分片失效
预压缩后必须验证解压完整性，不能只看文件大小
生成 .js.gz 后，ls -lh 看体积变小 ≠ 压缩成功。很多脚本漏调 gz.Close()，导致文件末尾缺 CRC32 和 ISIZE，gunzip -t 直接报 unexpected end of file，但浏览器可能静默降级回明文，掩盖问题。
真正验证要两步：一是用 gzip.NewReader 解开并比对原始内容；二是用真实 curl 测试 HTTP 响应头与 body 是否匹配。
- 验证命令：
gunzip -c main.js.gz | sha256sum对比原始main.js的 hash - HTTP 验证：
curl -H "Accept-Encoding: gzip" -I http://localhost/static/main.js确认返回Content-Encoding: gzip且Content-Length是 .gz 文件大小 - 最易忽略的坑：预压缩脚本里用了
defer gz.Close()，但后续还有return或 panic，导致Close()没执行——必须把gz.Close()放在所有可能出口之前
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
