http.FileServer 直接暴露根目录会导致路径遍历漏洞，如访问 /..%2f/etc/passwd 可读取系统文件；正确做法是限定真实子目录、配合 StripPrefix，并优先使用 embed 内嵌资源。

为什么 http.FileServer 直接暴露根目录会出问题

直接用 http.FileServer(http.Dir("/var/www")) 启动服务，浏览器访问 /..%2f/etc/passwd 可能读到系统文件——这是典型的路径遍历漏洞。Go 的 http.FileServer 默认不做路径规范化校验，http.Dir 仅做基础映射，不拦截恶意编码路径。

正确做法是用 http.StripPrefix 配合显式限定子路径，并确保底层目录无向上跳转能力：

fs := http.FileServer(http.Dir("./static"))
http.Handle("/static/", http.StripPrefix("/static/", fs))

• ./static 必须是相对或绝对的**真实物理子目录**，不能是 ../assets 这类含 .. 的路径
• StripPrefix 要和注册路由前缀严格一致（比如注册了 /static/，就不能写成 /static 或 /static/ 少斜杠）
• 若需支持 SPA 的 history 模式，不能只靠 FileServer，得在最后兜底路由里返回 index.html

开发期用 embed 内嵌静态资源更安全可靠

Go 1.16+ 的 embed 把静态文件编译进二进制，彻底规避路径遍历、权限、部署路径错位等问题，适合中小型 Web 应用。

使用时注意三点：

立即学习“go语言免费学习笔记（深入）”；

• 必须用 //go:embed 注释声明，且路径是相对于当前 .go 文件的（不是工作目录）
• embed.FS 不支持写操作，也不支持通配符递归（**），需显式列出或分层嵌入
• 配合 http.FileServer 时，要用 http.FS 包装，而非直接传 embed.FS

import _ "embed"

//go:embed static/*
var staticFS embed.FS
func main() {
fs := http.FileServer(http.FS(staticFS))
http.Handle("/static/", http.StripPrefix("/static/", fs))
}

net/http 默认不压缩，前端资源体积大怎么办

Go 标准库的 http.FileServer 不做 Gzip/Brotli 压缩，JS/CSS 文件全量传输会拖慢首屏。别自己实现压缩逻辑——容易出缓存头错误或并发 bug。

推荐两个轻量方案：

• 构建时预压缩：用 zopfli 或 gzip -k 生成 .js.gz 和 .css.br，再用第三方中间件如 github.com/gorilla/handlers.CompressHandler 自动选最优编码
• 反向代理前压：Nginx / Caddy 配置 gzip on，让静态资源走 CDN 或边缘节点压缩，Go 服务只管内容交付

如果坚持纯 Go 实现，务必检查 Content-Encoding、Vary: Accept-Encoding 和 ETag 是否同步更新，否则缓存可能错乱。

生产环境绕过 Go 直接托管静态资源的现实理由

HTTP 服务器（Nginx / Caddy）处理静态文件的性能远超 Go：sendfile 系统调用零拷贝、内核级缓存、连接复用、HTTP/2 Server Push 支持都更成熟。

典型部署结构是：

• Nginx 监听 80/443，location /static/ 指向磁盘路径，加 expires 1y 和 add_header Cache-Control
• 所有非静态请求（/api/、/auth/）用 proxy_pass http://localhost:8080 转给 Go 服务
• Go 里完全去掉 FileServer，避免误配导致敏感路径泄露

真正需要 Go 托管静态资源的场景其实很少：CLI 工具附带 Web UI、离线应用、或 POC 阶段快速验证。一旦进入生产，该交出去的就得交出去。