直接用 http.FileServer 默认不缓存、不压缩、不 fallback、路径校验松散，易致404或性能低下；核心问题在于其隐式路径假设（如不自动补/、不查index.html）、相对路径风险、缺失Cache-Control与gzip、未防护目录遍历，且无SPA fallback机制。
直接用 http.FileServer 就能跑起来，但“高性能”不是默认配置出来的——它默认不缓存、不压缩、不 fallback、路径校验松散，稍不注意就变成慢服务器或安全缺口。
为什么直接 http.FileServer 会变慢甚至 404
核心问题不在性能本身，而在默认行为和路径处理的隐式假设：
-
http.FileServer不自动补尾部/：访问/assets（目录）返回 404，而/assets/才能进目录 - 不查
index.html：访问/或/docs/直接 404，除非你显式请求/index.html - 传相对路径如
"./public"：工作目录一变，http.Dir就指向错位置，首次请求就 404 - 没加
Cache-Control：浏览器每次重刷都重新拉 JS/CSS，带宽和延迟双浪费 - 没包
gzip.Handler：文本类资源（HTML/JS/CSS）未压缩传输，体积翻倍
必须用绝对路径 + http.StripPrefix 启动
这是避免部署时路径错位、403/404 突然出现的底线操作：
- 永远用
filepath.Abs("./public")构造目录路径，别信"./public"能跨环境工作 -
http.StripPrefix的前缀必须以/结尾："/static/"✅，"/static"❌（否则/static123也会被 strip） - 顺序不能反：先
StripPrefix，再交给FileServer；反过来调用ServeHTTP会绕过内置路径校验 - 权限要提前检查：确保 Go 进程对目标目录有读权限，Linux 下 SELinux 或用户组限制常静默导致 403
生产级性能和安全必须加的三层包装
原生 http.FileServer 是个裸 handler，你要自己套上缓存、压缩、路径防护这三层：
立即学习“go语言免费学习笔记（深入）”；
- 缓存头：用中间件包裹，对
.js、.css、.woff2等设Cache-Control: public, max-age=31536000；HTML 设no-cache - gzip 压缩：用
http gzip.Handler包整个 handler，但注意别 double-compress（比如 Nginx 已压时关掉它） - 路径防护：Go 1.16+ 推荐用
os.DirFS("./public")替代http.Dir，它默认拒绝../和 URL 编码绕过（如%2e%2e%2fetc%2fpasswd）
SPA 应用必须手动 fallback 到 index.html
React/Vue 打包后走 History 模式，刷新 /user/123 时后端必须返回 index.html，而不是 404：
- 别依赖
http.FileServer自动 fallback —— 它根本不做这事 - 正确做法：自定义
http.Handler，先尝试os.Stat检查文件是否存在；不存在且路径无扩展名（如/admin），就用http.ServeFile返回index.html - 注意 MIME：直接
os.ReadFile返回 HTML 会丢Content-Type，必须用http.ServeFile或手动w.Header().Set("Content-Type", "text/html; charset=utf-8") - 不要在
index.html里硬写绝对路径引用静态资源；确保r.Static("/static", "./dist/static")（Gin）或对应前缀挂载一致
最易被忽略的点是：路径规范化和缓存策略必须在启动时确定，不能靠运行时 guess；os.DirFS 的安全性只在 Go 1.16+ 生效，老版本仍需手动 filepath.Clean + 白名单校验。
