fasthttp.RequestCtx 和 *http.Request 的主要差异在哪
最直接的冲击是：你不能把 fasthttp.RequestCtx 当成 *http.Request 用，它们压根不是同一套抽象。标准库里靠 r.URL.Query() 拿查询参数，fasthttp 得调 c.QueryArgs()；读 body 是 r.Body vs c.PostBody()；甚至 header 访问都是 r.Header.Get("X-Trace") vs c.Request.Header.Peek("X-Trace")。
常见错误现象：直接传 fasthttp.RequestCtx 给原本为 http.Handler 写的中间件，panic 或静默丢数据——因为类型不兼容，且生命周期管理逻辑完全不同。
-
fasthttp.RequestCtx是复用对象，每次请求后会被重置，不能跨 goroutine 保存引用 - 所有读取方法（如
c.FormValue()、c.UserAgent()）返回的是底层字节切片的引用，不是拷贝；如果需要长期持有，得手动string(...)或copy() - 没有
context.Context字段，但你可以用c.SetUserValue()+ 自定义 cancel 逻辑模拟，别硬塞context.WithTimeout
怎么安全地迁移一个已有的 net/http 路由到 fasthttp
别试图“全量替换”，先挑高并发、低逻辑、纯 API 的路由切过去，比如健康检查、指标上报、简单 POST 表单接收。
使用场景很明确：你已经测出 net/http 在 5k+ 并发下 CPU 卡在 GC 或 syscall，而业务逻辑本身不依赖 http.Server 的高级特性（如 HTTP/2 push、TLS client auth callback、或第三方中间件如 gorilla/mux 的嵌套路由）。
立即学习“go语言免费学习笔记（深入）”；
- 路径匹配用
fasthttp.ServeMux，它只支持前缀匹配和通配符*，不支持正则或命名参数；想用/user/:id？得自己解析c.Path()或换fasthttprouter - 中间件必须重写：原
func(http.Handler) http.Handler模式完全失效；fasthttp 中间件是func(*fasthttp.RequestCtx)，且需显式调用c.Next()（如果有的话）或c.Handler链式跳转 - 日志、trace 等依赖
http.Request字段的模块，得提取关键字段（如c.Method(), c.URI().String(), c.RemoteAddr()）再喂给原有逻辑
fasthttp.Client 发起请求时为什么经常超时或连接复用失败
默认配置太“激进”：连接池大小、空闲超时、TLS handshake 超时全设得极短，线上一压就报 timeout: timed out waiting for idle connection 或 connection refused。
性能影响明显：不调优的话，高并发下大量新建连接，TLS 握手开销翻倍，CPU 和文件描述符都吃紧。
- 务必设置
Client.MaxConnsPerHost = 200（根据后端扛量调） -
Client.MaxIdleConnDuration = 30 * time.Second，避免后端主动断连导致下次请求重连 - TLS 场景下，打开
Client.TLSConfig = &tls.Config{InsecureSkipVerify: false}并复用，否则每次请求新建 TLS config 会触发锁竞争 - 别用
fasthttp.Get这类快捷函数做高频调用——它们内部每次新建临时Client，连接池失效
如何处理 multipart/form-data 文件上传
fasthttp 不像 net/http 那样自动解析 r.MultipartReader()，也不建临时文件；它把整个 body 当二进制读上来，然后靠 c.MultipartForm() 解析，但这个方法有坑。
容易踩的坑：上传大文件时，c.MultipartForm() 默认把所有 part 全载入内存，OOM 风险极高；而且它不支持流式处理，无法边收边转存。
- 用
c.Request.MultipartFormValue("field")只拿小文本字段，别用它读文件 - 文件内容必须用
c.Request.MultipartFormFile("file")拿到multipart.File接口，再配合io.Copy流式写入磁盘或对象存储 - 务必限制总 body 大小：
Server.MaxRequestBodySize = 10 * 1024 * 1024，否则恶意上传可轻易耗尽内存 - 注意：fasthttp 的
multipart.File是内存映射或缓冲区切片，不是*os.File，不能直接传给需要os.FileInfo的库
最麻烦的地方其实是错误处理链路：上传失败时，c.Error() 不会自动终止响应，你得手动 c.SetStatusCode(400) 并 return，否则可能写出半截响应再 panic。
