Fiber内存占用最低的前提是不用fiber.Default()，因其默认加载Logger等中间件导致高频内存分配和I/O缓冲膨胀；生产环境应改用fiber.New()并禁用启动日志，配合fasthttp对象池复用机制（如用c.ParamsInt而非c.Params）以避免额外拷贝。
实测 Fiber 内存占用显著低于 Gin，约为其 40%；但比 Go 标准库略高（约 +8%～12%），属于高性能框架中资源最省的一档 —— 前提是你没用 fiber.Default()。
为什么 fiber.Default() 会让内存飙升
它默认挂载 Logger、Recover、RequestID 三个中间件，其中 Logger 每次请求都做完整字符串拼接 + 写磁盘，触发高频内存分配和 I/O 缓冲区膨胀。实测在 4 核 8G 环境下，QPS ≥5k 时 RSS 增长比 fiber.New() 高出 60MB+，且 GC 压力明显上升。
常见错误现象：top 显示 go 进程 RES 持续上涨、pprof/heap 显示大量 strings.Builder.String 和 bufio.(*Writer).Write 占主导。
- 开发阶段可用
fiber.Default()快速验证逻辑，但上线前必须替换 - 生产环境一律用
fiber.New(&fiber.Config{DisableStartupMessage: true}) - 真要日志，改用采样式结构化输出（如只记录 error 或慢请求），别碰
fiber.Logger()
fasthttp 底层复用机制如何压低内存
Fiber 基于 fasthttp，核心是复用 *fasthttp.Request 和 *fasthttp.Response 对象池，避免每次请求分配新结构体。这意味着：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
c.Params("id")返回的是底层缓冲区切片引用，不是新字符串 —— 但你若转成string或传给strconv.Atoi()，就立刻触发拷贝 - 正确做法：优先用
c.ParamsInt("id")（内置缓存、不 panic、零分配） - 读请求体必须用
c.BodyBytes()，而非c.Body()（后者强制转string，多一次[]byte → string拷贝） - JSON 解析若结构固定，避开
c.BodyParser(&v)（依赖reflect），改用预编译的jsoniter解码器
对比测试中容易被忽略的干扰项
真实业务里框架内存差异常被掩盖，但压测时稍不注意就会放大误差：
- 没关
gin.DebugMode或echo.Logger调试输出，Gin/QPS 直接跌 40%，看起来像 Fiber 更省 —— 实际是 Gin 自己拖垮了自己 - 用
wrk -t4 -c100压测却没加-d30s预热，首秒抖动拉低平均值，误判为 Fiber “更稳” - 数据库连接池未按进程隔离：Prefork 开启后仍共用一个
*gorm.DB，导致 goroutine 在acquireConn上排队，RSS 虚高（非框架问题，但归因常错） -
pprof/heap采集时没加?gc=1，看到的是含垃圾对象的快照，误以为内存泄漏
真正决定内存水位的，从来不是框架名字，而是你是否让 fasthttp 的复用机制跑起来 —— 一旦你写个 string(ctx.Params("id")) 或调一次 c.Body()，那点优势就没了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
