servefile 不能直接用作 http 处理器，因为它不是 http.handlerfunc 类型，不接收 http.responsewriter 和 *http.request 参数，而是自行调用 writeheader 和 write；直接使用会导致编译失败。
ServeFile 为什么不能直接用作 HTTP 处理器
ServeFile 是一个函数，不是 http.HandlerFunc，它不接收 http.ResponseWriter 和 *http.Request 参数，而是自己内部调用 WriteHeader 和 Write。直接写 http.HandleFunc("/file", http.ServeFile) 会编译失败——类型不匹配。
正确包装 ServeFile 的两种方式
必须手动实现处理器逻辑，把请求路径映射到具体文件路径。常见错误是硬编码路径或忽略 URL 解码，导致 404 或 403。
- 用
http.ServeFile+ 匿名函数：适合固定文件，例如http.HandleFunc("/logo.png", func(w http.ResponseWriter, r *http.Request) { http.ServeFile(w, r, "./static/logo.png") }) - 用
http.FileServer+http.StripPrefix：更灵活，支持子路径映射，例如fs := http.FileServer(http.Dir("./static")); http.Handle("/static/", http.StripPrefix("/static/", fs))
注意：ServeFile 不会自动处理 index.html，也不支持目录列表；传入的文件路径必须是绝对路径或相对于当前工作目录的相对路径，且需确保进程有读取权限。
路径安全问题：别让 ../ 突破根目录
如果用户构造请求如 GET /file?path=../etc/passwd 并拼接到 ServeFile，可能造成任意文件读取。Go 标准库的 ServeFile 本身不做路径净化，需自行防御。
- 永远不要直接使用
r.URL.Query().Get("path")拼接文件路径 - 用
filepath.Clean()规范化路径，再检查是否在允许根目录内，例如：root := "/var/www/files"<br>path := filepath.Clean(filepath.Join(root, r.URL.Path))<br>if !strings.HasPrefix(path, root) {<br> http.Error(w, "Forbidden", http.StatusForbidden)<br> return<br>} - 更稳妥的做法是白名单校验文件名（如只允许
report.pdf、data.json）
Content-Type 和缓存头不会自动设置
ServeFile 会根据扩展名调用 mime.TypeByExtension 设置 Content-Type，但若文件无扩展名或扩展名未注册，会 fallback 到 application/octet-stream。同时它不设置 Cache-Control 或 ETag，客户端每次都会重新请求。
- 如需自定义 MIME 类型，先调用
w.Header().Set("Content-Type", "...")，再调用ServeFile（注意顺序，header 必须在 write 前设置） - 若要启用强缓存，可加：
w.Header().Set("Cache-Control", "public, max-age=3600") - 对小文件（os.ReadFile +
w.Write替代ServeFile，避免多次系统调用和锁竞争
真正麻烦的从来不是怎么发一个文件，而是怎么确保它只发该发的那个、发得安全、发得高效。
