http.FileServer 默认不处理路径末尾斜杠导致404，且未清理路径易引发目录遍历；需配合http.StripPrefix（带尾部斜杠）、显式fallback至index.html、安全使用embed.FS并自定义响应头。
为什么直接用 http.FileServer 会返回 404 或目录遍历失败
默认的 http.FileServer 不自动处理路径末尾斜杠，比如访问 /static（没加 /）时，它不会重定向到 /static/，而是直接查文件 static —— 这当然不存在，于是 404。更危险的是，若未做路径清理，攻击者可能用 ../../../etc/passwd 绕过根目录限制。
- 必须用
http.StripPrefix配合，且前缀要带结尾斜杠（如/static/），否则路径拼接错乱 -
http.FileServer内部调用Dir.Open前会做filepath.Clean，但前提是传入的路径是相对合法的；若 handler 路由本身没截断好，clean 也救不了 - 开发时建议加一层中间件检查请求路径是否含
..，哪怕只是strings.Contains(r.URL.Path, "..")快速拦截
如何让 http.FileServer 支持 SPA 的 fallback 路由（如 React/Vue）
单页应用需要所有非静态资源请求都 fallback 到 index.html，但 http.FileServer 本身不支持 fallback。不能靠它自己解决，得在它前面加一层判断逻辑。
- 先尝试用
fs.Stat检查文件是否存在，存在就交给http.FileServer；不存在且路径不带扩展名（如/dashboard），才返回index.html - 注意：
http.FileServer对index.html的服务是隐式触发的（当请求目录时），但 fallback 场景下你要显式读取并写回响应体，别忘了设Content-Type: text/html; charset=utf-8 - 别用
http.ServeFile直接返回index.html—— 它会强制设置Content-Disposition，破坏 SPA 的正常渲染
http.FileServer 的 fs.FS 参数怎么安全替换为嵌入文件系统（Go 1.16+）
用 embed.FS 替代传统磁盘目录，能打包静态资源进二进制，但容易忽略两件事：路径前缀和文件权限模拟。
-
embed.FS的路径是相对于 embed 声明位置的，而http.FileServer期望路径以/开头；所以要用fs.Sub(embedFS, "ui/dist")提前切出子树，再传给http.FileServer -
fs.FS实现不提供文件模式信息，http.FileServer默认把所有文件当成0644；如果原资源有可执行脚本（如.sh），浏览器下载时可能被拒绝执行 —— 这不是 bug，是设计使然，别指望它还原 chmod - 调试时可用
fs.Glob打印所有嵌入路径，确认index.html确实在根下，否则http.FileServer找不到入口
自定义 http.FileServer 的响应头（如缓存、CORS）有哪些可靠方式
不能直接改 http.FileServer 返回的 ResponseWriter，它内部已写 header；必须用包装器或中间件提前干预。
立即学习“go语言免费学习笔记（深入）”；
- 最稳的方式是写一个
http.Handler包装器，在调用fileServer.ServeHTTP前修改ResponseWriter，比如用responsewriter.Wrap（第三方）或自己实现Header()方法代理 - 对静态资源设
Cache-Control: public, max-age=31536000是常规操作，但注意：HTML 文件应设短缓存（如max-age=0），否则 HTML 更新后用户仍看到旧版 - CORS 头（如
Access-Control-Allow-Origin）只应在明确需要跨域时加；加在所有静态资源上可能暴露敏感路径结构，尤其当目录列表开启时
真正难的不是让文件跑起来，而是搞清每个路径段谁在解析、谁在清理、谁在拼接 —— http.FileServer 表面简单，背后三处路径处理（路由匹配、StripPrefix、Dir.Open）稍有错位就 404 或越权。上线前务必用 curl -v 测一遍带点号、双斜杠、URL 编码的路径。
