必须手动解析 multipart 数据流并用带计数的 wrapper 实时统计进度，避免 parsemultipartform 全量加载；websocket 连接需与上传请求绑定唯一 id 并校验活跃性；进度上报须节流防阻塞，且大文件上传需设上下文超时与内存限制。
用 http.HandlerFunc 处理上传 + io.MultiWriter 实时计数
go 标准库本身不提供上传进度回调，得自己拆包解析 multipart 数据流。核心思路是：不等整个 req.ParseMultipartForm() 完成（它会把全部文件读进内存或临时磁盘），而是用 req.MultipartReader() 拿到原始 reader，再套一层带计数的 wrapper。
常见错误是直接调 r.FormFile("file") —— 这会触发完整解析，进度完全不可见；或者用 io.copy 直接写目标文件，但漏掉统计逻辑。
- 用
mime/multipart手动解析，对每个*multipart.Part检查Header.Get("Content-Disposition")是否含filename= - 创建自定义
io.Reader包裹原始 part body，每次Read(p []byte)时累加已读字节数，并通过 channel 或闭包变量通知 WebSocket - 别在 HTTP handler 里直接发 WebSocket 消息 —— 网络延迟可能拖慢上传，应把进度数据推给独立 goroutine 处理
WebSocket 连接生命周期必须和上传请求绑定
很多人开个全局 map 存 *websocket.Conn，然后靠 URL 参数或 header 关联上传请求，结果出现状态错乱：用户刷新页面、重试上传、多个标签页同时操作，旧连接没关，新进度推到错误 conn 上。
正确做法是让上传请求和 WS 连接共用同一个上下文或唯一 ID，且上传 handler 启动时就确认该 WS 连接还活着。
立即学习“go语言免费学习笔记（深入）”；
- 上传接口 URL 带一次性 Token（如
/upload?ws_id=abc123），后端用该 token 查找对应 WS 连接，查不到就拒绝 - WS 连接建立后立刻发心跳，服务端记录最后活跃时间；上传 handler 检查该连接是否
LastPing > time.Now().Add(-30 * time.Second) - 上传结束或出错后，主动调
conn.Close()并从 map 中删掉，避免 goroutine 泄漏
websocket.WriteMessage 频率太高会阻塞上传
每读 1KB 就发一次进度，看似精细，实际容易把网络栈打满，尤其客户端弱网时，WriteMessage 会阻塞甚至超时，反过来卡住上传流 —— 进度卡在 85%，文件却早传完了。
这不是并发问题，是写入节奏失控。WebSocket 是全双工，但写通道有缓冲上限，Go 的 gorilla/websocket 默认 write buffer 是 4096 字节，高频小消息很快填满。
- 进度只按百分比阶梯上报：0% → 10% → 20% … 100%，跳变超过 5% 才发一次
- 用带缓冲 channel（如
ch := make(chan int, 1)）做节流，新进度进来先尝试select { case ch ，丢弃中间值 - 100% 必须确保送达：用
conn.SetWriteDeadline(time.Now().Add(5 * time.Second))加超时，失败则记录日志，不重试
大文件上传下 net/http 超时和内存控制
默认 http.Server 的 ReadTimeout 是 0（不限），但上传 2GB 文件卡在 99% 十分钟，HTTP 连接其实早被中间代理（nginx、ALB）断开了，而 Go server 还在读 —— 最终 panic 或 goroutine 堆积。
更隐蔽的是内存：multipart 解析时，FormValue 类字段若没限制大小，攻击者可发巨量文本字段耗尽内存。
- 上传 handler 开头立刻设
ctx, cancel := context.WithTimeout(r.Context(), 30 * time.Minute)，所有 IO 操作都用该 ctx - 用
r.ParseMultipartForm(32 限制内存缓冲为 32MB，超出部分自动落盘；同时检查 <code>r.MultipartForm.Value长度，超长字段直接 reject - 别依赖
Content-Length判断文件大小 —— 它可被伪造，真实大小以读取结束为准；进度计算始终基于已读字节数 / 预估总长（前端传的Content-Length仅作参考）
进度反馈不是炫技功能，它暴露的是整个请求生命周期的可控性。只要 upload handler 和 websocket 之间没共享状态、没共用超时、没忽略底层 reader 的阻塞特性，剩下的就是数值怎么报得准的问题。