Fiber的“零内存分配”指复用RequestCtx和缓冲区以减少GC压力，但c.Params("id")、c.Body()等操作会触发堆分配；需避免new、隐式拷贝及goroutine捕获ctx；JSON应绕过反射；StrictRouting不可关闭；pprof需手动挂载并加?gc=1。
零内存分配不是指完全不分配，而是避免请求生命周期内的重复/冗余分配
Fiber 的「零内存分配」是相对 net/http 而言的性能宣传，并非字面意义的 0 次 new 或 make。它的核心是复用底层 fasthttp.RequestCtx 结构体和缓冲区，让每个请求尽可能不触发 GC 压力。但这个优势极易被代码破坏：一旦你从 c.Params("id") 拿字符串再转 int，或调 c.Body()，就立刻引入至少一次堆分配——前者多一次字符串拷贝，后者多一次 []byte → string 转换。
关键判断标准是：是否在 handler 内新构造了生命周期超出当前请求的对象（如 map、struct、slice）。只要没 new，且没隐式拷贝，就算守住了「零分配」底线。
-
c.ParamsInt("id")直接返回int，内部缓存解析结果，不分配字符串 -
c.BodyBytes()返回底层缓冲区引用，前提是你不修改它；若需异步处理，必须bytes.Copy()一份 -
c.Locals是 map[string]interface{}，存值不分配，但取值后类型断言失败不会 panic，建议统一用c.Locals.Get("key") - 别在 handler 里启动 goroutine 并捕获
*fiber.Ctx—— 复用机制会让后续请求读到脏数据，必须用c.Context().Copy()或只提取所需字段
ctx.JSON() 是性能黑洞，结构体反射开销远超路由本身
很多人以为 c.JSON(200, v) 是最省事的写法，但它依赖 reflect 遍历结构体字段，每次调用都触发动态类型检查和内存布局计算。压测中常见现象是：QPS 卡在 8k 上不去，Profile 显示 reflect.Value.Interface 占 CPU 35% 以上。
真正高性能做法是绕过反射：结构固定时，用 jsoniter.ConfigCompatibleWithStandardLibrary.Unmarshal() 预编译解码器；响应固定时，手写 json.Marshal + c.Status(200).Send()，或直接拼接字节切片。
- 避免
c.BodyParser(&v)，它和c.JSON()共享同一套反射路径 - 如果必须用结构体，定义时加
json:tag，并确保字段首字母大写（小写字段无法被反射读取） - 高频接口（如健康检查）直接返回
c.SendString(`{"status":"ok"}`)，比c.JSON(map[string]string{"status": "ok"})快 3 倍以上
StrictRouting 和尾斜杠不是配置问题，是路由契约问题
StrictRouting: true 不是 bug，是 Fiber 对路径语义的严格约定：/users 和 /users/ 是两个不同资源。关掉它看似解决 404，实则埋下更隐蔽的匹配冲突——比如同时注册了 /users 和 /users/:id，关掉 StrictRouting 后，/users/123 可能被前者捕获，c.Params("id") 拿不到值。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
生产环境不要动 StrictRouting，而是用中间件统一处理：所有结尾带斜杠且非根路径的请求，301 重定向到无斜杠版本。这既符合 REST 规范，又避免前端 SDK、OpenAPI 文档、Postman 集合因路径不一致反复出错。
- 中间件必须注册在所有其他中间件（如 JWT、CORS）之前，否则鉴权会拦截重定向
- 别写
app.Get("/users/", ...)单独处理，那只是掩盖问题，不是解决 - 上线前同步检查所有调用方使用的路径格式，确保全量统一
pprof 不挂载 = 白装，采集 heap profile 必须加 ?gc=1
Fiber 默认不注册任何 pprof handler，哪怕你写了 import _ "net/http/pprof"，/debug/pprof/ 依然返回 404。这是因为 Fiber 完全不使用 http.DefaultServeMux，两者路由系统隔离。
手动桥接后，另一个致命坑是采集 /debug/pprof/heap 时不加 ?gc=1。Fiber 高并发下对象分配快、GC 滞后，不强制 GC 就采样，profile 显示的往往是上一轮未回收的积压对象，而非真实泄漏点。比如一个 handler 每次都 new map，但 GC 还没跑，heap profile 里看到的却是旧的、已无业务关联的实例。
- 挂载路由必须放在
app.Use()所有中间件之后，否则会被拦截 - 监听地址不能只绑
127.0.0.1:3000，压测机访问需要0.0.0.0:3000 - 正确采集命令：
curl "http://localhost:3000/debug/pprof/heap?gc=1"（Go 1.19+ 支持） - 别依赖
runtime.GC()后立刻 curl —— GC 是异步的，调用后立即 fetch 可能为空或中断
实际部署时最容易被忽略的是：ctx 复用机制要求你绝不能把 *fiber.Ctx 或其字段（如 c.Request().URI() 返回的 fasthttp.URI）逃逸到 goroutine 或全局变量里。这个约束不像 panic 那样立刻报错，而是在高并发下表现为偶发的数据错乱，极难复现和定位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
