应于ParseMultipartForm前用io.TeeReader将r.Body复制到bytes.Buffer，否则解析后r.Body不可再读；直接读取会导致空内容或“invalid Read on closed Body”错误。
上传文件后如何可靠获取原始字节流
Go 的 http.Request 默认会把 multipart/form-data 中的文件字段解析为临时文件或内存缓冲，但一旦调用 r.ParseMultipartForm() 或访问 r.MultipartForm，底层 Request.Body 就被消费掉——后续再想读原始流会得到空内容或 http: invalid Read on closed Body 错误。
正确做法是：在解析表单前，先用 io.TeeReader 或显式复制 Body 到内存/临时文件，再交给 ParseMultipartForm 处理。否则解析完就无法做内容校验、哈希计算或流式解析。
- 若文件较小（bytes.Buffer 缓存原始 Body，再用
multipart.NewReader手动解析，避免自动解析污染 Body - 若需支持大文件，用
os.CreateTemp创建临时文件，用io.Copy把 Body 写入，再用os.Open重复读取 - 切勿在
r.ParseMultipartForm(32 后还试图 <code>io.ReadAll(r.Body)
解析 PDF/DOCX/CSV 时怎么选对库和打开方式
不同格式的解析逻辑差异极大，硬套统一接口容易崩溃。PDF 需要处理分页、字体嵌入、加密；DOCX 是 ZIP 包裹的 XML，得解压后读 word/document.xml；CSV 表面简单，但实际常含 BOM、换行符嵌套、非 UTF-8 编码。
推荐组合：
立即学习“go语言免费学习笔记（深入）”；
- PDF：用
unidoc/unipdf/v3（商用需授权）或开源替代pdfcpu（命令行友好，Go 调用需exec.Command）；避免github.com/jung-kurt/gofpdf——它只生成不解析 - DOCX：用
github.com/89z/mech或更轻量的github.com/otiai10/gosseract（OCR 场景）；纯文本提取优先走github.com/psmithy/docx，它直接解压并解析 XML，不依赖外部二进制 - CSV：用标准库
encoding/csv，但必须先检测 BOM：bytes.HasPrefix(data, []byte{0xEF, 0xBB, 0xBF})，然后截断并转 UTF-8；字段含换行时，确保csv.Reader.FieldsPerRecord = -1
为什么用 goroutine 并发解析反而变慢甚至 panic
常见误区是“上传完立刻起 goroutine 解析”，结果在高并发下 OOM 或文件句柄耗尽。根本原因不是 Go 并发模型不行，而是没控制资源边界。
真实瓶颈往往在磁盘 I/O（临时文件读写）、CPU（PDF 文字提取）、或第三方库的非线程安全调用（如某些 Cgo 封装的 OCR 库）。
- 限制并发数：用带缓冲的 channel 做工作队列，例如
sem := make(chan struct{}, 5)，每次解析前sem ，结束后 <code><-sem - 避免共享文件句柄：每个 goroutine 必须独立
os.Open临时文件，不要传 *os.File 指针跨 goroutine - 注意
runtime.GOMAXPROCS默认是 CPU 核心数，但 IO 密集型任务设太高反而增加调度开销；保持默认即可，靠 channel 控制实际并发度
解析失败时怎么保留上下文并定位问题
用户传了个损坏的 DOCX 或密码保护的 PDF，如果只返回 “parse failed”，前端没法重试，运维没法查因。必须把原始错误链、文件元信息、甚至前 1KB 二进制快照一起记录。
- 用
fmt.Errorf("parse docx %s: %w", filename, err)包装原始错误，保留栈信息 - 记录
Content-Type、Content-Length、filepath.Ext(filename)，比单纯看扩展名更可靠 - 对前 128 字节做 hex dump：
fmt.Sprintf("%x", data[:min(len(data), 128)])，能快速识别是否真为 ZIP（PK\x03\x04）或 PDF（%PDF-） - 不要吞掉
io.ErrUnexpectedEOF或zip.ErrFormat这类关键错误，它们直接指向文件完整性问题
真正麻烦的永远不是解析逻辑本身，而是你没看到的那部分：上传时客户端悄悄截断了请求体，Nginx 限了 body size，或者 Windows 用户双击压缩包拖进浏览器导致 MIME 类型错报为 application/x-zip-compressed。留好日志字段，比加十个重试逻辑都管用。
