开启prefork是fiber应对高并发内存飙升最直接有效的手段，但需关闭全局状态依赖、避免fasthttp buffer泄漏、禁用隐式内存增长；因fasthttp复用buffer，若在中间件中长期保存body/params、滥用locals、闭包引用或设过大bodylimit，将导致buffer无法回收。
开启 Prefork 是 Fiber 应对高并发请求下内存飙升最直接有效的手段，但前提是必须关掉全局状态依赖、避免 fasthttp 的 buffer 泄漏风险，并禁用所有隐式内存增长行为。
为什么高并发时 Fiber 内存会飙升
Fiber 底层用 fasthttp，它复用请求/响应对象和内部 buffer —— 这本是性能优势，但一旦开发者在中间件或 handler 中做了以下操作，buffer 就无法回收：
- 把
c.Body()或c.Params()结果长期存到全局 map / struct 字段里 - 用
c.Locals()存大对象（比如未序列化的 struct、raw JSON bytes）且没及时清理 - 在
fiber.Ctx上挂了闭包引用外部变量，导致整个栈帧无法 GC - 启用了
BodyLimit但设得过大（如 100MB），而攻击者发超长 payload 触发 buffer 预分配
启用 Prefork + 调整资源限制
Prefork:true 不是“多开几个进程就能压住内存”，而是让每个 worker 进程独立承担压力，避免单进程 buffer 积压。但必须配合系统级配置：
- 启动前执行
ulimit -n 65536，否则大量连接会触发too many open files，fasthttp会不断重试并缓存失败请求 - 在
fiber.Config中显式设BodyLimit: 4 * 1024 * 1024（4MB），比默认的 4GB 安全得多 - 禁用
DisableKeepalive: true—— Keepalive 复用连接才能让fasthttp的 connection pool 发挥作用，否则每次新建连接都分配新 buffer - 用
ServerHeader: ""清空响应头，减少每响应一次的字符串拼接开销
中间件里别碰原始 buffer
Fiber 的 c.Body() 返回的是 fasthttp 内部 buffer 的切片，不是拷贝。常见错误写法：
// ❌ 危险：body 是底层 buffer 切片，后续请求可能覆盖内容 body := c.Body() json.Unmarshal(body, &data) <p>// ✅ 安全：显式拷贝 bodyCopy := append([]byte(nil), c.Body()...) json.Unmarshal(bodyCopy, &data) </p>
同理，c.Request().URI().PathOriginal() 也返回内部 buffer 切片；需用 string(c.Request().URI().PathOriginal()) 强制拷贝。
监控真实内存压力点
Fiber 默认不暴露内存指标，光看 top 的 RES 值会误判。要定位真实泄漏源：
- 加
pprof：在路由里注册app.Get("/debug/pprof/heap", func(c *fiber.Ctx) error { return pprof.Handler("heap").ServeHTTP(c) }) - 压测时用
go tool pprof http://localhost:3000/debug/pprof/heap查 top allocs - 重点关注
github.com/valyala/fasthttp.*下的acquireCtx、acquireRequest调用栈 —— 如果它们没被对应release，说明你卡住了某个fiber.Ctx实例（比如忘了return c.Next()或 panic 后没 recover）
真正棘手的内存问题往往不出现在业务逻辑，而在于你 hold 住了一个本该被释放的 fiber.Ctx，或者在 recover() 里又调用了另一个需要 buffer 的函数。
