必须用fiber.New()初始化，别碰fiber.Default()——后者默认启用Logger（泄露Authorization头）、Recover（暴露panic堆栈）、RequestID（无采样直写），导致生产环境安全与性能双崩。
必须用 fiber.New() 初始化，别碰 fiber.Default()
上线即裸奔的最常见原因：还在用 fiber.Default()。它默认挂了 Logger（输出完整 Authorization 头）、Recover（暴露 panic 堆栈）、RequestID（无采样直写），I/O 和安全风险双爆表。
- 开发阶段可用
fiber.Default()快速验证逻辑，但上线前必须切到fiber.New() - 最小可用初始化写法：
app := fiber.New(fiber.Config{ StrictRouting: true, CaseSensitive: true, }) - 所有中间件（
cors.New()、csurf.New()、helmet.New()）都得手动注册，没有“默认安全”这回事
CORS 白名单必须精确匹配协议、端口、路径
cors.New() 默认是 AllowOrigins: "*"，生产环境等于关掉跨域防护。哪怕你写了白名单，一个斜杠或端口不一致就直接 404。
- 前端请求
Origin: https://a.com:8080，白名单只写https://a.com→ 拒绝 - 前端路径带尾部斜杠（
https://a.com/），白名单没写斜杠 → 拒绝（StrictRouting不影响 CORS 校验） - 多租户子域名场景，别用
AllowOriginsFunc直接返回true；应解析c.Hostname()后做白名单校验
健康检查必须区分 /health 和 /ready，且带依赖校验
只注册 app.Get("/health", func(c fiber.Ctx) error { return c.SendString("ok") }) 是无效的。Kubernetes 或 Istio 会把流量导进来，而此时 DB 可能还没连上。
-
/health：liveness，只判进程是否存活（如能否响应 HTTP） -
/ready：readiness，必须校验真实依赖：数据库用db.PingContext(ctx)，Redis 用redis.Ping()，外部服务优先用http.Head() - 每个检查必须带 context 超时：
ctx, cancel := context.WithTimeout(c.Context(), 2*time.Second)；别用if db != nil这类空值判断 - 禁用默认 ErrorHandler：
fiber.Config{ErrorHandler: func(c fiber.Ctx, err error) error { return c.Status(fiber.StatusInternalServerError).SendString("health check failed") }}
Prefork 模式要开，但得配 ulimit 和外部状态存储
Prefork: true 在多核服务器上能把 QPS 从 ~35k 拉到 ~120k，但不是开个开关就完事。
- 各子进程内存独立，不能靠全局变量存 session 或计数器；状态必须外置（Redis、PostgreSQL）
- 系统级文件描述符限制必须调高：
ulimit -n 65536，否则高并发下会报too many open files - 启动日志里会打印
Worker PIDs，这是正常现象；若看不到，说明 prefork 没生效（检查是否在 root 用户下运行，或被 systemd 限制） - 搭配反向代理（Nginx/Traefik）使用更稳；别让 Fiber 直面公网
fiber.Default() 的默认中间件、CORS 白名单漏了端口、健康检查没设 context 超时、Prefork 下误用内存共享。这些都不是“配置完就跑”，而是每一条都得对齐运行时行为。 
