因为 multipart/form-data 请求体由 boundary 分隔，r.Body 仅暴露原始字节流而不解析；必须调用 r.ParseMultipartForm 或 r.FormFile 才能提取字段和文件，否则读 r.Body 会得空、io.EOF 或乱码，r.FormValue 也返回空。
为什么 http.HandleFunc 里直接读 r.Body 会失败？
因为 multipart/form-data 请求体不是纯文本，而是由边界（boundary）分隔的多个部分，r.Body 只暴露原始字节流，不解析表单字段和文件。必须调用 r.ParseMultipartForm 或 r.FormFile 才能提取上传的文件。
常见错误现象：读 r.Body 得到空内容、io.EOF、或一堆乱码；r.FormValue 返回空字符串，即使前端明明传了字段。
r.ParseMultipartForm(32 必须在读取任何字段或文件前调用，参数是内存缓冲上限（如 32MB），超限会自动写入临时磁盘文件- 若只上传小文件且字段简单，可跳过
ParseMultipartForm，直接用r.FormFile("file")—— 它内部会触发一次轻量解析 - 不要重复调用
ParseMultipartForm，第二次会 panic：「multipart: Part already parsed」
如何安全地保存上传的 *multipart.FileHeader？
r.FormFile("file") 返回 multipart.File 和 *multipart.FileHeader，后者含文件名、大小、头信息，但 FileHeader.Filename 是客户端提供的，不可信，直接拼路径会导致路径遍历漏洞（如传 ../../etc/passwd）。
正确做法是丢弃原始文件名，生成服务端可控的唯一标识：
立即学习“go语言免费学习笔记（深入）”；
- 用
filepath.Base(fileHeader.Filename)截掉路径部分，再用strings.ReplaceAll清除非法字符（如/、\、..） - 更稳妥的是完全忽略原名，用
uuid.New().String()+filepath.Ext(fileHeader.Filename)构成新文件名 - 保存前务必检查
fileHeader.Size是否超出业务限制（如 10MB），避免 DoS 攻击 - 打开目标文件时使用
os.O_CREATE | os.O_WRONLY | os.O_TRUNC，并设置合理权限（如0644），避免 world-writable
上传大文件时为什么内存暴涨或超时？
默认 http.Server 没有读取超时和请求体大小限制，恶意用户可发超长请求体耗尽内存或阻塞连接。
必须显式配置服务端限制：
- 在
http.Server初始化时设置ReadTimeout和MaxHeaderBytes（如30 * time.Second、1 ） - 对上传接口单独加中间件，用
http.MaxBytesReader包裹r.Body，例如：http.MaxBytesReader(w, r, 50 限制总请求体不超过 50MB - 若需支持真正的大文件（>100MB），应考虑分片上传 + 后端合并，而非一次性读取整个
multipart.File - 注意：Nginx 等反向代理也有自己的
client_max_body_size，需与 Go 侧限制一致，否则请求在代理层就被拒
如何返回结构化错误而不暴露内部细节？
上传失败时，直接返回 http.Error(w, err.Error(), http.StatusBadRequest) 很危险 —— 错误信息可能包含文件系统路径、内部函数名等敏感内容。
应该做最小化、分类化的响应：
- 对
os.IsNotExist、os.IsPermission等系统错误，统一返回「上传目录不可写」，不透露具体路径 - 对
multipart.ErrMessageTooLarge，返回「文件超出大小限制」，而非原始错误字符串 - 建议用 JSON 返回，如：
json.NewEncoder(w).Encode(map[string]string{"error": "file too large"})，同时设w.Header().Set("Content-Type", "application/json") - 开发环境可额外记录完整错误日志，但生产环境响应体绝不包含
err.Error()
文件上传看着简单，但边界处理、安全校验、资源控制这三块最容易被跳过，一上线就出问题。别依赖框架自动兜底，每个环节都得自己盯住。
