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"
<p>//go:embed static/*
var staticFS embed.FS</p><p>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 阶段快速验证。一旦进入生产，该交出去的就得交出去。
