Fiber 高性能写法：用 ctx.BodyBytes() 替代 ctx.Body()，ctx.ParamsInt() 替代 strconv.Atoi(ctx.Params("id"))，ctx.JSON() 替代 json.Marshal，禁用 fiber.Logger() 以避免 I/O 拖垮 QPS，Prefork 仅在多核高并发场景下有效。
Fiber 的 app.Get 和 app.Post 怎么写才不掉性能
Fiber 默认就用上了 fasthttp，但很多人一加中间件或乱用 ctx.Body 就退化回标准库水平。关键不是“能不能跑”，而是“并发上来后延迟是否突增”。
-
ctx.Body()会触发完整字节拷贝，高吞吐下成为瓶颈；改用ctx.BodyBytes()直接取底层 slice，前提是后续不修改内容 - 路由参数别写成
/:id后再用strconv.Atoi(ctx.Params("id"))—— 改用ctx.ParamsInt("id")，它内建缓存且跳过错误 panic - JSON 序列化别碰
json.Marshal，直接上ctx.JSON(200, data)，Fiber 内部用了预分配 buffer 和 unsafe 字符串转换
为什么 fiber.New() 加了 DisableStartupMessage 还打日志
启动日志没关掉，大概率是因为你启用了其他中间件（比如 logger 或 recover），它们自己会输出。Fiber 的 DisableStartupMessage 只管那一行 ⇨ http server started。
- 检查是否误启用了
fiber.Logger()：它默认每条请求都打时间、状态码、路径，压测时 I/O 直接拖垮 QPS - 开发环境留着
Logger没问题，上线前必须删掉或换成采样式日志（比如只记 error 级） - 如果真要静默启动，除了
DisableStartupMessage: true，还得确认没调app.Listen之外的任何带副作用的初始化逻辑
和 Gin / Echo 对比时，ctx.Locals 和 ctx.Context.Value 别混用
Fiber 的 ctx.Locals 是 map[string]interface{}，Gin 的 ctx.Set 和 Echo 的 ctx.Set 行为类似，但底层实现完全不同。跨框架迁移时最容易在这里丢数据或 panic。
-
ctx.Locals是 Fiber 自维护的 map，线程安全，适合放中间件传参（如用户 ID、请求 traceID） - 别往里面塞指针或大结构体——没有 copy 保护，下游 goroutine 修改会影响上游
- 如果对接需要
context.Context的库（比如 database/sql、redis-go），必须显式调用ctx.Context()拿原生 context，ctx.Locals不会自动透传到那里
fiber.New() 的 Prefork 开了反而更慢？
Prefork 在 Linux 上启用 fork 多进程模型，听起来能压榨 CPU，但实际在小规模部署（≤4 核）、SSD 一般、连接数
立即学习“go语言免费学习笔记（深入）”；
- 只在明确有多个物理 CPU 核、且压测发现单进程吃满一个核还扛不住时才开
Prefork: true - 开了 Prefork 后，
app.Shutdown()必须用os.Interrupt信号控制，否则子进程可能残留 - 本地开发或 Docker 单容器部署时，Prefork 基本没意义，还让调试变麻烦（日志分散、pprof 绑定困难）
真正卡住性能的，往往不是框架选型，而是中间件顺序、JSON 字段标签写法、甚至 time.Now() 调用位置。Fiber 快的前提是别把它当 Gin 写。
