fasthttp.RequestCtx不能跨goroutine持有，因其底层缓冲区为共享内存切片，handler返回后可能被复用覆盖；须立即拷贝如body := append([]byte(nil), ctx.PostBody())再传入goroutine。
直接换 fasthttp 不会自动突破性能瓶颈，真正起作用的是对复用模型、内存生命周期和连接调度的显式控制——多数人卡在“以为替换了库就完事”，结果 QPS 没涨，反而出现随机 panic 或脏数据。
fasthttp.RequestCtx 为什么不能跨 goroutine 持有
fasthttp.RequestCtx 是从 sync.Pool 复用的对象，它的底层缓冲区（如 ctx.PostBody() 返回的 []byte）不是独立副本，而是共享内存切片。一旦 handler 函数返回，这块内存可能立刻被下一个请求覆盖。
- 常见错误现象：
go func() { json.Unmarshal(ctx.PostBody(), &v) }()→ 偶发解析失败、空结构体、或panic: runtime error: slice bounds out of range - 正确做法：必须立即拷贝，例如
body := append([]byte(nil), ctx.PostBody())，再传入 goroutine - 同理需拷贝的还有：
ctx.QueryArgs().Peek("id")、ctx.Request.Header.Peek("Authorization")、ctx.FormValue("token") - 若需长期持有，建议用
ctx.UserValue("key")存已拷贝值，或改用 channel + worker pool 控制异步节奏
响应写入必须走 ctx.Write* 系列方法
fasthttp 不兼容 http.ResponseWriter，所有输出都必须通过 ctx 方法触发，否则响应静默丢失或 panic。
- 设 Content-Type：用
ctx.SetContentType("application/json")，不是w.Header().Set() - 写 JSON：推荐
ctx.JSON(fasthttp.StatusOK, data)（需自行封装），或json.NewEncoder(ctx).Encode(data) - 写原始字节：用
ctx.Write(body)，注意它不自动设置Content-Length；大响应建议手动调ctx.Response.Header.SetContentLength(len(body)) - 报错响应：用
ctx.Error("bad request", fasthttp.StatusBadRequest)，不是http.Error()
Server 和 Client 都必须显式调优连接参数
默认配置极度保守，高并发下极易触发 timeout: timed out waiting for idle connection 或 TLS 握手风暴。
立即学习“go语言免费学习笔记（深入）”；
-
fasthttp.Server关键参数：ReadTimeout/WriteTimeout至少设为30 * time.Second，IdleTimeout设为60 * time.Second，Concurrency设为256 * runtime.NumCPU() -
fasthttp.Client必须按 host 隔离：高频调用多个域名时，不要共用全局 client，应为每个 host 创建独立fasthttp.HostClient - 连接池参数：
MaxConnsPerHost: 1000，MaxIdleConnDuration: 30 * time.Second，并禁用DialDualStack: true避免 IPv6 fallback 延迟 - 务必用
client.Do(req, resp)，别用client.Get()等快捷方法——后者每次新建fasthttp.Request，破坏复用逻辑
什么时候不该换 fasthttp
它不是万能加速器，只在特定路径上有效。如果服务依赖以下任一特性，强行替换反而引入维护成本或行为偏差：
- 标准
http.Request.Context()链路（如 opentelemetry trace、auth 中间件、cancel 传播） - 严格 RFC 兼容性（
fasthttp忽略 header 大小写、跳过部分边界校验） - 复杂模板渲染或 multipart 表单解析（
fasthttp的 form 解析比net/http更简陋） - 已有大量基于
http.Handler的中间件生态，迁移成本远超收益
真正关键的判断点是 pprof：只有当你看到 net/textproto.MIMEHeader.Read 或 bufio.NewReaderSize 占 CPU >15%，且 handler 本身逻辑极轻（纯 JSON 转发/规则匹配），才值得投入迁移。
