Go HTTP服务器默认配置易成瓶颈：未设Read/WriteTimeout致连接耗尽，MaxConnsPerHost默认无限制可能压垮后端，log.Fatal启动无优雅关闭；视频上传卡在multipart解析因默认全文件入内存，需预设ParseMultipartForm大小。
Go HTTP 服务器默认不支持高并发？
不是不支持，是默认配置容易成为瓶颈。Go 的 http.Server 本身轻量且并发能力强，但关键参数没调就会在真实流量下卡死或超时。
-
ReadTimeout和WriteTimeout不设的话，慢客户端可能长期占住连接，耗尽net.Listener文件描述符 -
MaxConnsPerHost（在http.Transport中）默认是 0（无限制），但后端服务如视频转码 API 若没限流，会反向压垮自己 - 用
log.Fatal(http.ListenAndServe(...))启动，panic 一来整个服务就挂，没做 graceful shutdown
实操建议：启动前显式配置超时和连接池，比如 srv := &http.Server{Addr: ":8080", ReadTimeout: 5 * time.Second, WriteTimeout: 30 * time.Second}；用 srv.Shutdown() 配合信号监听，避免正在处理的视频上传请求被粗暴中断。
视频上传接口为什么总卡在 multipart 解析阶段？
因为 request.ParseMultipartForm() 默认把整个文件读进内存，100MB 视频直接触发 OOM 或 GC 压力飙升。
- 必须提前调用
r.ParseMultipartForm(32 （即 32MB 内存上限），超出部分自动落盘到临时目录 - 临时目录磁盘 IO 慢？改用
multipart.NewReader(r.Body, boundary)手动流式解析，跳过不需要的字段，直接io.Copy到对象存储上传流 - 别依赖
r.FormValue("title")获取元数据——如果它在大文件之后，解析器会等完整体传完才开始读，延迟翻倍
示例：先用 bufio.NewReader(r.Body) 扫描 header，拿到 Content-Disposition 后立即提取 filename 和字段名，再按需消费 body 流。
立即学习“go语言免费学习笔记（深入）”；
短链接生成 + 视频播放鉴权怎么避免 DB 查库拖慢响应？
每播一次都查一次 MySQL，QPS 上千时 DB 成最慢环节。核心是把「链接有效性」和「播放权限」变成无状态判断。
- 短链用带签名的 token 生成，比如
base64(url) + "." + hmac.Sum256(secret+url+expire).String()，校验时只做哈希比对，不查库 - 播放鉴权走 JWT：颁发含
vid、exp、ip（可选）的 token，中间件用jwt.Parse()验签解码，全程无 DB 交互 - 注意：
time.Now().Unix()和服务器时间不同步会导致 token 频繁失效，所有节点必须 NTP 同步
如果业务要求实时封禁某个视频，加一层 Redis 缓存黑名单，key 是 vid:block，过期时间设短（比如 5 分钟），查库只作为兜底，不影响主路径性能。
goroutine 泄漏导致内存持续上涨，怎么快速定位？
常见于忘记 close http.Response.Body、或用 time.AfterFunc 启动定时任务却没 cancel，goroutine 积累后 GC 回收不了。
- 加健康接口暴露
/debug/pprof/goroutine?debug=2，看堆栈里是不是大量卡在net/http.(*persistConn).readLoop或runtime.gopark - HTTP 客户端务必用
defer resp.Body.Close()，哪怕 resp 是 nil 也要先判空，否则 panic 会跳过 defer - 用
context.WithTimeout包裹所有外部调用（如对象存储上传、转码服务通知），超时自动 cancel 对应 goroutine
最容易被忽略的是：日志打点里用了 fmt.Sprintf 拼接大结构体，而该结构体含未导出字段或循环引用，导致 fmt 包内部 goroutine 卡死 —— 这类问题只能靠 pprof goroutine 堆栈一眼识别。
