fasthttp无法直接替换net/http，因其RequestCtx与标准http.Request/Response类型不兼容，Handler签名（func(fasthttp.RequestCtx) vs func(http.ResponseWriter,http.Request)）及生态依赖完全不互通，强行替换会导致路由、中间件、上下文、Header等全部失效。
FastHTTP 不能直接替换 net/http —— 它不是 drop-in 替代品，强行“替换”会导致路由、中间件、标准接口全部失效。
为什么 fasthttp 无法用 import 替换就跑起来
因为 fasthttp.RequestCtx 和 http.Request/http.ResponseWriter 类型不兼容，所有基于 net/http 构建的框架（如 Gin、Echo、http.ServeMux）和中间件（log、cors、jwt）都依赖 Go 标准 Handler 接口：func(http.ResponseWriter, *http.Request)。而 fasthttp 的 handler 签名是：func(*fasthttp.RequestCtx)。
- 你不能把 Gin 的
router.GET(...)传给fasthttp.Server -
http.HandlerFunc包装器（如fasthttpadaptor）只能单向桥接：把net/httphandler 转成fasthttp可调用形式，但性能会打折扣（需内部构造/解析 HTTP 报文） - 所有依赖
http.Request.Context()、http.Request.Header.Clone()、responseWriter.Header().Set()的逻辑，在fasthttp中要么不存在，要么行为不同（例如 header 是 slice-based，大小写不敏感但不保留原始 casing）
什么时候该考虑 fasthttp 而不是优化 net/http
只有在满足以下全部条件时，引入 fasthttp 才有实际收益：
- 服务是纯 API（无模板渲染、无文件上传解析、无复杂 cookie/session 逻辑）
- 瓶颈确实在 HTTP 解析层（pprof 显示
net/http.(*conn).serve或net/http.readRequest占 CPU >30%） - 你能放弃所有标准库生态：不用
http.Client做下游调用（得换fasthttp.Client），不用http.Redirect，不用http.Error，甚至日志里不能再用r.RemoteAddr（得用c.RemoteIP()） - 团队接受手写路由（
switch string(c.Path())）或使用fasthttp.Router这类轻量路由，而非 Gin/Echo 的声明式语法
fasthttp 最容易踩的三个内存坑
它通过对象池复用 RequestCtx 和底层 buffer，带来性能提升，但也引入隐式生命周期约束：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
c.PostBody()返回的是内部 buffer 的 slice —— 如果你在 goroutine 里异步保存或返回这个 []byte，下次请求复用该 ctx 时数据会被覆盖。正确做法：bytes.Copy(dst, c.PostBody())或append([]byte{}, c.PostBody()...) -
c.QueryArgs().Peek("key")同样返回内部 slice；若需跨函数传递，必须拷贝：string(c.QueryArgs().Peek("key")) - 不要在 handler 里启动 goroutine 并直接传入
*fasthttp.RequestCtx—— 它可能已被回收。应提取所需字段（如string(c.Path())、c.UserValue("id")）后传参
简单场景下怎么安全起步
从零开始用 fasthttp 写一个 JSON API，比改现有项目更可行：
package main
import (
"encoding/json"
"github.com/valyala/fasthttp"
)
func handler(ctx *fasthttp.RequestCtx) {
// 注意：ctx.Response.Header.Set("Content-Type", "application/json") 必须在 Write之前
ctx.Response.Header.Set("Content-Type", "application/json")
var req struct{ Name string }
if err := json.Unmarshal(ctx.PostBody(), &req); err != nil {
ctx.Error("bad json", fasthttp.StatusBadRequest)
return
}
resp := map[string]string{"hello": req.Name}
data, _ := json.Marshal(resp)
ctx.SetBody(data) // 自动设 Content-Length
}
func main() {
if err := fasthttp.ListenAndServe(":8080", handler); err != nil {
panic(err)
}
}
记住：没有 http.ServeMux，没有 context.WithTimeout 自动注入，超时要自己用 ctx.Timeout() == 0 判断 + ctx.SetConnectionClose()；错误响应要用 ctx.Error(msg, code)，而不是 http.Error。
真正卡住人的从来不是怎么写 handler，而是当你要加 Prometheus metrics、JWT 验证、trace 上下文透传时，发现每个环节都要重写适配——这才是 fasthttp 的隐性成本。
