fasthttp不是更快的net/http，而是另一套http模型，需重写而非升级：requestctx与*http.request完全不兼容，goroutine中必须复制postbody等切片，server/client默认配置极不友好，须显式调优超时与连接参数。
fasthttp 不是“更快的 net/http”，它是另一套 HTTP 处理模型——换用它不是升级，而是重写。如果你的业务逻辑重度依赖 http.Request 生命周期、标准库中间件或 context.Context 超时控制，直接切到 fasthttp 会出问题，不是性能没提升，而是请求错乱、数据丢失、panic 频发。
fasthttp.RequestCtx 和 *http.Request 完全不兼容
你不能把 *fasthttp.RequestCtx 当作 *http.Request 传给任何原有逻辑。两者抽象层级、内存模型、生命周期管理完全不同：
-
r.URL.Query()在 net/http 里返回url.Values；fasthttp 得调c.QueryArgs()，再用.Peek("key")或.Get("key") -
r.Header.Get("X-Trace")→ 必须改成c.Request.Header.Peek("X-Trace") -
r.Body是io.ReadCloser；c.PostBody()直接返回[]byte，且是底层缓冲区引用 - 没有
c.Context()字段：调用c.Context()返回nil，硬塞context.WithTimeout没效果
常见错误现象：把 ctx 塞进 gorilla/handlers 日志中间件，结果日志字段全空，或 panic 报 invalid memory address。
goroutine 里用 PostBody() / FormValue() 必须复制字节
ctx.PostBody()、ctx.FormValue("name")、ctx.QueryArgs().Peek("id") 等所有以 Peek 或 Value 结尾的方法，返回的都是底层复用缓冲区的切片视图，不是拷贝。
- 错误写法：
go process(ctx.PostBody())→ 下一个请求进来，这块内存就被覆盖了 - 正确做法：立即复制，例如
body := append([]byte(nil), ctx.PostBody())或body := make([]byte, len(ctx.PostBody())); copy(body, ctx.PostBody()) - 同理适用于
ctx.Request.Header.Peek("User-Agent")、ctx.Request.URI().Username()等所有返回[]byte的方法
不复制的后果不是立刻 crash，而是偶发脏数据、JSON 解析失败、空字符串、甚至 runtime panic。
fasthttp.Server 和 fasthttp.Client 默认配置极不友好
开箱即用的配置是为单机压测设计的，不是为生产环境准备的。不调优就上线，高并发下必现超时和连接拒绝：
-
Server.IdleTimeout默认仅 10 秒 → 后端主动断连后，客户端下次请求强制重连 -
Client.MaxIdleConnDuration默认约 1 秒 → 连接池迅速耗尽，报timeout: timed out waiting for idle connection -
Server.Concurrency默认未设限但实际受限于 GOMAXPROCS → QPS 上不去，P95 延迟抖动剧烈 -
Client.MaxConnsPerHost默认 0（不限），但实际受系统文件描述符限制 → 高并发下too many open files
必须显式设置：
Server.ReadTimeout = 30 * time.SecondServer.WriteTimeout = 30 * time.SecondServer.IdleTimeout = 60 * time.SecondClient.MaxIdleConnDuration = 30 * time.SecondClient.MaxConnsPerHost = 200（按后端扛量调）
Fiber 框架的 ctx.Locals 是安全的，但 ctx.Context() 不是
Fiber 底层基于 fasthttp，但它封装了一层 fiber.Ctx。这里最容易被忽略的是存储机制差异：
-
ctx.Locals["user_id"] = 123是线程安全的，生命周期绑定当前请求，类型断言失败也不会 panic -
ctx.Context()返回的是 fasthttp 底层的context.Context，它不带 cancel/timeout 控制，也不能存任意值 —— 本质是空壳 - 别用
context.WithValue(ctx.Context(), key, val)，它什么也留不住；需要超时控制，得用time.AfterFunc或外部定时器配合ctx.Done() - 日志中间件想打完整 URL？别用
ctx.Request().URI().String()（含原始 query），改用ctx.OriginalURL()
真正容易被忽略的点在于：ctx.Locals 看似简单，但它是 Fiber 唯一推荐的 request-scoped 存储方式；一旦你绕过它去碰底层 context，就等于放弃框架的安全护栏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
