fiber 比 net/http 快因基于 fasthttp 避免接口抽象与内存分配，但实际压测未必胜出；优势限于纯路由场景，一旦涉及 json 序列化、反射或混用标准库中间件，性能差距迅速收窄甚至反超。
为什么 Fiber 比 net/http 快，但实际压测未必赢？
因为 Fiber 底层用的是 fasthttp，它绕过了 Go 标准库的 net/http 中大量接口抽象和内存分配（比如不创建 http.Request/http.Response 实例），直接操作字节切片。但这只在「纯路由+简单响应」场景下优势明显；一旦你频繁调用 context.JSON()、做结构体反射、或混用标准库中间件，性能差距会快速收窄甚至反超。
-
fasthttp的RequestCtx是复用的，但如果你在 handler 里启动 goroutine 并捕获了ctx，可能读到脏数据——必须用ctx.Copy()或提取所需字段 - 所有
ctx.Body()返回的是底层缓冲区的引用，不是拷贝；如果做异步处理，要手动bytes.Copy()否则 panic -
Fiber默认禁用Content-Type自动推导，ctx.SendString("hi")发出去是纯文本，前端拿不到 JSON 解析——得显式写ctx.JSON(map[string]string{"ok": "yes"})
Fiber 中间件为啥不能直接用 net/http 的？
因为 fasthttp 的请求生命周期和接口签名完全不同：net/http 中间件依赖 http.Handler 函数签名，而 Fiber 的 func(*fiber.Ctx) 不兼容。强行包装会导致上下文丢失、超时失效、甚至 panic。
- 别写
http.HandlerFunc然后丢给app.Use()——编译不过 - 像
gorilla/handlers这类标准库生态中间件，必须找对应fiber版本（如fiber/handlers），或者自己重写逻辑 - 日志中间件里想打印完整 URL？别用
ctx.Request().URI().String()，它返回的是带 query 的原始路径；要用ctx.OriginalURL()才符合预期
并发高时 ctx.Locals 和 ctx.Context() 哪个更安全？
ctx.Locals 是 Fiber 提供的 request-scoped 存储，线程安全且生命周期绑定当前请求；而 ctx.Context() 返回的是底层 fasthttp 的 context.Context，它本身不带 cancel/timeout 控制（fasthttp 不实现 Context.WithTimeout），也不能存任意值。
TurboShop是一套使用强大、安全的JAVA语言开发，基于企业级J2EE架构设计的免费商城系统。整个商城逻辑业务搭建在我们自主研发的TurboPortal平台上，保证了商城具备优秀的负载性能、极快的响应速度、稳定的产品质量、牢固的安全特性、流畅的web流程控制、良好的跨平台特性和后续开发的可扩展性。 TurboShop V4.0.0(Spring版) 更新：久别的4.0版本，时隔4年归来。本版
- 存用户 ID、trace ID 这类请求级数据，只用
ctx.Locals["user_id"] = 123，别碰context.WithValue - 需要超时控制？别依赖
ctx.Context()，改用ctx.Context().Done()配合外部定时器，或直接上time.AfterFunc -
ctx.Locals是 map[string]interface{}，类型断言失败不会 panic，但建议统一用ctx.Locals.Get("key")+ 类型检查
部署时 Fiber 的 ServerHeader 和 DisableStartupMessage 会影响什么？
这两个配置看似只是开关，实则关系到安全扫描结果和可观测性落地。默认开启的启动提示会暴露框架版本，而默认设置的 Server: fiber 头可能被 WAF 规则拦截。
立即学习“go语言免费学习笔记（深入）”；
-
app.Settings.ServerHeader = ""可以清空 Server 头，但别设成"nginx"——某些 CDN 会识别并覆盖，反而暴露异常 -
DisableStartupMessage: true关闭控制台欢迎语，但日志里仍需补上监听地址和端口，否则 k8s liveness probe 失败时无从排查 - Docker 部署时若用
ENTRYPOINT ["./app", "-addr", ":8080"]，确保app.Listen()参数与命令行一致，否则Listen(":3000")会覆盖配置，容器内端口错位
